背景
目前实现Redis高可用的模式主要有三种：主从模式、哨兵模式、集群模式。今天我们先来聊一下主从模式。
Redis 提供的主从模式，是通过复制的方式，将主服务器上的Redis的数据同步复制一份到从 Redis 服务器，这种做法很常见，MySQL通过binlog进行的主从复制也是这么做的。
主节点的Redis我们称之为master，从节点的Redis我们称之为slave，主从复制为单向复制，只能由主到从，不能由从到主。
可以有多个从节点，比如1主3从甚至n从，从节点的多少根据实际的业务需求来判断。
搭建Redis主从复制模式
Redis的主从架构中，主节点的数据更新会自动被复制到从节点，确保数据的一致性。主从复制的开启，在从节点配置和发起即可，不需要我们在主节点做任何事情。
可以通过 replicaof（Redis 5.0 之前使用 slaveof）命令形成主库和从库的关系。
主从复制原理
主从库模式开启之后，应用层面采用读写分离，所有数据的写操作只会在主库上进行，而读操作基本会在从库上进行（特殊情况下部分读业务允许走主库）。
主从会保持最终一致性：主库有了数据更新之后，会立即同步给从库，来保证主从库的数据的一致的。
主从架构如何保证数据一致性
为了保证主服务器Redis的数据和从服务器Redis的数据的一致性，也为了分担访问压力，均衡负载，应用层面一般采取读写分离的模式。
读操作：主、从库都可以执行，一般是在从库上读数据，对实时性和准确性有100%高真要求的部分业务，在谨慎评估之后也可以读主库，前提是不能给Master带来高压力和风险
主从同步实践
配置&启动master
查看主节点信息
配置&启动slave
查看从节点信息
从节点不能写入，只能读出
验证数据同步
redis-cli -h 127.0.0.1 -p 6379 // master
redis-cli -h 127.0.0.1 -p 6380 //slave
结论
默认是走RDB复制模式，PSYNC 命令是Redis中用于从节点与主节点之间数据同步的关键命令。
主从复制的好处：
-
数据冗余，实现数据的热备份
-
故障恢复，避免单点故障带来的服务不可用
-
读写分离，负载均衡。主节点负载读写，从节点负责读，提高服务器并发量
-
高可用基础，是哨兵机制和集群实现的基础
复制原理
Redis 的主从复制机制均采用异步复制，我们也称为乐观复制，这种复制方式意味着不能完全保证主库和从库数据的实时一致性。
Redis的主从复制机制可以根据不同的业务场景可以采用不同的应对方式。下面是一些主要场景及其对应的实现方案：
-
首次配置完成主从库之后的全量复制：在从库第一次连接到主库时，将采用psync复制方式进行全量复制。这意味着从库会从头开始复制主库中的全部数据。主从正常运行期间，准实时同步：在正常运行状态下，从库通过读取主库的缓冲区来进行增量复制。这个过程涉及复制主库上发生的新的数据变更。从库第二次启动（异常或主从网络断开后恢复）：Append增量数据 + 准实时同步将通过读取主库的缓冲区进行部分复制。这种方式能够快速同步中断期间发生的数据变更，而不会对主库造成重大影响。
数据同步
在主从服务器建立连接确认各自身份之后，就开始数据同步，从服务器向主服务器发送PSYNC命令，执行同步操作，并把自己的数据库状态更新至主服务器的数据库状态
Redis的主从同步分为：完整重同步（full resynchronization）和部分重同步（partial resynchronization）
全量同步
有两种情况下是完整重同步，一是slave连接上master第一次复制的时候；二是如果当主从断线，重新连接复制的时候有可能是完整重同步，这个在后面说
下面是完整重同步的步骤
-
从服务器连接主服务器，发送SYNC命令
-
主服务器接收到SYNC命名后，开始执行
bgsave命令生成RDB文件并使用缓冲区记录此后执行的所有写命令 -
主服务器
basave执行完后，向所有从服务器发送快照文件，并在发送期间继续记录被执行的写命令 -
从服务器收到快照文件后丢弃所有旧数据，载入收到的快照
-
主服务器快照发送完毕后，开始向从服务器发送缓冲区中的写命令
-
从服务器完成对快照的载入，开始接收命令请求，并执行来自主服务器缓冲区的写命令
增量同步
部分重同步是用于处理断线后重复制的情况，先介绍几个用于部分重同步的部分
-
runid(replication ID)，主服务器运行id，Redis实例在启动时，随机生成一个长度40的唯一字符串来标识当前节点 -
offset，复制偏移量。主服务器和从服务器各自维护一个复制偏移量，记录传输的字节数。当主节点向从节点发送N个字节数据时，主节点的offset增加N，从节点收到主节点传来的N个字节数据时，从节点的offset增加N -
replication backlog buffer，复制积压缓冲区。是一个固定长度的FIFO队列，大小由配置参数repl-backlog-size指定，默认大小1MB。需要注意的是该缓冲区由master维护并且有且只有一个，所有slave共享此缓冲区，其作用在于备份最近主库发送给从库的数据
当slave连接到master，会执行PSYNC <runid> <offset>发送记录旧的master的runid（replication ID）和偏移量offset，这样master能够只发送slave所缺的增量部分。但是如果master的复制积压缓存区没有足够的命令记录，或者slave传的runid(replication ID)不对，就会进行完整重同步，即slave会获得一个完整的数据集副本
PSYNC命令执行完整重同步和部分重同步的流程图
真实部署架构
总结
-
主从复制的作用一个是为分担读写压力，均衡负载，另一个是为了保证部分实例宕机之后服务的持续可用性，所以Redis演变出主从架构和读写分离。
-
主从复制的步骤包括：建立连接的阶段、数据同步的阶段、基于长连接的命令传播阶段。
-
数据同步可以分为全量复制和部分复制，全量复制一般为第一次全量或者长时间主从连接断开。
-
主从模式是比较低级的可用性优化，要做到故障自动转移，异常预警，高保活，还需要更为复杂的哨兵或者集群模式，这个后面我们继续介绍。
其他文章
Kafka消息堆积问题排查
基于SpringMVC的API灰度方案
理解到位：灾备和只读数据库
SQL治理经验谈：索引覆盖
Mybatis链路分析：JDK动态代理和责任链模式的应用
大模型安装部署、测试、接入SpringCloud应用体系
Mybatis插件-租户ID的注入&拦截应用
