redis集群之主从复制

单台redis服务器的缺点

• 如果服务器发生了宕机，由于数据恢复是需要点时间，那么这个期间是无法服务新的请求的；

• 如果这台服务器的硬盘出现了故障，可能数据就都丢失了。

要避免这种单点故障，最好的办法是将数据备份到其他服务器上，让这些服务器也可以对外提供服务，这样即使有一台服务器出现了故障，其他服务器依然可以继续提供服务。

如何保证多台redis服务器之间数据的一致性？

Redis 提供了主从复制模式，可以保证多台服务器数据一致性，且主从数据库之间采用的是读写分离的方式，主服务器可以进行读写操作，当发生写操作时自动将写操作同步给从服务器，而从服务器一般是只读，并接受主服务器同步过来写操作命令，然后执行这条命令。

对redis服务器的修改操作在主redis服务器上进行，从服务器只提供读操作

主从复制同步流程

第一次同步

通过命令：replicaof <服务器 A 的 IP 地址> <服务器 A 的 Redis 端口号> 确认哪台是主，哪台是从。
例如服务器B 执行上条命令，那么服务器B就是服务器A的从数据库。

1. 执行replicaof命令后，服务器就会给主服务器发送 psync 命令，表示要进行数据同步。psync命令包含两个参数，主服务器的id（每个服务器启动时都会随机产生一个id表示自己，由于第一次连接不知道主服务器的id，直接设为？），和复制进度offset（初始设为-1）.
2. FULLRESYNC 响应命令的意图是采用全量复制的方式，也就是主服务器会把所有的数据都同步给从服务器。
3. 主服务器会执行 bgsave 命令来生成 RDB 文件，然后把文件发送给从服务器。从服务器收到 RDB 文件后，会先清空当前的数据，然后载入 RDB 文件，主服务器生成 RDB 这个过程是不会阻塞主线程的，也就是说 Redis 依然可以正常处理命令。但是这期间的写操作命令并没有记录到刚刚生成的 RDB 文件中，这时主从服务器间的数据就不一致了，为了保证主从服务器的数据一致性，主服务器会将在 RDB 文件生成后收到的写操作命令，写入到 replication buffer 缓冲区里。
4. 主服务器发送新写操作命令给从服务器：在主服务器生成的 RDB 文件发送后，然后将 replication buffer 缓冲区里所记录的写操作命令发送给从服务器，然后从服务器重新执行这些操作。至此，主从服务器第一次同步算是完成了。
5. 主从服务器在完成第一次同步后，双方之间就会维护一个 TCP 连接。主服务器可以通过这个连接继续将写操作命令传播给从服务器，然后从服务器执行该命令，使得与主服务器的数据库状态相同。

从数据路库分摊主服务器的压力

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

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

传输 RDB 文件会占用主服务器的网络带宽，会对主服务器响应命令请求产生影响。
所以采用经理式的方法，让从数据库代理其他的从数据库

增量复制

如果主数据库和从数据库网络出现延时、断开，或者说网络分区时，此时无法同步，从数据库无法保证一致。过一段时间后，网络恢复过来后，如果再进行全量复制，那么代价太大了，所以会采用增量复制同步给从数据库。
三步骤：

1. 从服务器在恢复网络后，会发送 psync 命令给主服务器，此时的 psync 命令里的 offset 参数不是 -1；
2. 主服务器收到该命令后，然后用 CONTINUE 响应命令告诉从服务器接下来采用增量复制的方式同步数据；
3. 然后主服务将主从服务器断线期间，所执行的写命令发送给从服务器，然后从服务器执行这些命令。
4. repl_backlog_buffer，是一个「环形」缓冲区，用于主从服务器断连后，从中找到差异的数据；
5. replication offset，标记上面那个缓冲区的同步进度，主从服务器都有各自的偏移量，主服务器使用 master_repl_offset 来记录自己「写」到的位置，从服务器使用 slave_repl_offset 来记录自己「读」到的位置。