我们总说的 Redis 具有高可靠性，又是什么意思呢？
其实，这里有两层含义：一是数据尽量少丢失，二是服务尽量少中断。
AOF 和 RDB 保证了前者，而对于后者，Redis 的做法就是增加副本冗余量，将一份数据同时保存在多个实例上。
即使有一个实例出现了故障，需要过一段时间才能恢复，其他实例也可以对外提供服务，不会影响业务使用。

image.png image.png image.png

当主从库断连后，主库会把断连期间收到的写操作命令，写入 replication buffer，同时也会把这些操作命令也写入 repl_backlog_buffer 这个缓冲区。

repl_backlog_buffer 是一个环形缓冲区，主库会记录自己写到的位置，从库则会记录自己已经读到的位置。

image.png

主从库的连接恢复之后，从库首先会给主库发送 psync 命令，并把自己当前的 slave_repl_offset 发给主库，主库会判断自己的 master_repl_offset 和 slave_repl_offset 之间的差距。

image.png

因为 repl_backlog_buffer 是一个环形缓冲区，所以在缓冲区写满后，主库会继续写入，此时，就会覆盖掉之前写入的操作。
如果从库的读取速度比较慢，就有可能导致从库还未读取的操作被主库新写的操作覆盖了，这会导致主从库间的数据不一致。

Redis的主从库同步的基本原理，总结来说，有三种模式：全量复制、基于长连接的命令传播，以及增量复制。

全量复制虽然耗时，但是对于从库来说，如果是第一次同步，全量复制是无法避免的，所以给你一个小建议：一个Redis实例的数据库不要太大，一个实例大小在几GB级别比较合适，这样可以减少RDB文件生成、传输和重新加载的开销。另外，为了避免多个从库同时和主库进行全量复制，给主库过大的同步压力，我们也可以采用“主-从-从”这一级联模式，来缓解主库的压力。

长连接复制是主从库正常运行后的常规同步阶段。在这个阶段中，主从库之间通过命令传播实现同步。不过，这期间如果遇到了网络断连，增量复制就派上用场了。我特别建议你留意一下repl_backlog_size这个配置参数。如果它配置得过小，在增量复制阶段，可能会导致从库的复制进度赶不上主库，进而导致从库重新进行全量复制。所以，通过调大这个参数，可以减少从库在网络断连时全量复制的风险。

不过，主从库模式使用读写分离虽然避免了同时写多个实例带来的数据不一致问题，但是还面临主库故障的潜在风险。

如果在网络断开期间，repl_backlog_size环形缓冲区写满之后，从库是会丢失掉那部分被覆盖掉的数据，还是直接进行全量复制呢？

对于这个问题来说，有两个关键点：

1. 一个从库如果和主库断连时间过长，造成它在主库repl_backlog_buffer的slave_repl_offset位置上的数据已经被覆盖掉了，此时从库和主库间将进行全量复制。

2. 每个从库会记录自己的slave_repl_offset，每个从库的复制进度也不一定相同。在和主库重连进行恢复时，从库会通过psync命令把自己记录的slave_repl_offset发给主库，主库会根据从库各自的复制进度，来决定这个从库可以进行增量复制，还是全量复制。

主从库间的数据复制同步使用的是 RDB 文件，前面我们学习过，AOF 记录的操作命令更全，相比于 RDB 丢失的数据更少。那么，为什么主从库间的复制不使用 AOF 呢？

主从全量同步使用RDB而不使用AOF的原因：

1、RDB文件内容是经过压缩的二进制数据（不同数据类型数据做了针对性优化），文件很小。而AOF文件记录的是每一次写操作的命令，写操作越多文件会变得很大，其中还包括很多对同一个key的多次冗余操作。在主从全量数据同步时，传输RDB文件可以尽量降低对主库机器网络带宽的消耗，从库在加载RDB文件时，一是文件小，读取整个文件的速度会很快，二是因为RDB文件存储的都是二进制数据，从库直接按照RDB协议解析还原数据即可，速度会非常快，而AOF需要依次重放每个写命令，这个过程会经历冗长的处理逻辑，恢复速度相比RDB会慢得多，所以使用RDB进行主从全量同步的成本最低。

2、假设要使用AOF做全量同步，意味着必须打开AOF功能，打开AOF就要选择文件刷盘的策略，选择不当会严重影响Redis性能。而RDB只有在需要定时备份和主从全量同步数据时才会触发生成一次快照。而在很多丢失数据不敏感的业务场景，其实是不需要开启AOF的。

“当主从库断连后，主库会把断连期间收到的写操作命令，写入 replication buffer，同时也会把这些操作命令也写入 repl_backlog_buffer 这个缓冲区。” 这个说法有些问题。

1、主从库连接都断开了，哪里来replication buffer呢？

2、应该不是“主从库断连后”主库才把写操作写入repl_backlog_buffer，其实只要有从库存在，这个repl_backlog_buffer就会存在。主库的所有写命令除了传播给从库之外，都会在这个repl_backlog_buffer中记录一份，缓存起来，只有预先缓存了这些命令，当从库断连后，从库重新发送psync offset，主库才能通过offset之后的增量数据给从库即可。

对repl_backlog_buffer和replication buffer的理解

1、repl_backlog_buffer：就是上面我解释到的，它是为了从库断开之后，如何找到主从差异数据而设计的环形缓冲区，从而避免全量同步带来的性能开销。如果从库断开时间太久，repl_backlog_buffer环形缓冲区被主库的写命令覆盖了，那么从库连上主库后只能乖乖地进行一次全量同步，所以repl_backlog_buffer配置尽量大一些，可以降低主从断开后全量同步的概率。而在repl_backlog_buffer中找主从差异的数据后，如何发给从库呢？这就用到了replication buffer。

2、replication buffer：Redis和客户端通信也好，和从库通信也好，Redis都需要给分配一个 内存buffer进行数据交互，客户端是一个client，从库也是一个client，我们每个client连上Redis后，Redis都会分配一个client buffer，所有数据交互都是通过这个buffer进行的：Redis先把数据写到这个buffer中，然后再把buffer中的数据发到client socket中再通过网络发送出去，这样就完成了数据交互。所以主从在增量同步时，从库作为一个client，也会分配一个buffer，只不过这个buffer专门用来传播用户的写命令到从库，保证主从数据一致，我们通常把它叫做replication buffer。

3、再延伸一下，既然有这个内存buffer存在，那么这个buffer有没有限制呢？如果主从在传播命令时，因为某些原因从库处理得非常慢，那么主库上的这个buffer就会持续增长，消耗大量的内存资源，甚至OOM。所以Redis提供了client-output-buffer-limit参数限制这个buffer的大小，如果超过限制，主库会强制断开这个client的连接，也就是说从库处理慢导致主库内存buffer的积压达到限制后，主库会强制断开从库的连接，此时主从复制会中断，中断后如果从库再次发起复制请求，那么此时可能会导致恶性循环，引发复制风暴，这种情况需要格外注意。

psync 这个动作 执行 RDB 全量数据，是直接传输到从库上，还是先落到主redis 磁盘上 ?

Redis在全量复制时，既支持先生成RDB文件，再把RDB文件传给从库，也支持在主库上直接通过socket把数据传给从库，这称为无盘复制。

如果运行主库的机器磁盘性能不太好，但是网络性能不错的话，可以考虑无盘复制。

主从复制的另一种方式：基于硬盘和无盘复制，可以通过这个参数设置： repl-diskless-sync
复制集同步策略：磁盘或者socket

新slave连接或者老slave重新连接时候不能只接收不同步，得做一个全同步，需要一个新的RDB文件dump出来，然后从master传到slave。

可以有两种情况：
1）基于硬盘（disk-backed）：master创建一个新进程dump RDB，完事儿之后由父进程（即主进程）增量传给slaves。
2）基于socket（diskless）：master创建一个新进程直接dump RDB到slave的socket，不经过主进程，不经过硬盘。

当基于 disk-backed 复制时，当 RDB 文件生成完毕，多个 replicas 通过排队来同步 RDB 文件。

当基于diskless的时候，master等待一个repl-diskless-sync-delay的秒数，如果没slave来的话，就直接传，后来的得排队等了，否则就可以一起传，适用于disk较慢，并且网络较快的时候，可以用diskless。（默认用disk-based）

环形缓冲期再大，也会出问题，那么如果遇到这类问题，导致数据不同步怎么处理？比方说，一个从库长断网以后，长时间没有联网处理。

没错，环形缓冲区再大，在某些时候，就如你所说的从库长期断网时，也会出问题。

其实从库正常情况下会每秒给主库发送一个replconf ack命令，主库会根据这个命令的达到时间判断和从库的连网情况。如果距离最后一次ack命令收到的时间已经超过了repl_timeout时间，就会和从库断开连接了。

从库再和主库连接时，会发送自己的复制进度，如果要复制内容在缓冲区中已经被覆盖了，那么就不再做增量复制了，而是进行全量复制。

主从库的复制，是异步的吗？那不就保证不了强一制了

Redis主从库的复制是异步的，主库收到命令操作后，在本地执行完成后，就会返回给客户端，并不会等到和从库同步完成后才返回给客户端。

如果从库同步较慢的话，例如从库正在执行bigkey操作，那么复制进度就会落后，此时，从库数据不是强一致性保证。

如果有两个从库正在恢复，一个正常恢复把slave_repl_offset往前推了，另一个从库在恢复的过程中又断了，但是再恢复的时候slave_repl_offset已经往前推了，中间就有一部分数据丢失了，这个情况该怎么办?

repl_backlog_buffer就是一块内存空间，被所有从库共享的，不过每个从库会记录自己的复制位置，重新同步时也会发给主库。

master_repl_offset是主库自己往repl_backlog_buffer中写入命令的偏移量，就只有一个值。

repl_backlog_buffer是所有从库共享的，而slave_repl_offset是由从库自己记录的，这也是因为每个从库的复制进度不一定相同。

从库断连后再恢复时，会给主库发送psync命令，并把自己当前的slave_repl_offset发给主库。所以，在你所说的情况下，正常恢复的从库推进的slave_repl_offset是它自己记录的，不会影响到第二个从库。

第二个从库断连后再恢复，只要slave_repl_offset指向的数据没有被覆盖，就能继续恢复。

客户端写入数据只能从主库写入，读数据可以从主库或者从库读取。请问这个是怎么控制的？

这个需要客户端实现（例如Redisson客户端），或者在客户端和集群间增加一个proxy才行，由客户端或proxy先行判断是读操作还是写操作，再把读、写操作发给从库或主库。

从库天然就是只读的吗？还是说要另外配置一下读写权限？

从Redis 2.6开始，从库默认是被设置为只读的，配置项slave-read-only 默认为yes.
Redis中RDB是默认开启的。同时，你可以在配置文件中设置appendonly yes，这样就可以把AOF也开启了。
在RDB和AOF同时开启后，在进行恢复时，会优先使用AOF进行恢复。

参考

Redis 核心技术与实战

https://time.geekbang.org/column/intro/100056701

Redis 源码剖析与实战

https://time.geekbang.org/column/intro/100084301