Redis哨兵模式与高可用集群

Redis高可用概述

高可用是如今Web服务的一个基本诉求，它是指服务器可以正常访问的时间，衡量标准是多少时间内可以提供正常服务。在Redis层面内，不仅仅需要能正常提供服务，还需要考虑数据扩容、数据安全等。

Redis主从复制问题

主从复制是为了解决分布式系统中的单点问题，通常会把数据复制到多个副本部署到其他机器上，满足了故障恢复和负载均衡等需求。Redis也提供了这样的功能，它可以将主节点数据的改变同步给其他从节点，这样当主节点因为故障不可达，那么从节点就可以作为后备“顶”上来，并保证数据尽量不丢失，也是最终一致性的保证。同时主从复制也扩展了主节点的读能力，对于一致性要求不是那么严格的场景下，一旦主节点不能支撑住大并发量的读操作，可以使用从节点分摊主节点的读压力。

但是主从复制模式下一旦主节点出现故障，就需要手动将一个从节点晋升为主节点，同时需要修改应用方的从节点地址，还需要命令其他从节点去复制新的主节点，整个过程都需要人工的干预，如果处理不及时，那么系统很长时间都可能处于不可用状态。对于应用方来说，因为无法感知主节点的变化，必然会造成一定写数据的丢失和读数据的错误，甚至可能造成应用放服务的不可用。对于运维来说，整个故障转移过程都需要人工介入，故障转移的实时性和准确性上都无法得到保障。

Redis Sentinel架构

Redis主从复制模式下，一旦主节点出现故障不可达，需要人工干预进行故障转移，无论对Redis的应用方还是运维都带来了很大的不便。为了让一切不需要人为干预，在Redis2.8以后提供了Redis Sentinel哨兵机制来解决这个问题。

 

所以Redis 的高可用架构就分为Redis数据节点和Sentinel节点，数据节点是主节点和从节点的数据进程，保证数据的最终一致性；Sentinel节点对数据节点进行监控，当它发现节点不可达时，会对节点做下线便是。如果被标识的是主节点，他还会对其他Sentinel节点进行“协商”，当大多数Sentinel节点都认为主节点不可达时，他们会选举出一个Sentinel节点来完成自动的故障转移工作，同时还会将这个变化通知给应用方，整个过程是完全自动的，不需要人工来介入，所以这套方案很有效的解决了Redis高可用问题。

故障转移流

1）每个Sentinel节点定期监控发现主节点出现了故障

2）多个Sentinel节点对主节点故障达成一致，选举sentinel3节点作为领导者，负责此次故障转移。

3）此时Sentinel3完成整个故障转移过程故障转移后整个Redis Sentinel的变化

通过上面过程，我们就可以看出Redis Sentinel具有以下几个功能：

监控：Sentinel节点会定期检查Redis数据节点、其余Sentinel节点是否可达

通知：Sentinel节点会将故障转移的结果通知给应用方

主节点故障转移：实现从节点晋升为主节点并维护后续正确的主从关系

配置提供者：在Redis Sentinel结构中，客户端在初始化的时候连接的是Sentinel节点集合，从中获取主节点信息。

Redis Sentinel客户端连接逻辑

Sentinel节点集合具备了监控、通知、自动故障转移、配置提供者等若干功能。也就是说实际上主节点的信息就是保存在Sentinel节点，所以我们只要能正确的连接到Redis Sentinel获取到主节点信息，就能正常访问Redis。

1）获取一个可用的Sentinel

2）获取主节点信息并连接

从返回的Sentinel节点中，调用API获取主节点的信息并连接。为了防止故障转移期间主节点发送了变化，在进行第二步连接主节点之前，需要先验证一下当前节点是不是主节点

3）保持和Sentinel节点集合联系，时刻关注主节点相关信息

从上面模型来看，服务端只有在初次连接和要切换主节点的时候才需要和Sentinel节点集合进行交换来获取直接点信息，其他时间都是和以前一样。整个获取很灵活自动进行，也不需要人为的干预。

小结

Redis Sentinel哨兵模式是Redis高可用的实现，弥补了Redis主从复制的不足。但是Redis Sentinel仅仅只是解决了高可用问题，对于主节点单点写入和单节点无法扩容等问题还是没有解决，这里还需要引入Redis Cluster集群模式来解决。