Redis复制机制

一、Redis的复制机制

在生产环境中，单个数据库实例常常存在诸如系统崩溃、网络连接闪断或突然断电等单点故障问题。与其他大多数数据库系统一样，Redis也提供了一个复制机制，使得数据能够从一个Redis服务器（master, 主实例）复制到一个或多个其他的Redis服务器（slave，从实例）。
复制不仅提高了整个系统的容错能力，还可以用来对系统进行水平扩展。在一个重读取的应用中，可以通过增加多个Redis只读从实例来减轻主实例的压力。
Redis的复制机制是Redis Cluster的基础，而Redis Cluster在此基础上提供了高可用性。

二、Redis复制机制的工作原理

当主从实例之间网络连接通畅且建立了复制关系后，主实例会把将其接收到的写入命令转发给从实例执行，以实现主从实例之间的数据同步。
在Redis的复制机制中，共有两种重新同步机制：部分重新同步和完全重新同步。
当一个Redis的从实例启动并连接到主实例时，从实例总是会尝试通过发送请求进行部分重新同步。如果主实例接受部分重新同步的请求，那么它会从从实例停止时的最后一个偏移处开始增量地进行命令同步。否则，需要进行完全重新同步。
当从实例第一次连接到它的主实例时，总是需要进行完全重新同步。在进行完全重新同步时，为了将所有的数据复制到从实例中，主实例需要将数据转储到一个RDB文件中，然后将这个文件发送给从实例。从实例接收到RDB文件后，会先将内存中的所有数据清除，再将RDB文件中的数据导入。
主实例上的复制过程完全是异步的，因此并不会阻塞服务器处理客户端的请求！
与完全重新同步相比，部分重新同步不需要从主实例中传输完整的数据转储文件。另外，将数据转储到RDB文件中会创建一个后台进程，还会有内存开销。

为避免主从实例之间的数据不一致，大多数情况下，在redis的配置文件中配置slave-read-only yes，使得服务器处于只读模式，在这种情况下，在从实例上创建一个新键或修改已有键的值时，会得到一个错误，禁止修改！

三、Redis复制机制调优

Redis调优：对Redis的关键配置参数进行优化来达到更好的Redis性能。

1. repl-backlog-size: 通过调整该参数以充分利用部分重新同步的优势来实现更好的主从复制性能。

Redis中使用replication backlog缓冲区来决定究竟是进行完全重新同步还是部分重新同步，更具体地说，在发出SLAVEOF命令后，从实例使用最后一个offset和最后一个主实例的ID向主实例发送一个部分重新同步请求。当主实例和从实例之间的连接建立后，主实例首先会检查请求中的master_replid是否与它自己的master_replid一致。然后，主实例会检查请求中的offset能否从backlog缓冲区中获取。如果offset位于backlog的范围内，那么就可以从中获取到连接断开前的所有写入命令，即意味这可以进行部分重新同步。否则，如果主实例在连接断开期间接收到的写入命令的数量超过了backlog缓冲区的容量，那么部分重新同步请求会被拒绝，此时完全重新同步会执行。
默认情况下，backlog缓冲区的大小是1MB，这个容量在连接断开期间只能容纳少量的写入命令。多数情况下，需要把这个参数调整为更高的值以满足需求。
通过在峰值期间使用INFO命令来计算master_repl_offset的变化量，可以估算backlog缓冲区的合适大小为：
t * (master_repl_offset2 - master_repl_offset1) / (t2 - t1), t is how long the disconnection may last in seconds.

2. repl-backlog-ttl:如果所有的从实例与主实例的连接全部断开，那么主实例等待多久释放backlog占用的内存，默认值为3600s.