在高并发服务当中，如果使用单个Redis实例，由于Redis采用单进程单线程处理所有请求的方式，即每次只有一个请求在处理，后面的请求排队，如果前面请求执行时间长了，则会影响后面所有请求。所以可以拓展到多个Redis实例，采用主从机制，一个master和多个slave，master和多个slave包含相同的数据，master负责处理写请求，slave负责读请求。Redis主从同步即是实现这种机制的，master处理完写请求后，同步给多个slave，从而保证数据的最终一致性。

实现方式

Redis的主从复制有多种实现方式：

上图表示的是一台 Master 服务器与 Slave 服务器的情况，其实一台 Master 服务器也可以对应多台 Slave 服务器，如下图所示：

另外，Slave 服务器也可以有自己的 Slave 服务器，如下图所示：

在 Redis 2.6 以后，Slave 只读模式是默认开启的，我们可以通过配置文件中的 slave-read-only 选项配置是否开启只读模式：

slave-read-only yes

配置

配置某个redis使用另外一个redis作为master也很简单，redis.conf的配置如图：

################################# REPLICATION #################################
# 配置master服务器IP和端口
# slaveof <masterip> <masterport>
# 配置master服务器访问密码
# masterauth <master-password>

另外，还可以通过redis客服端中执行slaveof {masterip} {masterport}来配置Master服务器。

通过slaveof {masterip} {masterport}命令建立主从复制关系以后，可以通过slaveof no one断开。从节点断开复制后，不会删除已有的数据，只是不再接受主节点新的数据变化。

slaveof no one

全量同步

slave启动或者slave断开重连master的时候，slave会发生SYNC命令给master，master接收到该命令后，则会通过bgsave启动一个子进程将当前时间点的master全部数据的快照写到一个文件中，然后发送给slave，slave接收到之后则清空内存，载入这些数据，步骤如下：

• slave发生SYNC命令给master，请求执行全量同步，然后slave在等待期间，根据配置（如下）可以使用旧数据响应客户端请求或者直接报错；

# directive below) it is possible to tell the slave to authenticate before
# refuse the slave request.
# When a slave loses its connection with the master, or when the replication
# is still in progress, the slave can act in two different ways:
# 1) if slave-serve-stale-data is set to 'yes' (the default) the slave will
# 2) if slave-serve-stale-data is set to 'no' the slave will reply with
slave-serve-stale-data yes

• master接收到SYNC请求后，通过BGSAVE启动一个子进程将当前数据快照写到一个快照文件；同时主进程采用一个缓冲区保存这段时间内的所有写请求；注意如果同时有多个slave发送SYNC给master，master只会执行一次BGSAVE，然后将快照文件发送给这些slaves；
• 子进程完成快照文件的写入，向slave发送这个快照文件（正常逻辑来说是子进程发送待查看源代码确认）；主进程继续采用缓冲区缓存写命令；slave接收到快照文件后，删除旧数据，载入新的快照数据，此期间会阻塞客户端的请求；
• 子进程发送快照文件完毕后，主进程将缓冲区的数据以Redis命令协议形式，如DEL、SET，发送给slave。slave载入完快照数据后，则可以开始处理客户端的请求了。同时slave接收master发送过来的缓冲区的写命令并执行；
• 此后进入增量同步（命令传播）模式，不断接收master的写请求，实现最终一致性。

以上步骤，可以通过redis日志验证：

22221:M 02 Sep 10:12:23.489 * The server is now ready to accept connections on port 6379
22221:M 02 Sep 10:13:41.537 * Slave 192.168.1.107:6379 asks for synchronization
22221:M 02 Sep 10:13:41.537 * Full resync requested by slave 192.168.1.107:6379
22221:M 02 Sep 10:13:41.537 * Starting BGSAVE for SYNC with target: disk
22221:M 02 Sep 10:13:41.538 * Background saving started by pid 22234
22234:C 02 Sep 10:13:41.544 * DB saved on disk
22234:C 02 Sep 10:13:41.544 * RDB: 0 MB of memory used by copy-on-write
22221:M 02 Sep 10:13:41.627 * Background saving terminated with success
22221:M 02 Sep 10:13:41.628 * Synchronization with slave 192.168.1.107:6379 succeeded

增量同步

增量同步即为master每接收并执行一个写命令都同步给所有的slave，slave接收到该写命令后执行对自身数据的修改从而保持与master的数据一致。

部分同步(PSYNC)

在Redis2.8+版本，Redis的slave在与master断开连接重连的时候，默认是使用新的PSYNC同步方法，而不是原来的SYNC，因为断线重连时，slave是包含有数据的，只是可能落后于master，所以没必要又进行一次全量同步。PSYNC命令如下：

PSYNC <runid> <offset> # runid:主服务器ID, offset:从服务器最后接收命令的偏移量

流程说明

从节点发送 psync 命令给主节点，runId 就是目标主节点的 ID，如果没有默认为 -1，offset 是从节点保存的复制偏移量，如果是第一次复制则为 -1.

主节点会根据 runid 和 offset 决定返回结果：

• 如果回复 +FULLRESYNC {runId} {offset} ，那么从节点将触发全量复制流程。
• 如果回复 +CONTINUE，从节点将触发部分复制。
• 如果回复 +ERR，说明主节点不支持 2.8 的 psync 命令，将使用 sync 执行全量复制。

主服务器ID

每个Redis节点在启动后都会动态分配一个唯一的40位十六进制字符串作为运行ID（run_id）。当Redis重启后，运行ID也会改变。

192.168.1.106:6379> info server
# Server
...
run_id:2d31f8a381669bc2327a5fb07902c4341e3f1d11
tcp_port:6379

当主从节点第一次复制的时候，主节点会将run_id发送给从节点，从节点断线重新连接的时候，从节点将run_id发送给主节点，主节点和当前的自身的run_id判断是否需要全量复制。

1. 当从节点发送run_id和主节点当前的run_id不相同，说明从节点在断线前和断线后的主节点不相同，需要全量复制。
2. 当从节点发送run_id和主节点当前的run_id相同，主节点根据复制偏移量和复制积压缓冲区判断是需要全量复制还是部分复制。

复制偏移量

主节点和从节点都会维护自身复制偏移量（offset），主节点在处理完命令后，会将命令的字节长度做累加并记录，统计在info replication中的master_repl_offset中。

192.168.1.106:6379> info replication
# Replication
role:master
connected_slaves:1
slave0:ip=192.168.1.107,port=6379,state=online,offset=1121,lag=1
master_repl_offset:1121
repl_backlog_active:1 # 开启复制积压缓冲区
repl_backlog_size:1048576 # 缓冲区最大长度
repl_backlog_first_byte_offset:2 # 起始偏移量，计算当前缓冲区可用范围
repl_backlog_histlen:1120 # 已保存数据的有效长度

从节点在接收到主节点发送的命令后，同样累计记录自身的偏移量，统计在info replication中的slave_repl_offset中。

192.168.1.107:6379> info replication
# Replication
role:slave
master_host:192.168.1.106
master_port:6379
master_link_status:up
master_last_io_seconds_ago:8
master_sync_in_progress:0
slave_repl_offset:1121
slave_priority:100
slave_read_only:1
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

从节点向主节点默认每隔1秒发送replconf ack {offset}命令，把自身的复制偏移量上报给主节点，主节点会保存这个从节点的复制偏移量。

在主节点的info replication中可以看到lag=1，表示主节点上次收到replconf ack命令的间隔，正常情况下应该为0或者1。

从节点上报自身偏移量判断是否丢失数据，主节点把自身的offset和从节点的offset，如果从节点丢失数据，主节点会推送数据给从节点，如果从节点的offset之后的数据不在复制积压缓冲区中，则需要全量复制否则为部分复制。

复制积压缓冲区

复制积压缓冲区是主服务器维护的一个固定长度，先进先出的队列，默认为1M大小。当主节点有连接的从节点时被创建，主节点将命令发送给从节点时，还会写入复制积压缓冲区，作为写命令的备份，并且会为队列里的每个字节记录相应的复制偏移量。

心跳机制

主从复制建立之后，主从节点之间会维护两个心跳机制。

主从节点在建立复制后，他们之间维护着长连接并彼此发送心跳命令。

心跳的关键机制如下：

• 主从都有心跳检测机制，各自模拟成对方的客户端进行通信，通过 client list 命令查看复制相关客户端信息，主节点的连接状态为 flags = M，从节点的连接状态是 flags = S。
• 主节点默认每隔 10 秒对从节点发送 ping 命令，可修改配置 repl-ping-slave-period 控制发送频率。
• 从节点在主线程每隔一秒发送 replconf ack{offset} 命令，给主节点上报自身当前的复制偏移量。
• 主节点收到 replconf 信息后，判断从节点超时时间，如果超过 repl-timeout 60 秒，则判断节点下线。

# Slaves send PINGs to server in a predefined interval. It's possible to change
# this interval with the repl_ping_slave_period option. The default value is 10
# seconds.
#
# repl-ping-slave-period 10
#
# 1) Bulk transfer I/O during SYNC, from the point of view of slave.
# 2) Master timeout from the point of view of slaves (data, pings).
# 3) Slave timeout from the point of view of masters (REPLCONF ACK pings).
#
# It is important to make sure that this value is greater than the value
# specified for repl-ping-slave-period otherwise a timeout will be detected
# every time there is low traffic between the master and the slave.
#
# repl-timeout 60

Key过期问题

我们都知道 Redis 可以通过设置 Key 的过期时间来限制 Key 的生存时间，Redis 处理 Key 过期有惰性删除和定期删除两种机制。

而在配置主从复制后，Slave 服务器就没有权限处理过期的 Key，这样的话，对于在 Master 上过期的 Key，在 Slave 服务器就可能被读取。

所以 Master 会累积过期的 Key，积累一定的量之后，发送 Del 命令到 Slave，删除 Slave 上的 Key。

如果 Slave 服务器升级为 Master 服务器 ，则它将开始独立地计算 Key 过期时间，而不需要通过 Master 服务器的帮助。

CAP理论

CAP理论为：在分布式系统中，多个节点之间只能满足CP/AP，即强一致性和高可用是不能同时满足的。Redis的主从同步是AP的，具体对高可用的强度要求，可用通过在redis.conf配置，即有至少有多少个slaves存在和至多多少秒内没响应，则才执行写请求，否则报错，配置与说明如图：默认为关闭这个特性，即master始终接收客户端写请求。

# min-slaves-to-write 3
# min-slaves-max-lag 10