【Redis】三种集群模式——主从复制、哨兵、Cluster

Redis三种集群模式——主从复制、哨兵、Cluster

传统的单机部署

优点：

• 架构简单，部署方便
• 高性价比，缓存使用时无需备用节点，当然为了满足业务的高可用性，也可以牺牲一个备用节点，但同时刻只有一个实例对外提供服务
• 高性能

缺点：

• 不保证数据的可靠性
• 在缓存使用，进程重启后，数据丢失，即使有备用的节点解决高可用性，但仍然不能解决缓存预热问题，因此不适合数据可靠性要求高的业务
• 高性能受限于单核CPU的处理能力（Redis是单线程机制），CPU为主要瓶颈，所以适合操作命令简单，排序、计算较少的场景。也可以考虑用Memcached替代。

主从复制模式

Redis的主从机制：主负责读写，从一般只读不能写（客户端）。

主从结构图

主从具体工作机制为（全量复制(初始化)+增量复制）：

• slave启动后，向master发送SYNC命令，master接收到SYNC命令后通过bgsave保存快照（即上文所介绍的RDB持久化），并使用缓冲区记录保存快照这段时间内执行的写命令；
• master将保存的快照文件发送给slave，并继续记录执行的写命令；
• slave接收到快照文件后，加载快照文件，载入数据；
• master快照发送完后开始向slave发送缓冲区的写命令，slave接收命令并执行，完成复制初始化；
• 此后master每次执行一个写命令都会同步发送给slave，保持master与slave之间数据的一致性。

优点：

• master能自动将数据同步到slave，可以进行读写分离，分担master的读压力；
• master、slave之间的同步是以非阻塞的方式进行的，同步期间，客户端仍然可以提交查询或更新请求。

缺点：

1. 不具备自动容错与恢复功能，master或slave的宕机都可能导致客户端请求失败，需要等待机器重启或手动切换客户端IP才能恢复；
2. master宕机，如果宕机前数据没有同步完，则切换IP后会存在数据不一致的问题；
3. 难以支持在线扩容，Redis的容量受限于单机配置

哨兵模式

由于无法进行主动恢复，因此主从模式衍生出了哨兵模式。哨兵模式基于主从复制模式，只是引入了哨兵来监控与自动处理故障。

哨兵顾名思义，就是来为Redis集群站哨的，一旦发现问题能做出相应的应对处理。其功能包括：

• 监控master、slave是否正常运行；
• 当master出现故障时，能自动将一个slave转换为master；
• 多个哨兵可以监控同一个Redis，哨兵之间也会自动监控。

优点：

• 哨兵模式基于主从复制模式，所以主从复制模式有的优点，哨兵模式也有。
• 哨兵模式下，master挂掉可以自动进行切换，系统可用性更高。

缺点：

• 同样也继承了主从模式难以在线扩容的缺点，Redis的容量受限于单机配置。
• 需要额外的资源来启动sentinel进程，实现相对复杂一点，同时slave节点作为备份节点不提供服务。

Cluster模式（分区分片模式）

哨兵模式解决了主从复制不能自动故障转移，达不到高可用的问题，但还是存在难以在线扩容，Redis容量受限于单机配置的问题，因此就诞生了集群模式。

要实现一个Redis集群，可以有三种方式：客户端实现、Proxy代理层、服务端实现。

1. 客户端实现

   

   这样的访问方式都通过代码来维护集群以及访问路径，可是这样的方式 维护难度大，也不支持动态扩容，因为一切都以代码实现访问规划。

2. Proxy代理层

   

   可见Codis是一个很完善的集群管理实现，我们可以不关心具体分片规则，程序开发容易简单，可是这样也有它的一些缺点：

   • 相对单机、主从、哨兵可以看到，原先可以直接访问Redis，现在由于多了一层Proxy，所有访问要经过Proxy中转，性能下降。
   • 我们需要依赖以及配置额外的插件(中间件)，增加了系统复杂度。

3. 服务端实现

   服务端的实现方式就是标准的集群(分区分片)模式，Redis Cluster是Redis在3.0版本后推出的分布式解决方案。

Redis Cluster采用无中心结构,它的特点如下：

• 所有的redis节点彼此互联(ping-pong机制),内部使用二进制协议优化传输速度和带宽。
• 节点的fail是通过集群中超过半数的节点检测失效时才生效。
• 客户端与redis节点直连,不需要中间代理层.客户端不需要连接集群所有节点,连接集群中任何一个可用节点即可。

Cluster 工作机制：

• 在Redis的每个节点上，都有一个插槽（slot），总共16384个哈希槽，取值范围为0-16383。如下图所示，跟前三种模式不同，Redis不再是默认有16(0-15)个库，也没有默认的0库说法，而是采用Slot的设计(一个集群有多个主从节点，一个主从节点上会分配多个Slot槽，每个槽点上存的是Key-Value数据):

  

• 当我们存取key的时候，Redis会根据CRC16的算法得出一个结果，然后把结果对16384求余数，这样每个key都会对应一个编号在0-16383之间的哈希槽，通过这个值，去找到对应的插槽所对应的节点，然后直接自动跳转到这个对应的节点上进行存取操作。如图所示：

  

• 为了保证高可用，Cluster模式也引入主从复制模式，一个主节点对应一个或者多个从节点，当主节点宕机的时候，就会启用从节点。

• 当其它主节点ping一个主节点A时，如果半数以上的主节点与A通信超时，那么认为主节点A宕机了。如果主节点A和它的从节点都宕机了，那么该集群就无法再提供服务了

Slot槽

Redis Cluster采用分区规则是键根据哈希函数(CRC16[key]&16383)映射到0－16383槽内，共16384个槽位，每个节点维护部分槽及槽所映射的键值数据。哈希函数: Hash()=CRC16[key]&16383

Gossip通信协议

节点之间采用Gossip协议进行通信，Gossip协议就是指节点彼此之间不断通信交换信息，当主从角色变化或新增节点，彼此通过ping/pong进行通信知道全部节点的最新状态并达到集群同步。

Gossip协议的主要职责就是信息交换，信息交换的载体就是节点之间彼此发送的Gossip消息，常用的Gossip消息有ping消息、pong消息、meet消息、fail消息：

• meet消息：用于通知新节点加入，消息发送者通知接收者加入到当前集群，meet消息通信完后，接收节点会加入到集群中，并进行周期性ping pong交换
• ping消息：集群内交换最频繁的消息，集群内每个节点每秒向其它节点发ping消息，用于检测节点是在在线和状态信息，ping消息发送封装自身节点和其他节点的状态数据；
• pong消息：当接收到ping meet消息时，作为响应消息返回给发送方，用来确认正常通信，pong消息也封闭了自身状态数据；
• fail消息：当节点判定集群内的另一节点下线时，会向集群内广播一个fail消息

优点：

• 无中心架构；
• 数据按照slot存储分布在多个节点，节点间数据共享，可动态调整数据分布；
• 可扩展性：可线性扩展到1000多个节点，节点可动态添加或删除；
• 高可用性：部分节点不可用时，集群仍可用。通过增加Slave做standby数据副本，能够实现故障自动failover，节点之间通过gossip协议交换状态信息，用投票机制完成Slave到Master的角色提升；
• 降低运维成本，提高系统的扩展性和可用性。

缺点：

• Client实现复杂，驱动要求实现Smart Client，缓存slots mapping信息并及时更新，提高了开发难度，客户端的不成熟影响业务的稳定性。目前仅Jedis Cluster相对成熟，异常处理部分还不完善，比如常见的“max redirect exception”。
• 节点会因为某些原因发生阻塞（阻塞时间大于clutser-node-timeout），被判断下线，这种failover是没有必要的。
• 数据通过异步复制，不保证数据的强一致性。
• 多个业务使用同一套集群时，无法根据统计区分冷热数据，资源隔离性较差，容易出现相互影响的情况。
• Slave在集群中充当“冷备”，不能缓解读压力，当然可以通过SDK的合理设计来提高Slave资源的利用率。
• Key批量操作限制，如使用mset、mget目前只支持具有相同slot值的Key执行批量操作。对于映射为不同slot值的Key由于Keys不支持跨slot查询，所以执行mset、mget、sunion等操作支持不友好。
• Key事务操作支持有限，只支持多key在同一节点上的事务操作，当多个Key分布于不同的节点上时无法使用事务功能。
• Key作为数据分区的最小粒度，不能将一个很大的键值对象如hash、list等映射到不同的节点。
• 不支持多数据库空间，单机下的redis可以支持到16个数据库，集群模式下只能使用1个数据库空间，即db 0。
• 复制结构只支持一层，从节点只能复制主节点，不支持嵌套树状复制结构。
• 避免产生hot-key，导致主库节点成为系统的短板。
• 避免产生big-key，导致网卡撑爆、慢查询等。
• 重试时间应该大于cluster-node-time时间。
• Redis Cluster不建议使用pipeline和multi-keys操作，减少max redirect产生的场景。

参考链接：https://www.cnblogs.com/jing99/p/12651186.html