主从模式又称为主从复制

在主从架构中master负责接收写请求写操作成功后返回客户端OK然后后将数据异步的方式发送给多个slaver进行数据同步不过从redis

当启动一个slave

开始全量复制的时候master会启动一个后台线程开始生成一份RDB快照文件同时还会将从客户端收到的所有写命令缓存在内存内存缓冲区中。

RDB文件生成完毕之后master会将这个RDB发送给slaveslave会先写入本地磁盘然后再从本地磁盘加载到内存中。

然后master会将内存中缓存的写命令发送给slaveslave也会同步这些数据。

负载均衡master能自动将数据同步到slave可以进行读写分离分担master的读压力尤其是在写少读多的场景下通过多个从节点分担读负载可以大大提高

Redis

当主节点出现问题时从节点仍然可以提供读服务人工干预的情况下也可以实现快速的故障恢复高可用基石

Redis

主节点如果down机系统无法提供写操作建立在从节点上的链接仍然可以进行读操作后续需要人工干预恢复主节点或切换某个从节点为主节点但是连接到原主节点的客户端需要修改配置且在主节点down机之前发生的写操作如果没有及时同步到从节点这部分数据将会丢失或者从原主节点的AOF文件从手工恢复

哨兵模式

主从模式中master挂掉后系统无法提供写操作没有人工干预的情况下不能自动选主。

为了提高可用性在主从模式的基础上增加哨兵(sentinel)用来监控各节点情况当master出现故障时能自动将一个slave转换为master。

哨兵节点是特殊的

Redis

节点不存储数据。

哨兵模式中一般是一主多从加上3个及以上哨兵节点。

监控Monitoring

每个哨兵节点每10秒会向主节点和从节点发送info命令获取最新拓扑结构图哨兵配置时只要配置对主节点的监控即可通过向主节点发送info获取从节点的信息并当有新的从节点加入时可以马上感知到每个哨兵节点每隔2秒会向redis数据节点的指定频道上发送该哨兵节点对于主节点的判断以及当前哨兵节点的信息同时每个哨兵节点也会订阅该频道来了解其它哨兵节点的信息及对主节点的判断其实就是通过消息publish和subscribe来完成的。

每隔1秒每个哨兵会向主节点、从节点及其余哨兵节点发送一次ping命令做一次心跳检测这个也是哨兵用来判断节点是否正常的重要依据。

自动故障转移Automatic

哨兵认为master客观下线后故障恢复的操作需要由选举出来的领头哨兵来执行选举领头哨兵采用Raft算法

发现master下线的哨兵节点我们称他为A向每个哨兵发送命令要求对方选自己为领头哨兵如果目标哨兵节点没有选过其他人则会同意选举A为领头哨兵如果有超过一半num(sentinel)/21的哨兵同意选举A为领头则A当选如果有多个哨兵节点同时参选领头此时有可能存在一轮投票无竞选者胜出此时每个参选的节点等待一个随机时间后再次发起参选请求进行下一轮投票竞选直至选举出领头哨兵

选出领头哨兵后领头者开始对系统进行故障恢复从出现故障的master所在的系统中哨兵可以监控多个master环境的slave中挑选一个来当选新的master,选择规则如下

所有在线的slave中选择优先级最高的优先级可以通过slave-priority配置如果有多个最高优先级的slave则选取复制偏移量最大即复制越完整的当选如果以上条件都一样选取id最小的slave挑选出需要继任的slave后领头哨兵向系统发送命令使其升格为master然后再向其他slave发送命令接受新的master最后更新数据。

将已经停止的旧的master更新为slave节点使其恢复服务后以slave的身份继续运行

如果哨兵集群只有

票所以如果有个哨兵挂掉了那么此时的集群是无法进行主从库切换的。

因此通常我们至少会配置

主从模式的优点它都有在主从模式的基础上增加了哨兵实现了master节点的自动切换系统可用性更高

缺点同样也继承了主从模式难以在线扩容的缺点Redis的容量受限于单机配置需要额外的资源来启动哨兵服务实现相对复杂一点

集群模式又称为cluster模式

哨兵模式解决了主节点自动切换的问题实现了高可用性但是单个节点的写并发能力和存储能力是有上限的无法扩展为了解决这个问题才有了clusterRedis

Cluster

就可以横向扩容了。

如果你要支撑更大数据量的缓存那就横向扩容更多的

master

Cluster要求至少需要3个master才能组成一个集群同时每个master至少需要有一个slave节点当master发生了宕机就会将对应的slave节点提拔为master来重新对外提供服务。

在cluster模式下集群能够自动将数据进行分片每个

master

上放一部分数据而且即使某个master不可用了其他的master仍然可以提供读写服务。

那么redis

的工作原理是什么样的呢它是如何把数据分配到不同的master上的呢

假如一个key过来了它要放到master1master2还是master3上如果决定的呢

哈希算法又称传统哈希算法

首先就是对key计算出一个hash值然后对节点数master个数取模然后存放在不同的

master

节点上例如hash1master3取模后1%31结果就是将key存放在master1上。

算法实现起来很简单但是有一定的局限性

节点减少了某个master节点挂掉了或者某些原因要撤掉一个master节点针对这种情况我们期望系统只是出现性能降低正常的功能不会受到影响但是已设置过的key将会产生很大影响比如原来是key的hash对3取模现在变成了对2取模导致hash计算的结果发生了偏移无法命中缓存导致缓存都失效了。

同样如果增加了节点原来的key也要重新计算hash值rehash到新的节点上。

对于分布式缓存这种的系统而言映射规则失效就意味着之前缓存的失效若同一时刻出现大量的缓存失效则可能会出现

“缓存雪崩”这将会造成灾难性的后果。

要解决此问题我们必须在其余节点上重新分配所有现有键这可能是非常昂贵的操作并且可能对正在运行的系统产生不利影响。

当然还有另一种更好的方案即使用一致性哈希算法。

一致性哈希算法

是一种特殊的哈希算法在移除或者添加一个服务器时能够尽可能小地改变已存在的服务请求与处理请求服务器之间的映射关系,一致性哈希解决了传统哈希算法在分布式哈希表Distributed

Hash

一致性哈希算法是在(传统)哈希算法基础上提出的在动态变化的分布式环境中哈希算法应该满足的几个条件平衡性、单调性和分散性。

hash

的结果应该平均分配到各个节点这样从算法上解决了负载均衡问题单调性是指在新增或者删减节点时不影响系统正常运行分散性是指数据应该分散地存放在分布式集群中的各个节点节点自己可以有备份不必每个节点都存储所有的数据

一致性哈希算法通过一个叫作一致性哈希环的数据结构实现。

这个环的起点是

2^32

数据读写执行节点查找操作时先根据key计算hash值然后顺时针找到第一个大于等于该哈希值的节点这种方式相比节点取余最大的好处在于加入和删除节点只影响哈希环中相邻的节点对其他节点无影响。

但一致性哈希也存在一些问题致性哈希算法在节点太少时容易因为节点分布不均匀而造成缓存热点的问题为了解决这种热点问题一致性

hash

hash每个计算结果位置都放置一个虚拟节点。

这样就实现了数据的均匀分布负载均衡。

redis

都会持有部分槽位t如上图中node1node2node3node4node5这些节点及它们所对应的槽位。

hash槽