Redis高可用之战：主从架构
1 主从模式介绍
在笔者的另外两篇文章 《Redis系列：RDB内存快照提供持久化能力》、《Redis稳定性之战：AOF日志支撑数据持久化》中，我们介绍了Redis中的数据持久化技术，包括 RDB快照 和 AOF日志 。有了这两个利器，我们再也不用担心机器宕机，数据丢失了。
但是持久化技术只是解决了Redis服务故障之后，快速数据恢复的问题。宕机和数据恢复的过程中整个业务系统来说，还是有损失的，并没有根本上提升可用性问题，而且持久化技术对于Redis服务性能来说是有损的。
我们需要的是保障Redis的高可用，减少甚至避免Redis服务发生宕机的可能。
目前实现Redis高可用的模式主要有三种： 主从模式、哨兵模式、集群模式。今天我们先来聊一下主从模式。
Redis 提供的主从模式，是通过复制的方式，将主服务器上的Redis的数据同步复制一份到从 Redis 服务器，这种做法很常见，MySQL通过binlog进行的主从复制也是这么做的。
主节点的Redis我们称之为master，从节点的Redis我们称之为slave，主从复制为单向复制，只能由主到从，不能由从到主。可以有多个从节点，比如1主3从甚至n从，从节点的多少根据实际的业务需求来判断。
2 主从架构如何保证数据一致性？
为了保证主服务器Redis的数据和从服务器Redis的数据的一致性，也为了分担访问压力，均衡负载，应用层面一般采取读写分离的模式。
读操作：主、从库都可以执行，一般是在从库上读数据，对实时性和准确性有100%高真要求的部分业务，在谨慎评估之后也可以读主库，前提是不能给Master带来高压力和风险。
写操作：只在主库上写数据，写完之后将写操作指令同步到从库。
参考下图:
2.1 读写分离模式
读写分离模式的使用跟MySQL做读写分离的初衷是一样的。因为我们已经划分了主从库，而且从库的数据是由主库单向复制的。如果主从库都可以执行写指令，那么在高频并发场景下对不同的副本数据做修改，操作会具有无序性，极易导致各副本产生数据不一致，这是分布式模式的弊病。 如果非要保证数据的强一致性，Redis 需要加锁处理，或者使用队列顺序执行，这样势必降低Redis的性能，降低服务的吞吐能力，这就不是高性能Redis所能接受的。
2.2 主从复制和读写分离的意义
- 故障隔离和恢复：无论主节点或者从节点宕机，其他节点依然可以保证服务的正常运行，并可以手动或自动切换主从。
- 如果Slave库故障，则读写操作全部走到Master库中
- 如果Master库故障，则将Slave转成Master库，仅丢失Master库来不及同步到Slave的小部分数据
- 读写隔离：Master 节点提供写服务，Slave 节点提供读服务，分摊流量压力，均衡流量的负载。
- 提供高可用保障：主从模式是高可用的最基础版本，也是 sentinel 哨兵模式和 cluster 集群模式实施的前置条件。
3 搭建Redis主从复制模式
Redis的主从架构中，主节点的数据更新会自动被复制到从节点，确保数据的一致性。主从复制的开启，在从节点配置和发起即可，不需要我们在主节点做任何事情。
可以通过 replicaof（Redis 5.0 之前使用 slaveof）命令形成主库和从库的关系。在从节点开启主从复制，如下：
说明：masterip：主机IP，masterport：主机端口号
3.1 主库配置
# 设置Redis监听的IP地址和端口号，默认监听所有IP地址和6379端口
bind 0.0.0.0
# 启用保护模式，允许远程访问
protected-mode no
# 指定Redis监听的端口号
port 6380
# 增加Redis的最大内存限制，以容纳更多数据
#maxmemory 16GB 增加内存限制，根据您的服务器实际内存调整
maxmemory 20480mb
3.2 从库配置
在从服务器的配置文件中加入
replicaof <masterip> <masterport>
假设现在有主实例 （10.21.125.1:6380）、从实例 A（10.21.125.2:6379）和 从实例 B (10.21.125.3:6379)，在两个从实例上分别执行以下命令，就成为了Slave，主实例成为 Master。
# 修改为从库监听的端口号
port 6379
# 添加需要同步的主库信息
replicaof 10.21.125.1 6380
4 主从复制原理
主从库模式开启之后，应用层面采用读写分离，所有数据的写操作只会在主库上进行，而读操作基本会在从库上进行（特殊情况下部分读业务允许走主库）。
主从会保持最终一致性：主库有了数据更新之后，会立即同步给从库，来保证主从库的数据的一致的。
4.1 主从库的同步机制
Redis 的主从复制机制均采用异步复制，我们也称为乐观复制，这种复制方式意味着不能完全保证主库和从库数据的实时一致性。
Redis的主从复制机制可以根据不同的业务场景可以采用不同的应对方式。下面是一些主要场景及其对应的实现方案：
1. 首次配置完成主从库之后的全量复制：在从库第一次连接到主库时，将采用psync复制方式进行全量复制。 这意味着从库会从头开始复制主库中的全部数据。
2. 主从正常运行期间，准实时同步：在正常运行状态下，从库通过读取主库的缓冲区来进行增量复制。 这个过程涉及复制主库上发生的新的数据变更。
3. 从库第二次启动（异常或主从网络断开后恢复）： Append增量数据 + 准实时同步将通过读取主库的缓冲区进行部分复制。 这种方式能够快速同步中断期间发生的数据变更，而不会对主库造成重大影响。
PSYNC 命令是Redis中用于从节点与主节点之间数据同步的关键命令。它的工作原理包括以下几个步骤：
1. 启动或重连判断：
当从节点（Slave）启动或与主节点（Master）的连接断开后重连时，从节点需要确定是否曾经同步过。
如果从节点没有保存任何主节点的运行ID（runid），它将视为第一次连接到主节点。
2. 首次同步处理：
如果是第一次同步的情况下，从节点会发送 PSYNC -1 命令给主节点，代表请求全量数据同步。 全量同步是指主节点将其所有数据完整地Copy一份给从节点。
3. 主从重连后的处理：
对于之前已经同步过的从节点，它会发送 PSYNC runid offset 命令，其中runid是主节点的唯一标识符，offset是从节点上次同步数据的偏移量。这样本质就是增量同步。
4. 主节点响应：
主节点接收到PSYNC命令后，会检查runid是否匹配，以及offset是否在复制积压缓冲区的范围内。
如果匹配且offset有效，主节点将回复CONTINUE，并发送自从节点上次断开连接以来的所有写命令。
5. 触发全量同步的条件：
如果runid不匹配，或offset超出了积压缓冲区的范围，主节点将通知从节点执行全量同步，回复FULLRESYNC runid offset。
6. 积压缓冲区的作用：
主节点会在处理写命令的同时，将这些命令存入复制积压队列（缓冲池），同时记录队列中存放命令的全局offset。
这样做法是保证了效率。当从节点断线重连，且条件允许时（runid和offset都具备），它可以通过offset从积压队列中进行增量复制，而不是全量复制，这样复制的成本就低很多。
7. 保障数据一致性：
PSYNC机制允许从节点在网络不稳定或其他意外断开连接的情况下，能够以增量方式重新同步数据。这也是它的一大优势，那就是保持主从节点数据的一致性。
8. 什么时候启动重连工作
判断是否进行全量同步，需要考虑两个关键因素：首先，确认这是否是第一次进行数据同步；其次，检查缓存区是否已经达到或超过其容量上限。只有在是第一次同步，或者缓存区已溢出的情况下，才会执行全量同步。
4.2 1主n从的同步说明
如果你有多个从库，则在每次连接的时候需要注意一些细节，如下:
- 多个从库情况下，每个从库都会记录自己的
slave_repl_offset，各自复制的进度也不相同。 - 重连主库进行恢复时，从库会通过 psync 命令将 slave_repl_offset 告知主库，主库判断从库的状态，来决定进行增量复制，还是全量复制。
- replication buffer 和 repl_backlog 的说明
- replication buffer 是主从库在进行全量复制时，主库上用于和从库连接的客户端的 buffer
- repl_backlog_buffer 是为了支持从库增量复制，主库上用于持续保存写操作的一块专用 buffer，所有从库共享的
- 主库和从库会各自记录自己的复制进度，所以，不同的从库在进行恢复时，需要将自己的复制进度（slave_repl_offset）发给主库，主库才可以按照偏移量取数据跟它同步。
如图所示：
5 总结
- 主从复制的作用一个是为分担读写压力，均衡负载，另一个是为了保证部分实例宕机之后服务的持续可用性，所以Redis演变出主从架构和读写分离。
- 主从复制的步骤包括：建立连接的阶段、数据同步的阶段、基于长连接的命令传播阶段。
- 数据同步可以分为全量复制和部分复制，全量复制一般为第一次全量或者长时间主从连接断开。
- 主从模式是比较低级的可用性优化，要做到故障自动转移，异常预警，高保活，还需要更为复杂的哨兵或者集群模式，这个后面我们继续介绍。
