redis 哨兵与集群小结

日常学习小结，不计格式、不计内容，只做笔记之用，若有不对请留言赐教！！！

1、产生背景

哨兵

• redis主从复制结构可以实现读写分离、数据备份、宕机恢复等功能，但主节点发生故障，需要故障转移时，需要人工干预。
• 应用方无法感知redis主节点变化，主节点发生故障，应用方仍会继续向主节点发送数据。
• 人工干预会导致实时性和准确性无法保证。
  为此需要自动化故障转移策略 —— 哨兵

集群

• 当redis中数据量庞大，主节点发生故障需要故障转移，故障转移时主从节点的全量复制，会造成网络阻塞和redis进程阻塞
  为此需要数据分区，即使部分节点出现故障，也不会影响集群的正常的使用

2、实现功能

哨兵

• 监控：每个哨兵节点会定期监控redis数据节点、其他哨兵节点是否可达。
• 通知：哨兵节点会将故障转移的结果通知给应用方。
• 故障转移：实现从节点升级及后面的主从复制。
• 配置提供者：在哨兵模式中，客户端初始连接的是哨兵节点集，从中获得主节点信息。

集群

• 数据分区：根据CRC16（key）&16383算法，将数据分配到16384个虚拟slot上（建议各槽节点平均分配槽），实现负载均衡及高可用。
• 可扩展：扩容、缩容。
• 故障转移：实现从节点升级。若是一主一从，从节点多做备份之用，想要使用从节点进行读操作，需要readonly配置。（自带故障转移功能，不需要借助哨兵）

3、故障转移

哨兵

1. 每10秒，各哨兵节点会向主节点、从节点发送info命令，获取节点的拓扑信息。
2. 每2秒，各哨兵节点会向redis的数据节点的_sentinel_:hello频道发布该节点对主节点的状态判断及当前哨兵节点的信息，同时每个哨兵节点也会订阅此频道，来了解其他哨兵节点对主节点的状态判断，用于判断主节点的客观下线。
3. 每1秒，各哨兵节点会向redis数据节点、其他哨兵节点发送ping命令，检查是否可达。
4. 下线判断：若某数据节点可能下线时，哨兵节点需要经过主观下线检查、客观下线检查。注：客观下线检查只针对主节点。若有半数以上的哨兵节点认为此主节点主观下线，则此节点客观下线，进入故障转移阶段。
5. 领导者选举：进入故障转移阶段，哨兵集会选出一个领导者执行故障转移。注：哨兵节点通常为奇数个。Raft算法选出，类似zookeeper选举的思想。
6. 故障转移：在从节点列表中选着一个从节点（原则：与原主节点数据最接近的）—— 升级上面选的从节点为主节点（slaveof no one）—— 哨兵节点发送命令，将剩余从节点改为新主节点的从节点 —— 哨兵节点会将原主节点将为从节点，并监控，一旦恢复工作，使其作为新主节点的从节点

集群

• 故障发现–通信：集群中各节点互相ping/pong，实现通信，信息包括：节点槽信息、主从状态、节点故障等。
• 故障发现–主观下线1：A—> ping —> B —> pong —>A,A会记录与B的最后通信时间，A会启一个定时任务，定时将最后通信时间与配置时间比较，若大于，则判断为主观下线，广播消息。
• 故障发现–主观下线2：当消息体内含有其他节点的pfail状态会判断发送节点的内容，如果发送节点是主节点则对报告的pfail状态处理，找到pfail对应的节点结构，更新clusterNode内部下线报告链表，从节点则忽略。
• 故障发现–客观下线：下线报告列表中超过半数以上的主节点认为主观下线，则进行客观下线。若下线的是主节点，会发生故障转移。注：下线报告列表会定时清空，如果主观下线上报的速度 赶不上 下线报告清空的速度，那么永远不会客观下线
• 故障恢复–资格审查：各从节点与主节点断连的最后时间，判断是否有资格。
• 故障恢复–准备选举时间：各从节点的偏移量越大越会优先参加选举，每下个排名延迟1秒参加选举
• 故障恢复–选举、投票、替换

4、集群重新分区

根据业务需求，可能对集群进行扩容或缩容，导致了集群需要重新分区。可以用redis-trib.rb工具进行快速分区及数据迁移。重新分区会导致以下问题：

• 请求重定向：发生在扩容、缩容后，本地的槽与节点的对应关系还没更新时，同一个key对应相同的slot,访问的还是以前的节点，但是slot已经进行了重新分配，原节点没有对应的slot了，此时会返回MOVED重定向信息，包含正真slot所在的节点，客户端重定向再次访问服务端。
• ASK重定向：发生在数据迁移过程中，槽进行重新分配，数据相应会发生迁移，但迁移过程中，集群还是会提供服务，这就会发生数据可能已经迁到目标节点上了，此时访问源节点可能找不到数据，会返回ASK重定向，客户端向目标节点发起访问，有则返回，无返回nil。