再谈Redis三种集群模式：主从模式、哨兵模式和Cluster模式-编程知识

总结经验
redis主从：可实现高并发(读)，典型部署方案：一主二从
redis哨兵：可实现高可用，典型部署方案：一主二从三哨兵
redis集群：可同时支持高可用(读与写)、高并发，典型部署方案：三主三从

一、概述

Redis 支持三种集群模式，分别为主从模式、哨兵模式和Cluster模式。

最初，Redis采用主从模式构建集群。在这种模式下，如果主节点(master)出现故障，需要手动将从节点(slave)转换为主节点。然而，这种模式在故障恢复方面效率不高。

为了提高系统的可用性，Redis引入了哨兵模式。在哨兵模式中，一个哨兵集群负责监控主节点和从节点。如果检测到主节点故障，系统可以自动将从节点晋升为新的主节点。这提高了故障恢复的自动化程度。

尽管如此，哨兵模式仍然面临内存容量和写入性能的限制，因为这种模式的写入能力仍然局限于单个节点。为了解决这一问题，Redis在3.x版本之后推出了Cluster集群模式。Cluster模式通过数据分片和节点的水平扩展，实现了更高效的内存利用和写入性能。

特性/配置	Redis 主从复制	Redis 哨兵	Redis 集群
主要目的	数据备份与读写分离	高可用性和故障自动切换	高并发和数据分散处理
架构	一个主节点和多个从节点	监控主从结构并自动切换	多个主节点，数据分片
数据复制	主节点到从节点	监控并管理主从复制	每个主节点管理自己的数据集
故障转移机制	手动或哨兵自动切换	自动故障转移	自动处理节点故障
可伸缩性	有限，依赖主节点	为主从结构增加高可用性	高，因为数据分布式处理
使用场景	数据备份和读扩展	关键应用的高可用性	大规模应用的高性能需求
设置复杂度	相对简单	中等，需配置哨兵	复杂，需规划数据分区

二、Redis 主从模式架构介绍

2.1 概要

在Redis的主从复制架构中，系统通过定义主库（master）和从库（slave）的角色，实现数据的高效同步和备份。这一架构具体包含以下特点：

master的读写能力：master是系统中的数据中心，它不仅承担全部的写操作，还能处理读请求。当在master上执行任何改变数据的操作时，这些更改会自动且实时地同步到所有slave。
单向数据流：数据同步流是单向的，意味着数据只从master流向slave，确保了数据同步的一致性和可靠性。
slave的只读特性：slave通常被配置为只读模式，它们接收并存储从master传来的数据。这样设计主要是为了分散读取压力，从而提高系统的整体读取性能。
主slave的对应关系：一个master可以对应多个slave，形成一对多的关系。这种结构利于数据的冗余备份和读取负载的分散。相反，一个slave只能对应一个master，以保持数据同步的一致性。
slave的容错性：如果某个slave出现故障，它对系统其他部分的影响是最小的。即便在slave宕机的情况下，其它slave仍能继续提供读服务，master也能保持正常的读写操作。当故障的slave恢复后，它会自动从master同步缺失的数据。
master故障的影响：master的故障会导致Redis暂时无法处理新的写请求，但已连接的slave可以继续提供读服务。一旦master恢复，Redis会重新提供完整的读写服务。
master故障的应对机制：在当前的master发生故障时，系统不会自动在slave中选择一个新的master。这需要通过额外的高可用性解决方案来实现，例如使用Redis Sentinel或Redis Cluster来管理master的选举和故障转移。

在Redis主从复制架构，Redis能够有效地提供高可用性、数据冗余以及读写分离，从而在维持高性能的同时确保数据的安全和一致性。

2.2 Redis主从复制原理

在本文档中，我们将重点介绍Redis版本2.8及其后续版本的主从复制机制。

无是哪种场景，Redis 的主从复制机制均采用异步复制，也称为乐观复制，因此不能完全保证主从数据的一致性。

不论在什么场景下，Redis的主从复制机制都采用了所谓的“异步复制”或“乐观复制”。这种复制方式意味着不能完全保证主库和从库数据的实时一致性。

Redis的主从复制机制可以根据不同的运行场景和条件采取不同的实现方式。以下是一些主要场景及其对应的复制实现和说明：

第一次启动：在从库第一次连接到主库时，将采用psync复制方式进行全量复制。这意味着从库会从头开始复制主库中的全部数据。
正常运行期间：在正常运行状态下，从库通过读取主库的缓冲区来进行增量复制。这个过程涉及复制主库上发生的新的数据变更。
从库第二次启动（主库缓冲区未溢出）：当从库重新启动且主库的缓冲区未溢出时，将通过读取主库的缓冲区进行部分复制。这种方式能够快速同步中断期间发生的数据变更，而不会对主库造成重大影响。
Redis 2.8及以上版本的从库第二次启动（针对主库）：当从库第二次启动且系统版本为Redis 2.8或以上时，将采用psync复制进行全量复制。这种情况通常发生在主库的缓冲区数据无法满足从库需要同步的数据量时。

通过上述不同的复制策略，Redis能够在保证数据备份和减少系统负载的同时，灵活应对各种运行场景。尽管异步复制机制可能导致主从数据存在短暂的不一致，但这种设计在绝大多数应用场景中已被证明是既高效又可靠的。

PS：异步复制是Redis的复制方式，而psync是实现这种复制方式的具体命令。乐观复制或乐观并发控制则是另一种与Redis的异步复制机制不同的数据库事务处理概念。不少博客或说明介绍异步复制和乐观复制是同一个概念。

2.3 PSYNC 工作原理

Redis主从复制原理图解

PSYNC 命令是Redis中用于从节点与主节点之间数据同步的关键命令。它的工作原理包括以下几个步骤：

启动或重连判断：
- 当从节点（Slave）启动或与主节点（Master）的连接断开后重连时，从节点需要确定是否曾经同步过。
- 如果从节点没有保存任何主节点的运行ID（runid），它将视为第一次连接到主节点。
第一次同步处理：
- 在第一次同步的情况下，从节点会发送 PSYNC -1 命令给主节点，请求进行全量数据同步。
- 全量同步是指主节点将其所有数据完整地复制一份给从节点。
断线重连处理：
- 对于之前已经同步过的从节点，它会发送 PSYNC runid offset 命令，其中runid是主节点的唯一标识符，offset是从节点上次同步数据的偏移量。
主节点的响应：
- 主节点接收到PSYNC命令后，会检查runid是否匹配，以及offset是否在复制积压缓冲区的范围内。
- 如果匹配且offset有效，主节点将回复CONTINUE，并发送自从节点上次断开连接以来的所有写命令。
全量同步触发条件：
- 如果runid不匹配，或offset超出了积压缓冲区的范围，主节点将通知从节点执行全量同步，回复FULLRESYNC runid offset。
复制积压缓冲区的作用：
- 主节点会在处理写命令的同时，将这些命令存入复制积压队列，同时记录队列中存放命令的全局offset。
- 当从节点断线重连，且条件允许时，它可以通过offset从积压队列中进行增量复制，而不是全量复制。
数据一致性保障：
- PSYNC机制允许从节点在网络不稳定或其他意外断开连接的情况下，能够以增量方式重新同步数据，保持主从节点数据的一致性。