redis的主从复制细节

复制机制的运作

master和slave的复制运作依靠三个主要的机制：

• 当一个master和slave正常连接时，master会发送一连串的命令来保持对slave的更新，以便与将自身数据集的改变同步给slave：包括客户端的写入、键的过期或被驱逐。
• 当master断开重连后，因为网络问题或是主从意识到连接超时时，slave会重新连接上master并尝试进行部分重同步：它只会尝试获取在断开连接期间内丢失的命令流。
• 当无法进行重同步时，slave会请求进行全量同步。mater需要创建数据流的快照，并将之发送给slave，之后在数据集更改时持续发送命令流到slave。

redis主从使用的异步复制，特点是高性能和低延迟。

复制的一些事实

• redis使用异步复制，slave和master之间异步确认处理的数据量
• 一个master可以拥有多个slave
• slave可以连接slave，称作subslave节点，subslave节点会从master收到完全一样的复制流
• Redis复制在master侧是非阻塞的。master可以在一个或多个slave执行初次同步或部分同步时，可以继续处理查询请求
• Redis复制在slave侧是非阻塞的。当slave进行初次同步时，可以配置使用旧数据集处理查询请求，或者当master和slave连接断开时，返回一个error给客户端。但是在进行初次同步时，从节点会删除旧数据集，同时加载新数据集，在此期间会阻塞到来的请求。4.0开始可以开启新线程删除旧的数据集，但是加载新的数据集的操作依然需要在主线程中进行并阻塞slave。
• 复制可以用在伸缩性，以便只读查询有多个slave进行，或者仅用于数据安全。
• 可以使用复制来避免master将全部数据集写入磁盘造成的开销：一种典型的技术是配置你的redis.conf以避免对磁盘进行持久化，然后连接一个slave，其配置为不定期保存或是启用AOF。但是这个设置必须小心处理，因为重新启动的master程序从一个空数据集开始：如果一个slave试图与它同步，那么这个slave的数据也会被清空。

master持久化关闭时，复制的安全性

在使用Redis复制功能时，强烈建议在master和slave中启用持久化。当不可能时，例如非常慢的磁盘性能而导致的延迟问题，应该配置实例来避免重启后重置

为什么关闭持久化并配置了自动重启的master是危险的：

• 设置节点A为master并关闭它的持久化设置，节点B和节点C从节点A复制数据
• 节点A发生故障自动重启后，由于没有开启持久化，数据集为空
• 节点B和节点C从节点A同步数据，数据集也会被清空。

Redis复制是如何工作的

每一个Redis master都有一个Replication ID:这是一个比较大的伪随机数，用于表示一个给定的数据集。每个master节点也都持有一个偏移量，master将自己产生的复制流发送给slave时，发送过少个字节的数据，自身的偏移量就会增加多少，目的是当有新的操作修改自己的数据集时，它可以以此更新slave的状态。复制偏移量在没有一个slave的时候，也会自增。所以每个Replication ID,offset对都表示一个master 的确切版本。

• 部分同步：它们使用OSYNC命令来发送他们记录的旧的replication ID和它们至今为止的偏移量。通过这种方式master能够仅发送slave所需的增量部分。但是如果master的缓冲区没有足够的命令积压缓存记录或如果slave引用了不知道的历史记录，则会转而进行一个全量重同步：在这种情况下，slave会得到一个完整的数据副本，从头开始。
• 全量同步：master开启一个后台进程，生成一个rdb文件。同时开始缓冲所有从客户端接收到的命令。当后台保存完成时，master将数据集发送到slave，slave将数据集保存到磁盘，然后加载到内存。接着master会发送所有缓存命令给slave。这个过程以指令流的形式完成并且和Redis本身的格式相同。

无磁盘复制是直接将rdb文件通过网络发送给slave节点。

只读性质的slave

slave支持只读且默认开启，redis.conf文件中的slave-read-only变量控制这个行为，且可以在运行时通过config set开启或关闭。

设置一个slave对master进行验证

master通过requirepass设置密码，slave通过redis-cli config set masterauth 或在配置文件中添加masterauth 配置

允许只写入N个附加的副本

只有当至少n个slave连接到master时，才有可能配置master接收写查询。

因为redis使用异步复制的方式，因此无法确保slave是否实际接收到给定的写命令，因此总会有一个数据丢失窗口。工作机制：

• redis slave每秒都会ping master，确认已处理的复制流的数据量
• master会记录上次从每个slave收到ping的时间
• 用户可以配置一个最小的slave数量，使得它<=最大秒数

尽力而为的机制，条件不满足master将会恢复一个error并且写入将不被接受。

配置参数：

min-slaves-to-write <slave 数量>
min-slaves-max-lag <秒数>

Redis如何处理过期键

• 从节点不会出发键过期，相反，从节点会等待主节点触发键过期。当主节点触发键过期时，主节点会同步一个del命令给所有的从节点。
• 由于主节点控制键过期，所以从节点会存在实际已经过期的键，这是因为主节点无法及时提供del命令导致的。为了应对这种情况，在读操作下，从节点使用一个独立的时钟来标注一个键不存在，这并不会破坏数据一致性。
• 执行lua脚本期间，不执行任何键过期操作。防止key在脚本执行中间过期，保证将相同的脚本发送给slave，从而在二者的数据集产生相同的效果。

重新启动和故障转移后的部分同步

• 当一个实例在故障转移后被提升为master后，它仍能与旧master的slave进行同步。为此，slave会记住旧的master的旧的replication ID和复制偏移量。因此即使访问旧的replication ID，其也可以部分复制缓冲提供给连接的slave。
• 升级的slave的新的replication ID将不同，因为它构成了数据的不同记录，因此在被提升的slave中使用相同的replication ID将违反一对复制标识和偏移对只能标识单一数据集的规则。
• slave在关机重新启动后，能够在RDB文件中存储所需要的信息，以便与master进行同步。最好使用shutdown命令来执行slave的保存和退出。