本文主要是介绍Redis系列4-主从复制，对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

Redis的持久化技术AOF 和 RDB保证了即使在服务器重启的情况下也不会丢失数据（或少量损失），不过，由于数据都是存储在一台服务器上，

• 如果服务器发生了宕机，由于数据恢复是需要点时间，那么这个期间是无法服务新的请求的；
• 如果这台服务器的硬盘出现了故障，可能数据就都丢失了。

为了避免这种情况，最好的办法是将数据备份到其他服务器上，让这些服务器也可以对外提供服务，这样即使有一台服务器出现了故障，其他服务器依然可以继续提供服务。
Redis 提供了主从复制模式，来避免上述的问题。
这个模式可以保证多台服务器的数据一致性，且主从服务器之间采用的是「读写分离」的方式。
主服务器可以进行读写操作，当发生写操作时自动将写操作同步给从服务器，而从服务器一般是只读，并接受主服务器同步过来写操作命令，然后执行这条命令。

原理

Redis 主从复制大体可以分为三个阶段：

1. 建立连接阶段： 建立链接、协商同步
2. 数据同步阶段：主服务器同步数据给从服务器
3. 命令传播阶段：主服务器发送新写操作命令给从服务器
   

第一次同步

我们可以使用 replicaof（Redis 5.0 之前使用 slaveof）命令形成主服务器和从服务器的关系。

# 服务器 B 执行这条命令  B为从服务器
replicaof <服务器 A 的 IP 地址> <服务器 A 的 Redis 端口号>

建立连接

执行了replicaof命令后，从服务器就会给主服务器发送 psync 命令，表示要进行数据同步。

psync 命令包含两个参数，分别是主服务器的 runID 和复制进度 offset。

• runID，每个 Redis 服务器在启动时都会自动生产一个随机的 ID 来唯一标识自己。当从服务器和主服务器第一次同步时，因为不知道主服务器的 run ID，所以将其设置为 "?"。

• offset，表示复制的进度，第一次同步时，其值为 -1。

主服务器收到 psync 命令后，会用 FULLRESYNC 作为响应命令返回给对方。
并且这个响应命令会带上两个参数：主服务器的 runID 和主服务器目前的复制进度 offset。从服务器收到响应后，会记录这两个值。
FULLRESYNC 响应命令的意图是采用全量复制的方式，也就是主服务器会把所有的数据都同步给从服务器。

所以，第一阶段的工作是为了全量复制做准备。

那具体怎么全量同步呀呢？我们可以往下看第二阶段。

数据同步

1. 接着，主服务器会执行 bgsave 命令来生成 RDB 文件，然后把文件发送给从服务器。

2. 从服务器收到 RDB 文件后，会先清空当前的数据，然后载入 RDB 文件。

这里有一点要注意，主服务器生成 RDB 这个过程是不会阻塞主线程的，也就是说 Redis 依然可以正常处理命令。
但是这期间的写操作命令并没有记录到刚刚生成的 RDB 文件中，这时主从服务器间的数据就不一致了。

3. 那么为了保证主从服务器的数据一致性，主服务器会将在 RDB 文件生成后收到的写操作命令，写入到 replication buffer 缓冲区里。

命令传播

在主服务器生成的 RDB 文件发送后，然后将 replication buffer 缓冲区里所记录的写操作命令发送给从服务器，然后从服务器重新执行这些操作

拓扑结构

• 一主一从：最简单的拓扑结构，一般适用于没有太大的并发场景。当 master 宕机时，slave 提供故障转移支持
• 一主多从：适用于并发量较大的场景，一般都是读多写少，客户端可以将读命令发送到 salve 节点分担 master 节点压力。实现读写分离架构，当然也保证了高可用。但是该架构需要避免复制风暴。
• 树状结构：slave 节点除了在 master 复制数据，也可以在其他 slave 节点复制数据。主要是通过引用复制中间层，降低 master 节点的负载和需要传送给从节点的数据量，这种架构可以避免复制风暴，但是延长了数据一致性。

复制风暴

在前面的分析中，我们可以知道主从服务器在第一次数据同步的过程中，主服务器会做两件耗时的操作：生成 RDB 文件和传输 RDB 文件。

主服务器是可以有多个从服务器的，如果从服务器数量非常多，而且都与主服务器进行全量同步的话，就会带来两个问题：

• 由于是通过 bgsave 命令来生成 RDB 文件的，那么主服务器就会忙于使用 fork() 创建子进程，如果主服务器的内存数据非大，在执行 fork() 函数时是会阻塞主线程的，从而使得 Redis 无法正常处理请求；

• 传输 RDB 文件会占用主服务器的网络带宽，会对主服务器响应命令请求产生影响。

总结

主从复制共有三种模式：全量复制、基于长连接的命令传播、增量复制。

主从服务器第一次同步的时候，就是采用全量复制，此时主服务器会两个耗时的地方，分别是生成 RDB 文件和传输 RDB 文件。为了避免过多的从服务器和主服务器进行全量复制，可以把一部分从服务器升级为「经理角色」，让它也有自己的从服务器，通过这样可以分摊主服务器的压力。

第一次同步完成后，主从服务器都会维护着一个长连接，主服务器在接收到写操作命令后，就会通过这个连接将写命令传播给从服务器，来保证主从服务器的数据一致性。

如果遇到网络断开，增量复制就可以上场了，不过这个还跟 repl_backlog_size 这个大小有关系。

如果它配置的过小，主从服务器网络恢复时，可能发生「从服务器」想读的数据已经被覆盖了，那么这时就会导致主服务器采用全量复制的方式。所以为了避免这种情况的频繁发生，要调大这个参数的值，以降低主从服务器断开后全量同步的概率。

这篇关于Redis系列4-主从复制的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！