Redis(3)--哨兵模式，集群

Redis的哨兵模式

什么是哨兵模式

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

哨兵的工作原理

每个哨兵会向其它哨兵、master、slave定时发送消息，以确认对方是否”活”着，如果发现对方在指定时间(可配置)内未回应，则暂时认为对方主观下线。若“哨兵群”中的半数sentinel，都报告某一master没响应，系统才认为该master"彻底死亡"，即客观下线。通过一定的vote算法，从剩下的slave节点中，选一台提升为master，然后自动修改相关配置。

实际上哨兵只是一个运行在特殊模式下的 Redis 服务器，你可以在启动一个普通 Redis 服务器时通过给定 --sentinel 选项来启动哨兵(sentinel)。

哨兵的任务

• 监控：哨兵(sentinel) 会不断地检查你的Master和Slave是否运作正常。
• 提醒：当被监控的某个 Redis出现问题时, 哨兵(sentinel) 可以通过 API 向管理员或者其他应用程序发送通知。
• 自动故障迁移：当一个Master不能正常工作时，哨兵(sentinel)会开始一次自动故障迁移操作,它会将失效Master的其中一个Slave升级为新的Master,并让失效Master的其他Slave改为复制新的Master;当客户端试图连接失效的Master时,集群也会向客户端返回新Master的地址,使得集群可以使用Master代替失效Master。

哨兵的作用

• 通过发送命令，让Redis服务器返回监控其运行状态，包括主服务器和从服务器。
• 当哨兵监测到master宕机，会自动将slave切换成master，然后通过发布订阅模式通知其他的从服务器，修改配置文件，让它们切换主机。

Redis集群

本篇文章对Redis集群的讲解基于Redis官方提供的Redis Cluster模型来进行。

什么是Redis集群

Redis集群提供一种方式自动将数据分布在多个Redis节点上。Redis 集群通过分区来提供一定程度的可用性： 即使集群中有一部分节点失效或者无法进行通讯， 集群也可以继续处理命令请求。

数据分片

Redis 集群使用数据分片而非一致性哈希来实现： 一个 Redis 集群包含 16384 个哈希槽， 数据库中的每个键都属于这 16384 个哈希槽的其中一个， 集群使用公式 CRC16(key) % 16384 来计算键 key 属于哪个槽。集群中的每个节点负责处理一部分哈希槽。

这种将哈希槽分布到不同节点的做法使得用户可以很容易地向集群中添加或者删除节点。 假设现在集群中有A,B,C,D四个节点，如果我们现在想将新节点E添加到集群中，只需要将A,B,C,D的某些槽移动到E就可以了。同理，如果我们要从集群中移除节点 A ， 那么集群只需要将节点 A 中的所有哈希槽移动到B,C,D ， 然后再移除空白（不包含任何哈希槽）的节点 A 就可以了。

因为将一个哈希槽从一个节点移动到另一个节点不会造成节点阻塞， 所以无论是添加新节点还是移除已存在节点， 又或者改变某个节点包含的哈希槽数量， 都不会造成集群下线。

集群的高可用性

集群支持主从复制和主节点的自动故障转移（与哨兵类似）；当任一节点发生故障时，集群仍然可以对外提供服务。

集群状态

当每个槽都被分配完毕，集群就处于上线状态，否则就处于下线状态。

ASK错误

当客户端向节点发送关于节点key的命令的时候，若发现节点key不存在于源节点的数据库且源节点正在迁移槽i，则会向客户端返回一个ASK错误。当客户端收到ASK错误后，从中读取目标节点的地址信息，并向目标节点重新发送请求。

集群方案设计

设计集群方案时，至少要考虑以下因素：

• 高可用要求：根据故障转移的原理，至少需要3个主节点才能完成故障转移，且3个主节点不应在同一台物理机上；每个主节点至少需要1个从节点，且主从节点不应在一台物理机上；因此高可用集群至少包含6个节点。
• 数据量和访问量：估算应用需要的数据量和总访问量(考虑业务发展，留有冗余)，结合每个主节点的容量和能承受的访问量(可以通过benchmark得到较准确估计)，计算需要的主节点数量。
• 节点数量限制：Redis官方给出的节点数量限制为1000，主要是考虑节点间通信带来的消耗。在实际应用中应尽量避免大集群；如果节点数量不足以满足应用对Redis数据量和访问量的要求，可以考虑：(1)业务分割，大集群分为多个小集群；(2)减少不必要的数据；(3)调整数据过期策略等。
• 适度冗余：Redis可以在不影响集群服务的情况下增加节点，因此节点数量适当冗余即可，不用太大。

Redis集群的优势

• 可以将数据自动切分到多个节点
• 当集群中的一部分节点失效或者无法进行通讯时， 仍然可以继续处理命令请求的能力

集群存在的一些不足

• 涉及多个key的操作通常是不被支持的。举例来说，当两个set映射到不同的redis实例上时，你就不能对这两个set执行交集操作。
• 涉及多个key的redis事务不能使用。
• 不能保证集群内的数据均衡。分区的粒度是key，如果某个key的值是巨大的set、list，无法进行拆分。
• 增加或删除容量也比较复杂。redis集群需要支持在运行时增加、删除节点的透明数据平衡的能力。

对Redis高可用性的总结

我们之前Redis系列的文章提到了持久化、主从复制、哨兵模式和Redis集群等概念，下面我们对其进行总结：

• 持久化：持久化是最简单的高可用方法，主要作用是数据备份，即将数据存储在硬盘，保证数据不会因进程退出而丢失。
• 复制：复制是高可用Redis的基础，哨兵和集群都是在复制基础上实现高可用的。复制主要实现了数据的多机备份，以及对于读操作的负载均衡和简单的故障恢复。缺陷：故障恢复无法自动化；写操作无法负载均衡；存储能力受到单机的限制。
• 哨兵：在复制的基础上，哨兵实现了自动化的故障恢复。缺陷：写操作无法负载均衡；存储能力受到单机的限制。
• 集群：通过集群，Redis解决了写操作无法负载均衡，以及存储能力受到单机限制的问题，实现了较为完善的高可用方案。

参考：Redis哨兵（Sentinel）模式
redis主从复制下哨兵模式—选举原理
Redis集群的原理和搭建
深入学习Redis（5）：集群
深入学习Redis（4）：哨兵