1. 基础概念

主从模式（master-slave）：备份数据、负载均衡，一个主节点可以有多个从节点，一个从节点只能有一个主节点。从节点也可以有自己的从服务器，多个从服务期可以构成一个网状结构。数据复制是单向的只能从主节点到从节点。主从模式强调数据备份，读写分离，是哨兵和集群能够实施的基础也是redis高可用的基础。

作用：

1. 数据冗余：实现了数据的备份，是持久化之外的一种数据冗余的方式。
2. 故障恢复：当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复，实际上是一种服务的冗余。
3. 负载均衡：在主从复制的基础上，配合读写分离，可以由主节点提供写服务，从节点提供读服务（即写的操作时应用连接主节点，读连接从节点），分担服务器负载，尤其是在写少读多的场景下，通过多个从节点分担读负载，可以大大的提高redis的服务器并发量。
4. 读写分离：主库写，从库读，读写分离不仅可以提高服务器的负载能力，同时可以根据需求的变化，改变从库的数量。
5. 高可用的基础。

重要的点：

1. 采用异步复制。
2. 复制功能不会阻塞主服务器：即使有一个或多个从服务器正在进行初次同步，主服务器也可以继续处理命令请求。
3. 复制功能不会阻塞从服务器：只要在redis.conf文件中进行相应配置，即使从服务器正在进行初次同步，服务器也可以使用旧版本的数据集来处理命令查询。在从服务器删除旧版本数据集并载入新的数据集的这段时间内，连接请求会被阻塞。可以配置从服务器，让他和主服务器之间的链接断开时，向客户端发送一个错误。但是，当初始同步完成后，需要删除旧的数据集和加载新的数据集，在这个短暂的时间内，从服务器会阻塞连接进来的请求。
4. 复制功能可以单纯的用于数据冗余，可以通过让多个服务器处理只读命令请求来提高扩展性。
5. 关闭主服务器的持久化功能，可以让主服务器免于执行持久化操作，有从服务器执行即可。这样可以减少主服务器的写磁盘压力带来的开销。但是会有问题就是，如果主服务器一旦重启，因为主redis服务器数据为空，这时候通过主从同步可能导致从服务器上的数据也请空。

原理：

全量复制：master服务器会开启一个后台进程用于将redis中的数据生成一个rdb文件，与此同时，服务器会缓存所有接收到的来自客户端的写命令（包含增、删、改），当后台保存进程处理完毕后，会将该rdb文件传递给slave服务器，而slave服务器会将rdb文件保存在磁盘并通过读取该文件将数据加载到内存，在此之后master服务器会将在此期间缓存的命令通过redis传输协议发送给slave服务器，然后slave服务器将这些命令依次作用于自己本地的数据集上最终达到数据的一致性。

image

1. 第一阶段：主从库建立连接，协商同步的过程，主要是为全量同步做准备。（在redis 5.0 后使用replicaof命令确定主从关系）

具体步骤：从库向主库发送psync命令，表示要进行数据同步，主库根据这个命令的参数来启动复制。psync命令包含了主库的runID和复制进度offset。runID是每个redis实例启动时都会自动生成的一个随机ID，用来标示唯一实例，当主库和从库第一次复制时，因为不知道主库的ID，所以设置为？。offset，设置为-1，表示第一次复制，主库收到命令后会用FULLRESYNC响应命令带上两个参数；主库runID和主库目前的复制进度返回给从库，从库收到这个命令后，会记录这两个参数。这里需要注意，FULLRESYNC响应表示第一次复制采用全量复制，主库会把当前所有的数据都复制给从库。

2. 第二阶段：主库将所有数据复制给从库。从库收到数据后，在本地完成数据加载，这个过程依赖内存快照生成的RDB文件。

具体步骤：主库执行bgsave命令，生成RDB文件，接着将文件发给从库。从库接收到RDB文件后，会清空当前数据库，然后加载RDB文件。这是因为从库在通过replicaof命令开始和主库同步前，可能保存了其他数据，为了避免之前的数据影响，从库需要把当前数据库清空。在主库将数据同步给从库时，主库不会被阻塞，依然可以接受请求，否则redis就会中断。但是这些请求中的写操作并没有记录到刚刚生成的RDB文件中。而是记录到replication buffe中，记录RDB生成后主库收到的所有写操作，这是为了保证主从库的数据一致性。

3. 第三阶段：主库会把第二阶段执行过程中收到的新的写操作，在发送给从库。具体的操作是当主库完成RDB文件发送后，就会把replication buffer中的修改操作发给从库，从库在重新执行这些操作。这样就实现了主从同步。

增量复制：从redis 2.8版本以前，并不支持部分同步，当主从服务器之间的连接断掉之后，master服务器和slave服务器之间都是进行全量数据同步，但是从redis 2.8开始，即使主从连接中途断掉，也不需要进行全量同步，因为从这个版本开始融入了部分同步的概念。部分同步的实现依赖于在master服务器内存中给每个slave服务器维护了一份同步日志和同步标识，每个slave服务器在跟master服务器进行同步时都会携带自己的同步标识和上次同步的最后位置。当主从连接断掉之后，slave服务器隔断时间（默认1s）主动尝试和master服务器进行连接，如果从服务器携带的偏移量标识还在master服务器上的同步备份日志中，那么就从slave发送的偏移量开始继续上次的同步操作，如果slave发送的偏移量已经不再master的同步备份日志中（可能由于主从之间断掉的时间比较长或者在断掉的短暂时间内master服务器接收到大量的写操作），则必须进行一次全量更新。在部分同步过程中，master会将本地记录的同步备份日志中记录的指令依次发送给slave服务器从而达到数据一致。

image

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

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

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

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

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

2. 深入理解

当主库不进行持久化时复制的安全性

在进行主从复制设置时，强烈建议在主服务器上开启持久化，当不能这么做时，比如考虑到延迟的问题，应该将实例配置为避免自动重启。

1. 为什么不持久化的主库自动重启非常危险？
   因为主库服务器没有开启持久化自动重启后，这个时候重启了进程，data目录只有一个空数据集，从库进行复制就会清空当前的数据库，这个时候就会导致两边的数据都是空的。当在高可用系统中使用哨兵机制的时候，关闭了主库持久化，这个时候是非常危险的，比如主库可能在很短的时间内重启完成，以至于哨兵机制都没有监控到这次失败，那么就会发生这种情况。所以在只用主从复制时关闭了主服务器的持久化功能的时候都应该禁止自动重启。

为什么主从复制使用RDB而不是AOF？

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

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

为什么还有无磁盘复制模式？

Redis 默认是磁盘复制，但是如果使用比较低速的磁盘，这种操作会给主服务器带来较大的压力。Redis从2.8.18版本开始尝试支持无磁盘的复制。使用这种设置时，子进程直接将RDB通过网络发送给从服务器，不使用磁盘作为中间存储。

无磁盘复制模式：master创建一个新进程直接dump RDB到slave的socket，不经过主进程，不经过硬盘。适用于disk较慢，并且网络较快的时候。

使用repl-diskless-sync配置参数来启动无磁盘复制。

使用repl-diskless-sync-delay 参数来配置传输开始的延迟时间；master等待一个repl-diskless-sync-delay的秒数，如果没slave来的话，就直接传，后来的得排队等了; 否则就可以一起传。

从库的从库设计

通过分析主从库间第一次数据同步的过程，你可以看到，一次全量复制中，对于主库来说，需要完成两个耗时的操作：生成 RDB 文件和传输 RDB 文件。

如果从库数量很多，而且都要和主库进行全量复制的话，就会导致主库忙于 fork 子进程生成 RDB 文件，进行数据全量复制。fork 这个操作会阻塞主线程处理正常请求，从而导致主库响应应用程序的请求速度变慢。此外，传输 RDB 文件也会占用主库的网络带宽，同样会给主库的资源使用带来压力。所以就有了主-从-从的模式，这样可以以级联的形式分散到从库上。

image

一旦主从库完成了全量复制，它们之间就会一直维护一个网络连接，主库会通过这个连接将后续陆续收到的命令操作再同步给从库，这个过程也称为基于长连接的命令传播，可以避免频繁建立连接的开销。

读写分离及其中的问题

在主从复制基础上实现的读写分离，可以实现Redis的读负载均衡：由主节点提供写服务，由一个或多个从节点提供读服务（多个从节点既可以提高数据冗余程度，也可以最大化读负载能力）；在读负载较大的应用场景下，可以大大提高Redis服务器的并发量。

• 延迟与不一致问题

由于主从复制的命令传播是异步的，延迟与数据的不一致不可避免。如果应用对数据不一致的接受程度程度较低，可能的优化措施包括：优化主从节点之间的网络环境（如在同机房部署）；监控主从节点延迟（通过offset）判断，如果从节点延迟过大，通知应用不再通过该从节点读取数据；使用集群同时扩展写负载和读负载等。
在命令传播阶段以外的其他情况下，从节点的数据不一致可能更加严重，例如连接在数据同步阶段，或从节点失去与主节点的连接时等。从节点的slave-serve-stale-data参数便与此有关：它控制这种情况下从节点的表现；如果为yes（默认值），则从节点仍能够响应客户端的命令，如果为no，则从节点只能响应info、slaveof等少数命令。该参数的设置与应用对数据一致性的要求有关；如果对数据一致性要求很高，则应设置为no。

• 数据过期问题

在单机版Redis中，存在两种删除策略：

• 惰性删除：服务器不会主动删除数据，只有当客户端查询某个数据时，服务器判断该数据是否过期，如果过期则删除。
• 定期删除：服务器执行定时任务删除过期数据，但是考虑到内存和CPU的折中（删除会释放内存，但是频繁的删除操作对CPU不友好），该删除的频率和执行时间都受到了限制。

在主从复制场景下，为了主从节点的数据一致性，从节点不会主动删除数据，而是由主节点控制从节点中过期数据的删除。由于主节点的惰性删除和定期删除策略，都不能保证主节点及时对过期数据执行删除操作，因此，当客户端通过Redis从节点读取数据时，很容易读取到已经过期的数据。

Redis 3.2中，从节点在读取数据时，增加了对数据是否过期的判断：如果该数据已过期，则不返回给客户端；将Redis升级到3.2可以解决数据过期问题。