Redis主从服务器数据同步
一、主从架构
1.1为什么要主从架构
Redis也跟关系型数据(MySQL)一样，如果有过多请求还是撑不住的。随着请求越来越多：
- Redis的内存是有限的，可能放不下那么多的数据
- 单台Redis支持的并发量也是有限的
- 万一这台Redis挂了，所有的请求全走关系数据库了
可以多搞几台Redis服务器，做成主从来进行管理。
1.2主从架构的特点
- 主服务器负责接收写请求
- 从服务器负责接收读请求
- 从服务器的数据由主服务器复制过去。主从服务器的数据是一致的
主从架构的好处：
- 读写分离(主服务器负责写，从服务器负责读)
- 高可用(某一台从服务器挂了，其他从服务器还能继续接收请求)
- 处理更多的并发量(每台从服务器都可以接收读请求)
二、复制功能
在Redis中，用户可以通过执行SALVEOF命令或者设置salveof选项，让一个服务器去复制(replicate)另一个服务器。
复制功能分为两个操作：
- 同步(sync)：将从服务器的数据库状态更新至主服务器的数据库状态
- 命令传播(command propagate)：主服务器的数据库状态被修改，导致主从服务器的数据库状态不一致，让主从服务器的数据库状态重新回到一致状态。
2.1复制功能的具体实现
初次同步与断线后同步
Redis从2.8版本开始，使用PSYNC命令来替代SYNC命令执行复制时同步的操作。PSYNC命令具有完整重同步和部分重同步两种模式。
完整重同步
- 从服务器向主服务器发送PSYNC命令
- 收到PSYNC命令的主服务器执行BGSAVE命令，在后台生成一个RDB文件。并用一个缓冲区来记录从现在起执行的所有写命令。
- 当主服务器的BGSAVE命令执行完后，将生成的RDB文件发送给从服务器，从服务器接收和载入RBD文件。
- 主服务器将所有缓冲区的写命令发送给从服务器，从服务器执行这些写命令，达到数据最终一致性。
部分重同步
部分重同步可以让我们断线后重连只需要同步缺失的数据（而不是同步全部数据），由以下部分组成：
- 主从服务器的复制偏移量：主服务器每次传播N个字节，就将自己的复制偏移量加上N；从服务器每次收到N个字节，就将自己的复制偏移量加上N
- 主服务器的复制积压缓冲区：如果复制积压缓冲区存在丢失的偏移量的数据，那就执行部分重同步，否则执行完整重同步
- 服务器运行的ID(run ID)：如果从服务器断线之前复制的主服务器和当前连接的主服务器是两台服务器，就会进行完整重同步
2.1.3命令传播
当完成了同步之后，主从服务器就会进入命令传播阶段。从服务器默认会以每秒一次的频率，向服务器发送命令REPLCONF ACK <replication_offset>
发送这个命令主要有三个作用：
- 检测主从服务器的网络状态
- 辅助实现min-slaves选项
- 检测命令丢失