主从复制
:解决了高并发问题
哨兵模式
:解决了高并发,高可用问题
分片集群
:解决了海量数据存储,高并发写的问题
图示:
主从复制:单节点 Redis 并发能力有限,为了进一步提高 redis 并发能力,所以搭建主从集群,实现读写分离。主节点是写,从节点是读,这就是主从复制
主从同步流程,分为两种情况,分为全量同步
和增量同步
根据上图:
从节点发送同步请求,master 节点判断 replid 是否一致(肯定是一致的),不是第一次同步就会去日志文件中获取 offset 后的数据,然后发送repl_baklog文件中 offset 后的命令,从节点执行命令即可。
主从复制解决了高并发问题,但是我们能保证Redis不宕机么?那万一宕机了,我们又怎么知道呢?那么就引入哨兵模式,哨兵模式的引入就保证了Redis的高可用问题。
哨兵模式三个作用:监控,自动故障恢复,通知
哨兵模式中有心跳机制,每隔1s会向集群中每个实例发送ping命令,如果回复pong,那就说明OK。如果某一个哨兵发现某一个实例在一定时间里没有回应,那么认为该实例是主观下线
。若是超过一定数量(最好是超过哨兵实例数量的一半。)的哨兵都认为这个实例主观下线,那么这个实例客观下线
。
脑裂
:主节点、从节点、哨兵处于不同网络分区,导致哨兵没有感知到主节点,所以哨兵又选举出了一个从节点为主,这样就存在了两个master,这样导致客户端还在老的主节点那里写数据,新节点无法同步。当网络恢复后,哨兵将老的主节点降为从节点,这是再从新的主节点同步数据,就会导致数据丢失。
解决办法
:修改Redis的配置,设置最少的从节点数量以及缩短主从数据同步的延迟时间,达不到要求就拒绝请求。
虽然主从复制保证了高并发,哨兵模式保证了高并发和高可用,但是海量数据存储、高并发写的问题并没有解决,那么分片集群就是为了解决上述两个问题。
图示:
换句话说,分片集群中有很多Master节点,那么 Redis 集群在存储/读取数据时如何确定选择哪个节点呢?
解决方案:
Redis 是纯内存操作,执行速度非常快,它的性能瓶颈是网络延迟
,而不是执行速度。 I/O 多路复用模型就是为了实现高效的网络请求
。
注意:有些时候,我们可能看到说Redis6.0之后引入多线程,在这里引入多线程要明白,是指接收网络请求,指令转换的那一部分采用多线程,是为了进一步解决网络瓶颈,并不是执行命令的时候。
Redis执行命令依旧是单线程
。
面试题: