集群系列：Redis集群方案及新版实战

一.集群概述

1、为什么需要集群

1. 提高系统性能

• 在单台服务器的情况下，随着用户量的增加和数据量的增大，系统的响应时间和处理能力可能会受到限制，影响系统的性能。为了解决这个问题，可以使用集群技术将多台服务器组合在一起，共同处理用户的请求和数据，从而提高系统的性能

• 集群技术的核心思想是将任务分配到不同的服务器上，让每台服务器都参与到任务的处理中来。通过有效的负载均衡机制和任务调度算法，集群可以实现高效的任务分配和处理，从而提高系统的性能和吞吐量

1. 提高系统可靠性

• 在单台服务器的情况下，如果服务器发生故障或者停机，那么整个系统将会停止工作，用户的请求和数据也可能会丢失。为了避免这种情况，可以使用集群技术将多台服务器组合在一起，提高系统的可靠性和容错能力

• 集群技术可以通过多台服务器之间的数据备份和故障转移来保障系统的可靠性。如果其中一台服务器发生故障或者停机，其他的服务器可以接替它的工作，从而确保系统的持续运行和数据安全

2、集群是什么

1. 随着计算机应用领域的不断扩大，对于计算机系统的性能和可靠性要求也越来越高。在这种背景下，集群成为提高系统性能和可靠性的重要方式之一

2. 在集群中，通常会有一台主服务器负责任务的分配和调度，其他服务器作为从服务器负责任务的执行和处理。主服务器可以使用负载均衡机制和任务调度算法来均衡各个服务器之间的负载，从而提高集群的性能和可靠性。此外，集群还可以使用数据备份和故障转移机制来提高系统的可靠性和容错能力。如果其中一台服务器出现故障，其他服务器可以接替它的工作，确保系统的持续运行和数据安全

3. 在集群中，服务器之间的通信通常使用网络协议进行，比如TCP/IP协议、HTTP协议等。集群中的服务器可以在同一地理位置，也可以分布在不同的地理位置，它们之间可以通过Internet或专用网络进行通信

3、集群的分类

• 集群按照架构分类：主从集群、负载均衡器集群、分布式计算集群、高可用集群、容器集群、大数据集群、分布式存储集群

• 主从集群：主从集群通常使用数据库的复制机制来实现主从之间的数据同步，比如MySQL、Redis的主从复制技术，一般情况下主节点负责写，从节点负责读，主从节点数据是需要同步的

• 负载均衡器集群：负载均衡器的集群通常使用一定的负载均衡算法和技术实现请求的分流和负载均衡，比如Nginx、HAProxy、LVS等

二.Redis为什么需要集群

1. Redis需要集群主要是为了解决以下几个问题

• 容量限制：单机Redis的容量是有限的，一旦数据量达到单机容量极限，就需要将数据存储到多台机器上进行扩容

• 高可用性：单机Redis存在单点故障的问题，如果单机Redis宕机，就会导致整个系统的服务中断，因此需要使用集群来实现高可用性和容错能力

• 并发性能：单机Redis的并发性能是有限的，一旦并发访问量达到一定程度，就会出现性能瓶颈和性能下降的问题，因此需要使用集群来提高并发性能

1. Redis集群通过数据分片和数据复制的方式来实现数据存储和高可用性，具有以下优点

• 数据自动分片：Redis集群将数据自动分片存储到多台机器上，实现了数据的横向扩展，可以支持更大规模的数据存储

• 数据自动复制：Redis集群通过数据复制机制来保证数据的高可用性，即将主节点上的数据自动复制到多个从节点上，实现数据的备份和容错

• 自动故障转移：Redis集群可以自动进行故障转移，即在主节点宕机时，自动选举一个从节点作为新的主节点，保证系统的持续运行和服务的可用性

• 增强并发性能：Redis集群通过分片机制来增强并发性能，即将数据分散到多个节点上进行处理，从而避免单机性能的瓶颈问题

三.Redis三种集群模式

1、主从复制模式

1.主从复制概述

• 主从复制模式是三种模式中最简单的一种，多台Redis实例，以一台实例作为主机，其余的实例作为备份机，主机和从机的数据完全一致，主从复制提高了Redis读请求的吞吐量

• 主机支持数据的读和写操作，而从机只支持读和数据同步，客户端将数据写入主机后，由主机自动的将数据写入到从机中

• 在Redis中主从复制的同步策略有两种

  • 全量更新：复制主机所有数据到从机
  • 增量更新：仅复制主机与从机差异数据到从机

2.全量更新

• runid：主节点的runid，从节点第一次请求主节点时，主节点会将runid返回
• offset：当前数据的偏移量，执行一条命令后，主节点的偏移量会增大，从节点请求复制主节点的时候，会带上这个信息，主节点会将这个偏移量之后的数据发送给从节点

1. 原理

• 建立连接后，从节点向主节点发送psync命令，携带runid和offset请求同步，如果是第一次同步那么runid为空，offset为-1
• 主节点接收到psync请求后，发现runid为空，offset为-1，则知道从节点希望是全量更新，会将自己的runid和offset返回给从节点，从节点进行保存
• 主节点执行bgsave，生成rdb文件，在此期间如果主机有写入操作那么会放入到一个环形缓冲区中
• 主节点将生成后的rdb文件，传输给从节点
• 从节点收到rdb文件后，会先清除自己的所有数据，然后将rdb文件加载到内存中
• 全量更新结束之后将环形缓存区中的所有写操作发送给从节点进行同步

1. 注意事项

• 全量复制期间，主节点和从节点之间的网络连接是处于阻塞状态的，也就是说，主节点和从节点之间不能进行其他操作，直到全量复制完成为止
• 全量复制的优点是同步数据完整、准确，但是其缺点是需要占用大量的网络带宽和主节点的内存空间，在大规模集群中使用全量复制可能会对系统性能造成较大的影响。因此Redis在全量复制之后，还提供了增量复制（Incremental Resynchronization）的方式来进一步保证数据同步和性能

1. 全量复制期间如果有数据写入处理方式

• Redis会在全量复制期间开启一个复制缓冲区，将主节点接收到的写入操作暂存到缓冲区中。当全量复制结束后，Redis会将复制缓冲区中的所有写入操作发送给从节点，使从节点与主节点的数据保持一致。需要注意的是，如果在全量复制过程中写入操作较多，缓冲区可能会耗尽内存，从而影响Redis的性能和稳定性。
• 为了避免全量复制期间写入操作对Redis的性能和稳定性产生影响，一些Redis集群部署方案通常采用以下的方法
  • 对写入操作进行限流，避免写入操作过多导致缓冲区耗尽内存
  • 使用高可用方案，保证Redis主节点的高可用性，当主节点发生故障时能够快速切换到备用节点
  • 使用增量复制方案，将全量复制和增量复制相结合，减少数据同步时间和带宽占用

3.增量更新

1. 原理

• 从节点向主节点发送psync命令，携带已保存的runid和offset
• 主节点判断runid是否和自己的runid一致，如果不一致则执行全量更新，一致则判断offset
• 因为环形缓冲区是一个环形结构，若master的offset一直追加，会将slave未备份的一部分给覆盖，所以主节点判断从节点的offset是否在环形缓冲区内，如果不在则执行全量更新
• 如果在环形缓存区内，那么会将offset往后一直到环形队列底部的数据，全部同步给从节点，从节点执行命令保存数据到内存中。因为主节点采用的是异步处理，所以主从节点的数据不是强一致性的

1. 注意

   • 增量复制只会传输主节点与从节点之间差异的部分数据，从而减少了网络带宽的占用和主节点内存的消耗。但是，增量复制的缺点是需要额外的内存空间来保存主节点的复制缓存，因此可能会对主节点的内存占用和性能产生影响

2. 客户端写入数据到主机后同步流程

• 当主节点接收到写入操作时，Redis会将这些操作缓存到复制缓冲区中，等待下一次从节点请求增量复制时一次性发送给从节点
• 因此，在Redis主从节点之间进行数据同步时，并不一定会使用增量复制，具体是使用全量复制还是增量复制，取决于具体的同步策略和实现方式

1. 增量复制时机

• Redis增量复制的具体实现是基于主从节点之间的心跳机制和复制缓冲区的数据大小来确定的。当从节点接收到主节点的心跳消息时，会向主节点发送REPLCONF ACK 命令，其中offset表示从节点上次接收到主节点发送的复制偏移量。主节点在接收到ACK命令后，会检查从节点的复制偏移量，如果从节点复制偏移量小于主节点当前复制偏移量，则会将主节点的复制缓冲区中的数据发送给从节点，完成增量复制

• Redis增量复制的请求频率不是固定的，而是根据主从节点之间的数据同步情况而定。如果从节点上次接收到主节点发送的复制偏移量比较旧，或者从节点的复制缓冲区中的数据比较少，那么从节点会更频繁地向主节点发送心跳消息，并请求增量复制。如果从节点的复制缓冲区中的数据比较多，或者从节点与主节点之间的网络连接较慢或不稳定，那么从节点可能会减少向主节点发送心跳消息的频率，以避免网络带宽的占用和数据同步的延迟

• 一般情况下，Redis主从节点之间的增量复制请求频率较高，可以实现较实时的数据同步。同时，Redis增量复制的性能和效率也取决于主从节点之间的网络连接质量、硬件配置和数据量等因素

3.主从复制优缺点

1. 优点

• 提高了Redis的可扩展性：通过使用Redis主从复制，可以将读操作分摊到从节点上，从而减轻主节点的压力，提高Redis的读性能，同时也增加了Redis的水平扩展能力
• 提高了Redis的可用性：通过将主节点的数据复制到多个从节点上，可以在主节点发生故障时，切换到某个从节点，从而保证Redis的高可用性
• 分离了读写操作：将读操作分离到从节点上，可以避免读写操作的冲突，提高Redis的并发处理能力和数据一致性

1. 缺点

• 主节点宕机之后需要手动切换主机
• 多个从节点宕机恢复后，大量的SYNC同步操作会导致主节点IO压力倍增
• 延迟和数据不一致问题：Redis主从复制是异步复制，从节点与主节点之间存在一定的延迟，因此可能会存在数据不一致的问题，如主节点写入的数据还未同步到从节点，从节点就返回给客户端了
• 从节点的容错性较差：Redis从节点无法处理写操作，因此从节点发生故障时，只能选择重新启动或者重新配置，无法自动恢复
• 从节点数量的限制：Redis从节点数量的限制主要是由网络带宽和性能限制所限，因此从节点数量较多时，可能会导致网络拥塞和性能下降的问题

2、哨兵模式

1.哨兵模式概述

• 主从复制模式当主节点宕机以后，需要手动将一台从节点切换到主节点，这个时候就需要人工干预，不仅麻烦还会造成一段时间内服务不可用，这时候就需要哨兵模式

• Redis哨兵模式是在Redis 2.8版本中引入的。在此版本之前，Redis只提供了主从复制来实现高可用性和数据备份。但是，主从复制存在单点故障的问题，当主节点宕机时整个系统将无法提供服务。因此，Redis引入了哨兵模式来解决这个问题，使得Redis服务具备更高的可用性和数据一致性

• 哨兵模式的核心还是主从模式，只不过在主从模式的基础上增加了一个竞选机制，如果主节点宕机了，那么从所有的从节点中选出新的主节点。竞选机制的实现依赖于在系统中启动一个sentinel进程

• sentinel会监控所有节点是否正常运行，通过发出命令返回监控节点的状态，在多sentinel模式下，sentinel之间也会互相监控

• 故障切换：当哨兵监测到master宕机，会自动将slave切换成master，然后通过发布订阅模式通知其他的从服务器，修改配置文件，让它们切换master。同时那台有问题的旧主也会变为新主的从，也就是说当旧的主即使恢复时，并不会恢复原来的主身份，而是作为新主的一个从

2.单哨兵模式

• 单哨兵模式就是只启动一个sentinel进程，用于监控主从节点，但是sentinel本身也有单点故障的问题，所以一般都会采取多哨兵模式

3.多哨兵模式

• 多哨兵模式下，不仅会监控所有的主从节点，哨兵之间也会相互监控，每一个哨兵都是一个独立的进程，独立运行
• 一般而言，哨兵都是配置为多台，并且是单数，3台、5台、7台等，因为这涉及到一个竞选机制，如果是偶数可能会产生票数平均的情况

4.哨兵模式实现原理

1. 监控：当哨兵启动时，会监控所有的主从节点，并且保证哨兵集群能够正常通信，这个阶段称为监控阶段

• ping：哨兵节点启动后所有哨兵每隔1S会互相发送ping心跳，来检测其他哨兵节点是否正常

• info：哨兵节点启动后每隔10S会向所有的主节点发送info指令，得到runid、role、各个slave的详细信息。再根据slave信息发送info指令获取slave的详细信息，会得到runid、role、master_host、master_port、offset...

• pub/sub：每个哨兵节点每隔2S会在一个指定频道发布当前节点保存的主节点信息，其他哨兵节点会订阅该频道获取信息

1. 通知：当哨兵发现主节点或者从节点出现故障时，当前哨兵会通知其他哨兵，其他哨兵挨个发送ping命令来到出故障的redis节点，如果redis节点没有响应则哨兵集群认为此节点出现故障，我们把这个阶段称为哨兵通知阶段

• 哨兵监控slave
  • 在哨兵集群中，如果某一个哨兵节点发现某个从节点出现故障后，会将其标记为+sdown，并发布订阅告知给其他哨兵节点，其他哨兵节点收到通知后会将次从节点剔除，并标记为+sdown&