Redis学习笔记——Redis主从复制、哨兵模式、集群模式

1、主从复制

1、概念

• 主从复制，是指将一台Redis服务器的数据，复制到其他的Redis服务器。前者称为主节点(master/leader)，后者称为从节点(slave/follower)；数据的复制是单向的，只能由主节点到从节点。Master以写为主，Slave 以读为主。默认情况下，每台Redis服务器都是主节点；
• 一个主节点可以有多个从节点(或没有从节点)，但一个从节点只能有一个主节点。
• 主可以进行读写操作，当操作导致数据变化时会自动将数据同步给从数据库。
• 从节点一般都是只读的，并且接收主数据库同步过来的数据。
• 从节点挂了不影响其他从的读和主的读和写，重新启动后会将数据从主同步过来。
• 主挂了以后，不影响从的读，但redis不再提供写服务，主重启后redis将重新对外提供写服务。
• master挂了以后，不会在slave节点中重新选一个master。

2、作用

• 数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。
• 故障恢复：当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复；实际上是一种服务的冗余。
• 负载均衡：在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务（即写Redis数据时应用连接主节点，读Redis数据时应用连接从节点），分担服务器负载；尤其是在写少读多的场景下，通过多个从节点分担读负载，可以大大提高Redis服务器的并发量。
• 高可用（集群）基石：除了上述作用以外，主从复制还是哨兵和集群能够实施的基础，因此说主从复制是Redis高可用的基础。
• 只使用一台Redis是万万不能的（宕机），原因如下：
  • 从结构上，单个Redis服务器会发生单点故障，并且一台服务器需要处理所有的请求负载，压力较大。
  • 从容量上，单个Redis服务器内存容量有限，就算一台Redis服务器内存容量为256G，也不能将所有内存用作Redis存储内存，一般来说，单台Redis最大使用内存不应该超过20G。
  • 主从复制，读写分离！ 80% 的情况下都是在进行读操作！减缓服务器的压力！对于这种场景，我们可以使如下这种架构：
    • 

3、复制原理

• Redis 的主从同步，分为全量同步和增量同步。
• 全量同步
  • Slave启动成功连接到Master后会发送一个同步命令。
  • Master 创建并发送 RDB 给 Slave，Slave 载入并解析 RDB，同时 Master 将此阶段所产生的新的写命令存储到缓冲区。
  • Master 向 Slave 同步存储在缓冲区的写操作命令。
• 增量同步
  • 指Slave完成初始化后开始正常工作时， Master 发生的写操作同步到 Slave 的过程。
  • Master 每执行一个写命令就会向 Slave 发送相同的写命令，然后 Slave 接收并执行。

4、心跳检测机制

• 进⼊命令传播阶段后，Master 与 Slave 间需要进⾏信息交换，使用心跳机制进行维护，实现双⽅连接保持在线。

• Master心跳检测

  • 作用：判断Slave是否在线；
  • 周期：由repl-ping-slave-period决定，默认10秒；
  • 向主服务器发送INFO replication命令，可以列出Slave列表，可以看出Slave最后一次向主发送命令距离现在过了多少秒。lag的值应该在0或1之间跳动，如果超过1则说明主从之间的连接有故障。

• Slave心跳检测

  • 作用：
    • 告知 Master 自己的复制偏移量，Master 根据 Slave 的复制偏移量，在复制积压缓冲区里面找到从服务器缺少的数据，并将这些数据重新发送给从服务器。
    • 判断Master是否在线；

• 注意事项

  • 当 Slave多数掉线，或延迟过高时，Master将拒绝执行写命令，保证数据稳定性。

  • #Slave的数量少于3个
    min-slaves-to-write 3 （min-replicas-to-write 3）
    #Slave的延迟都大于等于10秒
    min-slaves-max-lag 10 （min-replicas-max-lag 10）
    

2、哨兵模式(sentinel)

1、概念

• 解决主从模式不能自动选主的问题，实现高可用
• 
• 监控redis集群的运行状况
• 三个特点：
  • 监控：不断地检查你的Master和Slave是否正常运行。
  • 提醒：当被监控地某个Redis出现问题时，哨兵可以通过API向管理员或者其他应用程序发送通知。
  • 自动故障转移：当一个Master不能正常工作时，哨兵会开始一次自动故障转移操作，它会将失效Master地其中一个Slave升级为新地Master，并且让失效的Master地其他slave改为复制新的Master；当客户端试图链接失效地Master时，集群也会向客户端返回新的Master地地址，使得集群可以使用新的Master代替失效地Master。
• sentinel模式下，客户端不直接连接Redis，而是连接哨兵，由哨兵提供具体的可提供服务的Redis实现，这样当master节点挂掉以后，sentinel就会感知并将新的master节点提供给使用者。
• 然而一个哨兵进程对Redis服务器进行监控，可能会出现问题，为此，我们可以使用多个哨兵进行监控。各个哨兵之间还会进行监控，这样就形成了多哨兵模式。
  • 

2、工作流程

• Sentinel默认每10s一次，向被监控的主服务器发送info命令，获取主服务器和其下属从服务器的信息；
• 当Sentinel发现主服务器有新的从服务器出现时，Sentinel还会向从服务器**建立命令连接和订阅连接。**在命令连接建立之后，Sentinel还是默认10s一次，向从服务器发送info命令，并记录从服务器的信息；
• 每个哨兵以每秒钟一次的频率向整个集群中的Master主服务器，Slave从服务器以及其他哨兵发送一个 PING 命令；
• 如果一个实例回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值，则这个实例会被哨兵标记为主观下线；
• 当一个Sentinel将一个Master主服务器标记为主观下线，该Sentinel会向正在监视这个Master的所有其他Sentinel以每秒一次的频率确认Master的确进入了主观下线状态；
• 当有足够数量的哨兵（大于等于配置文件指定的值）确认Master主服务器进入了主观下线状态，则Master会被标记为客观下线；
• 当Master被哨兵标记为客观下线时，监视这个主服务器的所有Sentinel会通过选举算法（raft），选出一个Leader Sentinel去执行failover（故障转移）操作；
• Sentinel向下线的Master的所有slave发送 INFO 命令的频率会从 10 秒一次改为 1 秒一次；
• 若没有足够数量的哨兵同意Master已经下线，Master的客观下线状态就会被移除； 若Master重新向哨兵的 PING 命令返回有效回复，Master的主观下线状态就会被移除；

3、选举Leader Sentinel

• 每个在线的哨兵节点都可以成为领导者，当某个Sentinel认定Master客观下线后，该Sentinel会先看看自己有没有投过票，如果自己已经投过票给其他Sentinel了，在一定时间内自己就不会成为Leader（领导者）。
• 如果该Sentinel还没投过票，那么它就成为Candidate（候选人）。
• 向其他Sentinel发命令，请求投票将自己设置为领导者，处理故障转移。
• 当其他哨兵收到此命令时，可以同意或者拒绝它成为领导者。
• 如果哨兵3发现自己在选举的票数大于等于哨兵的个数/2+1时且超过它配置的quorum，这时它就成为了Leader，如果没有超过，继续选举。
• 其他Sentinel等待Leader从Slave选出Master后，检测到新的Master正常工作后，就会去掉客观下线的标识。

4、故障转移机制

• 由哨兵节点定期监控发现主节点是否出现了故障
• 当主节点出现故障，此时所有哨兵节点共同选举了领导者哨兵，负责处理主节点的故障转移。
• 由领导者哨兵执行故障转移
  • 将失效 Master 的其中一个 Slave 升级为新的 Master，并让失效 Master 的其他 Slave 改为复制新的 Master；
  • 当客户端试图连接失效的 Master 时，集群会向客户端返回新 Master 的地址，使得集群可以使用现在的 Master 替换失效 Master 。
  • Master 主服务器的 redis.conf配置文件中会多一行 replicaof 的配置，sentinel.conf 的监控目标会随之调换。

5、选举Master策略

• 在失效Master属下的Slave中，淘汰被标记主观下线、断线或者最后一次回复PING时间大于五秒。
• 在失效Master属下的Slave中，淘汰与失效Master断开时长超过down-after选项指定的时长十倍。
• 在淘汰两次后剩下的从节点中，优先选出复制偏移量最大的Slave作为Master，如果没有区分度，则选择run_id最小的Slave作为Master。

3、集群模式

1、概念

• Redis 集群支撑多个Master，每个Master可以挂载多个Slave，Slave仅用作备份；
• Redis 集群实现了对Redis的水平扩容，即启动N个redis节点，将整个数据库分布存储在这N个节点中，每个节点存储总数据的1/N。
• Redis 集群通过分区（partition）来提供一定程度的可用性（availability）： 即使集群中有一部分节点失效或者无法进行通讯， 集群也可以继续处理命令请求。
• Redis集群由多个Redis节点组构成，依靠Gossip协议传播的集群。
  • Gossip协议是一个通信协议，一种传播消息的方式。起源于：病毒传播；
  • Gossip协议基本思想就是：
    • 一个节点周期性(每秒)随机选择一些节点，并把信息传递给这些节点。
    • 收到信息的节点会把这些信息传递给其他一些随机选择的节点。
• 优点：
  • 实现扩容
  • 分摊压力
  • 无中心配置相对简单
• 缺点：
  • 多键操作是不被支持的
  • 多键的Redis事务是不被支持的。lua脚本不被支持
  • 由于集群方案出现较晚，很多公司已经采用了其他的集群方案，而代理或者客户端分片的方案想要迁移至redis cluster，需要整体迁移而不是逐步过渡，复杂度较大。

2、slots

• Redis 集群采用slot(槽)的概念，一共分成16384个槽，每个redis节点上有一定数量的槽，基本上采用平均分配和连续分配的方式。
• 客户端路由
  • 
  • 将请求发送到任意节点，接收到请求的节点会计算槽和目标节点，如果当前节点是目标节点就执行命令，否则向客户端返回moved重定向异常；
  • 客户端接收到节点返回的结果，如果是moved异常，则从moved异常中获取目标节点的信息；
  • 客户端向目标节点发送命令，获取命令执行结果；
  • 当客户端向正确的节点发送命令时，槽及槽中数据已经被迁移到别的节点了，就会返回ask，这就是ask重定向机制
    • 
    • 客户端向目标节点发送命令，目标节点中的槽已经迁移支别的节点上了，此时目标节点会返回ask转向给客户端
    • 客户端向新的节点发送Asking命令，然后再次向新节点发送命令
    • 新节点执行命令，把命令执行结果返回给客户端
• 数据迁移
  • 
  • 向节点B发送状态变更命令，将B的对应slot 状态置为importing。
  • 向节点A发送状态变更命令，将A对应的slot 状态置为migrating。
  • 向A 发送migrate 命令，告知A 将要迁移的slot对应的key 迁移到B。
  • 当所有key 迁移完成后，cluster setslot 重新设置槽位。

3、消息机制

• meet消息：发送者会向接受者发送cluster meet命令，请求接受者将发送者加入到集群中。
• ping消息：集群中的每个节点每秒钟都会从已知节点列表选举出5个节点，然后从这5个节点中选中一个最长时间没有发送ping消息的节点作为目标节点来发送ping消息，来检测目标节点是否处于在线状态。
• pong消息：接受者接受到发送者发送的meet消息或者ping消息后，会回复pong消息，用于确认消息已经到达。
• fail消息：fail消息用于通知将某个节点置为下线状态。

4、故障检测

• 集群中的每个节点都会定期地向集群中其它节点发送ping消息，以此来检测对方是否在线。在规定时间内没有收到pong回复。则认为目标节点标记为疑似下线（PFAIL）；
• 在后续发送ping时，会带上认为疑似下线节点的pfail信息， 通知给其他节点；
• 如果集群中的半数（大于等于N/2 + 1）的主节点认为某个节点疑似下线（PFAIL），那么这个节点A将被标记为已下线（FAIL）；

5、故障转移

• 当一个从节点发现自己的主节点进入了已下线时，就会进行故障转移操作。
  • 下线的主节点的所有从节点里面，会进行选举，选举出一个新的主节点：
    • 每个从节点，都根据自己对Master复制偏移量最大的，优先进行选举；
    • 会向集群广播一条request消息，要求有投票权（负责处理槽）的主节点向这个节点进行投票；
    • 收到request消息的主节点，判断是否赞成该从节点成为新的主节点，若赞成则返回一条ack消息；
    • 从节点接收到ack消息，会将选票数加1。 如果某个从节点的选票大于等于集群中主节点的一半时（大于等于N/2 + 1），这个节点就会成为新的主节点；
    • 如果在一个配置周期内，没有一个从节点获得足够多的选票，那么集群中会进入新的配置周期，并进行选举，直到选出新的主节点为止；
  • 新的主节点向集群广播一条pong消息，通知其他节点自己变成了主节点，并且已经接管了原本由已下线节点处理的槽。
  • 新的主节点开始接受和自己负责处理的槽有关的命令请求，故障转移操作完成。