一篇搞懂Redis的主从复制，哨兵模式，分片化集群原理

一.主从复制

1.概念

单节点的Redis，它的并发能力不强，只能一个redis服务来实现读写操作，为了提高单节点Redis的并发能力，我们就想办法实现去它的读和写分离，提高并发能力。

对于redis来说，高并发、高性能可以保证，高可用需要架构的设计，单机redis由于存在系统崩溃、硬盘故障的风险，还有内存的限制，所以企业一般都会搭建主从，对系统有更高要求会搭建集群。

主从复制，是指将一台Redis服务器的数据，复制到其他的Redis服务器。前者称为主节点(Master)，后者称为从节点(Slave)；数据的复制是单向的，只能由主节点到从节点。

默认情况下，每台Redis服务器都是主节点；且一个主节点可以有多个从节点(或没有从节点)，但一个从节点只能有一个主节点。

2.数据同步原理

• 全量同步

主从第一次同步时全量同步.

Replication Id：简称replid，是数据集的标记，id一致则说明是同一数据集。每一个master都有唯一的replid，slave则会继承master节点的replid。
offset：偏移量，随着记录在repl_baklog中的数据增多而逐渐增大。slave完成同步时也会记录当前同步的offset。如果slave的offset小于master的offset，说明slave数据落后于master，需要更新。
 

 详细步骤：

• slave 在自己的服务器上执行的 replicaof 命令（命令中包含master的IP地址和端口号），与指定的master建立连接。
• 随后slave向master发送一个请求，请求内容中带上自己的replid（数据集标记）和自己的偏移量offset，
•  master 判断是否和自己的replid一致，一致就使用增量同步（下面会讲）最新的数据，不一致就返回给从节点自己的replid和offset 偏移量。
• 然后主节点执行bgsave命令，生成RDB文件发送给从节点，同时记录RDB期间的所有命令生成一个文件repl_baklog 。
• 从节点接收到文件后，清除本地的数据并且加载RDB文件。
• 最后主节点再发送repl_baklog文件中的命令给从节点让他执行。

增量同步

增量同步：从节点只更新与主节点有差异的数据，slave提交自己的offset到master，master获取repl_baklog中从offset之后的命令给slave

全量同步需要先做RDB，然后将RDB文件通过网络传输给slave，成本太高。因此除了第一次做全量同步，其它大多数时候slave与master都是做增量同步。

 

repl_backlog原理

repl_baklog文件是一个固定大小的数组，只不过数组是环形，也就是说角标到达数组末尾后，会再次从0开始读写，这样数组头部的数据就会被覆盖。

repl_baklog中会记录Redis处理过的命令日志及offset，包括master当前的offset，和slave已经拷贝到的offset：

slave与master的offset之间的差异，就是salve需要增量拷贝的数据了。

随着不断有数据写入，master的offset逐渐变大，slave也不断的拷贝，追赶master的offset：

直到数组被填满：

此时，如果有新的数据写入，就会覆盖数组中的旧数据。不过，旧的数据只要是绿色的，说明是已经被同步到slave的数据，即便被覆盖了也没什么影响。因为未同步的仅仅是红色部分。

但是，如果slave出现网络阻塞，导致master的offset远远超过了slave的offset：

如果master继续写入新数据，其offset就会覆盖旧的数据，直到将slave现在的offset也覆盖：

如果尚未同步，但是却已经被覆盖的数据。此时如果slave恢复，需要同步，却发现自己的offset都没有了，无法完成增量同步了。只能做全量同步。

3.小结

• 简述全量同步和增量同步区别？

- 全量同步：master将完整内存数据生成RDB，发送RDB到slave。后续命令则记录在repl_baklog，逐个发送给slave。
- 增量同步：slave提交自己的offset到master，master获取repl_baklog中从offset之后的命令给slave

• 什么时候执行全量同步？

- slave节点第一次连接master节点时
- slave节点断开时间太久，repl_baklog中的offset已经被覆盖时

• 什么时候执行增量同步？

- slave节点断开又恢复，并且在repl_baklog中能找到offset时
 

二.哨兵模式

1.概念

主从同步/复制的模式，当主服务器宕机后，需要手动把一台从服务器切换为主服务器，这就需要人工干预，费事费力，还会造成一段时间内服务不可用。

这不是一种推荐的方式，更多时候，我们优先考虑哨兵模式。哨兵是Redis集群架构中非常重要的一个组件，哨兵的出现主要是解决了主从复制出现故障时需要人为干预的问题。

哨兵模式是一种特殊的模式，首先Redis提供了哨兵的命令，哨兵是一个独立的进程，作为进程，它会独立运行。其原理是哨兵通过发送命令，等待Redis服务器响应，从而监控运行的多个Redis实例。

 

2.作用

集群监控：负责监控Redis master和slave进程是否正常工作。
消息通知：哨兵充当redis客户端的服务发现来源，如果故障转移发生了，通知client客户端新的master地址。
自动故障转移：如果master node挂掉了，哨兵提拔一个slave node作为主节点。

3.原理

当主节点出现故障时，由Redis Sentinel自动完成故障发现和转移，并通知应用方，实现高可用性。

• 哨兵机制建立了多个哨兵节点(进程)，共同监控数据节点的运行状况。
• 同时哨兵节点之间也互相通信，交换对主从节点的监控状况。
• 每隔1秒每个哨兵会向整个集群：Master主服务器+Slave从服务器+其他Sentinel（哨兵）进程，发送一次ping命令做一次心跳检测。

哨兵是如何判断主节点是否发生故障？两个概念：

• 主观下线：一个哨兵节点判定主节点down掉是主观下线。
• 客观下线：只有半数哨兵节点都主观判定主节点down掉，此时多个哨兵节点交换主观判定结果，才会判定主节点客观下线。

基本上哪个哨兵节点最先判断出这个主节点客观下线，就会在各个哨兵节点中发起投票机制Raft算法（选举算法），最终被投为领导者的哨兵节点完成主从自动化切换的过程。

4.故障转移过程

• 首先是一个哨兵检测到主节点的故障，即主观下线，
• 发现故障的哨兵通知其他哨兵检测这个故障节点，如果超过半数的哨兵节点认为该节点故障，即客观下线。
• 这时候哨兵内部会通过选举，在从节点中选出一个新的主节点。一般是由第一个发现故障的哨兵作为leader给剩余的节点发送命令。
• leader将某一个从节点升级为新的主节点，让其它从节点指向新的主节点，
• 若原主节点恢复也变成从节点，并指向新的主节点:
• 通知客户端主节点已经更换。

三.集群(Cluster)

1.概念

Redis 的哨兵模式基本已经可以实现高可用，读写分离 ，但是在这种模式下每台 Redis 服务器都存储相同的数据，浪费内存且有木桶效应，所以在redis3.0上加入了 Cluster 集群模式，实现了 Redis 的分布式存储，也就是说每台 Redis 节点上存储不同的内容。

Redis Cluster着眼于提高并发量。集群至少需要3主3从，且每个实例使用不同的配置文件，主从不用配置，集群会自己选。

 

2 Redis-Cluster集群的特点

•  所有的redis节点彼此互联(PING-PONG机制),内部使用二进制协议优化传输速度和带宽。
• 节点的fail是通过集群中超过半数的节点检测失效时才生效。
• 客户端与 Redis 节点直连,不需要中间代理层.客户端不需要连接集群所有节点,连接集群中任何一个可用节点即可。
• 所有的节点都是一主一从（也可以是一主多从），其中从节点不提供服务，仅作为备用
• 支持在线增加、删除节点
• 客户端可以连接任何一个主节点进行读写
   

 3.工作方式

在 Redis 的每一个节点上，都有两个东西，一个是插槽（slot），它的的取值范围是：0-16383。还有一个就是cluster，可以理解为是一个集群管理的插件。当我们的存取的 Key到达的时候，Redis 会根据 crc16的算法得出一个结果，然后把结果对 16384 求余数，这样每个 key 都会对应一个编号在 0-16383 之间的哈希槽，通过这个值，去找到对应的插槽所对应的节点，然后直接自动跳转到这个对应的节点上进行存取操作。

Redis 集群使用数据分片（sharding）而非一致性哈希（consistency hashing）来实现： 一个 Redis 集群包含 16384 个哈希槽（hash slot）， 数据库中的每个键都属于这 16384 个哈希槽的其中一个， 集群使用公式 CRC16(key) % 16384 来计算键 key 属于哪个槽， 其中 CRC16(key) 语句用于计算键 key 的 CRC16 校验和 。

集群中的每个节点负责处理一部分哈希槽。 举个例子， 一个集群可以有三个哈希槽， 其中：

节点 A 负责处理 0 号至 5500 号哈希槽。
节点 B 负责处理 5501 号至 11000 号哈希槽。
节点 C 负责处理 11001 号至 16384 号哈希槽。
这种将哈希槽分布到不同节点的做法使得用户可以很容易地向集群中添加或者删除节点。

为了保证高可用，redis-cluster集群引入了主从模式，一个主节点对应一个或者多个从节点，当主节点宕机的时候，就会启用从节点。当其它主节点ping一个主节点A时，如果半数以上的主节点与A通信超时，那么认为主节点A宕机了。如果主节点A和它的从节点A1都宕机了，那么该集群就无法再提供服务了。

3.Redis-Cluster集群的优缺点

优点

1. 解决分布式负载均衡的问题。具体解决方案是分片/虚拟槽slot。
2. 可实现动态扩容
3. P2P模式，无中心化

缺点

1. 为了性能提升，客户端需要缓存路由表信息
2. Slave在集群中充当“冷备”，不能缓解读压力