Redis哨兵模式研究

原理分析

Redis哨兵模式研究

前面说过，哨兵模式主要是为了解决节点故障问题，让 Redis 高可用的。本身并不是一个单独的模式，而是跟主从或者集群模式组合使用。

本篇研究的重点跟前面几篇保持一致：

哨兵模式的特点是什么。
哨兵模式解决了什么问题。
哨兵模式跟主从模式、集群模式的区别以及关联。
哨兵模式原理是什么。
尝试搭建一套哨兵模式的环境，进行一些测试等。
概括下哨兵模式的优缺点。

1. 哨兵模式是什么

Redis 哨兵模式 ( Redis Sentinel ) 是 Redis 官方提供的一种高可用解决方案，主要是用于监控 Redis 主从架构中的实例。

主从模式+哨兵

哨兵的核心功能有：

哨兵实例会不断的检查主从节点是否正常运行。
主节点故障时，哨兵会选举一个从节点，将它提升为主节点，并指挥从节点指向新的主节点。
哨兵会定时向客户端推送集群的状态信息，客户端根据哨兵的指示连接到正确的主节点。
哨兵可以监控集群节点的监控状况。

可以看出，哨兵模式主要功能还是让 Redis 有了自动化的高可用性，不需要人工去干预。

2. 哨兵模式原理

主要研究几个点：

哨兵是什么。
哨兵怎么去监控 Redis 节点。
哨兵怎么去判断故障、处理故障。
哨兵选举主节点的流程。

2.1 哨兵是什么

哨兵本质是就是特殊的 Redis 服务器实例，也可以说一个一个特殊的程序。这个程序是运行在哨兵模式下的，其他模式下不会运行这个程序。

2.2 哨兵怎么去监控 Redis 节点

每个哨兵会以每秒一次的频率向主节点、从节点和其他哨兵发送 PING 命令，然后其他实例正常情况下应该要回复 PONG 。

2.3 哨兵怎么去判断故障

上面说过了，哨兵会 PING 命令给其他节点，如果其他节点在超过的时间没有进行回复的话，哨兵就会将它标记为【主观下线】（SDOWN）。

当多个哨兵都认为主节点下线，即达到预设的 quorum 法定人数的时候。主节点会被标记为【客观下线】（ODOWN）。

当主节点被标记为 ODOWN 时，哨兵会启动故障处理流程。

这里的主观下线和客观下线也比较容易理解：

主观下线：单个哨兵认为某个节点不可用。
客观下线：当足够多的数量哨兵都认为主节点不可用时，它就会被标记为客观下线。

2.4 哨兵怎么去处理故障

首先哨兵节点会一起选举出一个领头的哨兵 ( Leader Sentinel )，选举的算法是 Raft 算法。选举出来的这个哨兵去负责执行故障转移操作。
领头哨兵会根据从节点的优先级、复制偏移量、延迟等指标，选择一个最合适的从节点作为新的主节点。
领头哨兵将其他从节点重新指向新的主节点 ( 这里使用 SLAVEOF no one 命令)。
领头哨兵通知所有哨兵和客户端更新配置，确保信息一致。
客户端收到哨兵发送的通知后，连接到新的主节点 ( 客户端需要订阅哨兵节点的 +switch-master 频道 )。
新的主节点会跟其他从节点进行数据同步，保证数据的一致性。数据完全同步完之后。 Redis 恢复正常工作状态。

简单总结下故障处理流程就是：

几个哨兵之间一起选举一个领头的哨兵。
领头的哨兵去从节点中挑选一个新的可用主节点。
领头哨兵提升这个新的从节点为主节点。
领头哨兵通知从节点修改指向新的主节点。
领头哨兵将新的主节点信息通知给客户端。
客户端收到通知后连接到新的主节点。

2.5 哨兵选举主节点的流程

3. 哨兵模式实践

3.1 哨兵节点部署原则

这里需要注意哨兵节点的部署通常遵循下面的原则：

至少部署3个哨兵节点
哨兵节点的数量应该是奇数

这么做的原因是是因为以下几点：

最低 3 个哨兵可以提供足够的冗余。如果只有 2 个哨兵的话，其中一个哨兵发生故障时，剩下的单个哨兵无法确定主节点是否真的下线。就像 2 个人各执一词，谁也不服谁。但是 3 个人在这种场景下必然会有 2 个人的意见一致。
奇数个哨兵个数可以在进行决策时避免出现平票情况。
上面说的 Redis 使用这种仲裁机制来决定什么时候进行故障转移。默认情况下，只有超过半数的哨兵认为主节点已经下线时，才会进行故障转移。

3.2 哨兵节点部署位置的选择

哨兵的部署位置也有 2 种方式：

哨兵部署在 Redis 节点服务器上。
单独部署在独立的服务器上。

这两种做法各有各的优缺点，对于大多数生产环境，特别是对高可用性要求较高的系统，可以将哨兵部署在独立的服务器上。

如果资源有限，可以考虑将哨兵部署在 Redis 从节点服务器上。但是不要将哨兵部署在主节点服务器上，如果部署在主节点上，主节点故障时通常也意味着哨兵也会故障。

3.3 演示

基于主从模式 + 哨兵进行演示。主从部署的节点为 1主2从，哨兵部署 3个哨兵。主从节点的部署参考之前的文章《Redis主从模式研究》。

哨兵的部署步骤：

准备好 3 台服务器，三台服务器上安装好跟主从 Reids 一模一样的版本。
在每一台哨兵 Redis 的配置目录下新建配置文件 sentinel.conf。添加如下内容：

  port 26379
  bind 0.0.0.0
  
  #   mymaster 是主节点的名字，可任意取名。主节点的 IP 为 192.168.60.1，端口为6379。2 是法定人数，当2个哨兵认为主节点下线时，才执行故障转移。
  sentinel monitor mymaster 192.168.60.1 6379 2
  
  # 5秒没有回应则认为主节点主观下线
  sentinel down-after-milliseconds mymaster 5000
  
  # 每次只允许一个从节点进行同步
  sentinel parallel-syncs mymaster 1
  
  # 故障转移超时时间为 60 秒
  sentinel failover-timeout mymaster 60000

启动哨兵

  redis-sentinel /etc/redis/sentinel.conf

注意哨兵启动的程序是不一样的。

启动完哨兵之后，客户端连接 Redis 应该通过哨兵来发现主节点的地址，而不是直接连接到Redis节点。

哨兵模式其实也没啥很多东西。直接手动停止主节点的 Redis 服务，就可以观察哨兵节点的日志输出。正常情况下，哨兵会在短时间内完成故障转移，选举出新的主节点，并重新同步好数据对外服务。

4. 哨兵模式总结

优点：

自动故障转移确保 Redis 服务持续可用。
可以部署多个哨兵，这样以提高可靠性。
客户端可以透明地处理故障转移，不需要关心这么多。有故障了哨兵会推送新的节点信息过来。

缺点：

哨兵本身就是一个程序，部署会增加系统的复杂度。
哨兵需要不断地监控和通信，对服务器资源有一定影响。

5. 哨兵模式跟主从模式、集群模式的区别以及关联

哨兵模式跟主从模式、集群模式两个模式容易搞混，它们之间有一定的关联关系，但是也有区别。

先要搞清楚哨兵模式的核心功能是为 Redis 节点提供高可用性。

主从模式则是为了可用性以及解决数据访问压力的，主节点负责处理所有写操作，从节点负责同步主节点的数据并处理读操作。不过主从模式有个致命的问题，如果主节点故障，Redis 的写操作是无法继续处理的。从节点不会自动提升为主节点，除非人工进行故障切换，这既耗时又容易出错。

这一点可以看出，主从模式的高可用性是具备的，那就是多个从节点可以具备读的高可用。但是写的高可用无法支持。

Redis 集群模式是允许将数据分布在多个节点上，设计目标是处理更大规模的数据集和更高的吞吐量。同时内置了高可用性，当一个主节点故障，集群可以自动将其从节点提升为新的主节点并继续提供服务。

集群模式看起来更加完备一点，但是部署起来更复杂。

所以可以总结出：

哨兵模式主要用于为主从架构提供高可用性，确保主节点故障时能自动切换到从节点。适用于不需要分片、但需要高可用性的应用场景。主从模式+哨兵结合起来就是完整的生产环境高可用+高性能方案。
集群模式适合大规模数据分片与存储，支持更大的数据集和更高的吞吐量。同时提供内置的高可用性。适用于需要横向扩展和高可用性的场景。

也可以按照下面的几个方面进行区分这几个模式：

数据规模：

数据量不多：主从模式
数据量中等：主从+哨兵模式
数据量很多：集群模式

高可用要求：

要求低：主从模式
要求高：主从模式+哨兵模、集群模式

部署复杂度：主从模式 < 哨兵模式 < 集群模式

运维成本：主从模式 < 哨兵模式 < 集群模式