树复制替换id_Redis高可用之复制技术原理

按照如下所示的架构图

redis复制架构

从节点2启动后的log如下所示

2542:C 01 Jul 2020 23:40:25.719 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo2542:C 01 Jul 2020 23:40:25.719 # Redis version=5.0.9, bits=64, commit=00000000, modified=0, pid=2542, just started2542:C 01 Jul 2020 23:40:25.719 # Configuration loaded2542:C 01 Jul 2020 23:40:25.719 * supervised by systemd, will signal readiness2542:S 01 Jul 2020 23:40:25.726 * Running mode=standalone, port=6379.2542:S 01 Jul 2020 23:40:25.727 # Server initialized2542:S 01 Jul 2020 23:40:25.728 * Ready to accept connections2542:S 01 Jul 2020 23:40:25.729 * Connecting to MASTER 192.168.100.2:63792542:S 01 Jul 2020 23:40:25.730 * MASTER  REPLICA sync started2542:S 01 Jul 2020 23:40:25.730 * Non blocking connect for SYNC fired the event.2542:S 01 Jul 2020 23:40:25.732 * Master replied to PING, replication can continue...2542:S 01 Jul 2020 23:40:25.733 * Partial resynchronization not possible (no cached master)2542:S 01 Jul 2020 23:40:25.735 * Full resync from master: ace84ebdf777439877a2ca70386ff8eb2bb14505:50822542:S 01 Jul 2020 23:40:25.805 * MASTER  REPLICA sync: receiving 788033 bytes from master2542:S 01 Jul 2020 23:40:25.826 * MASTER  REPLICA sync: Flushing old data2542:S 01 Jul 2020 23:40:25.827 * MASTER  REPLICA sync: Loading DB in memory2542:S 01 Jul 2020 23:40:25.859 * MASTER  REPLICA sync: Finished with success2542:S 01 Jul 2020 23:40:25.860 * Background append only file rewriting started by pid 25462542:S 01 Jul 2020 23:40:25.921 * AOF rewrite child asks to stop sending diffs.2546:C 01 Jul 2020 23:40:25.922 * Parent agreed to stop sending diffs. Finalizing AOF...2546:C 01 Jul 2020 23:40:25.922 * Concatenating 0.00 MB of AOF diff received from parent.2546:C 01 Jul 2020 23:40:25.922 * SYNC append only file rewrite performed2546:C 01 Jul 2020 23:40:25.922 * AOF rewrite: 0 MB of memory used by copy-on-write2542:S 01 Jul 2020 23:40:25.960 * Background AOF rewrite terminated with success2542:S 01 Jul 2020 23:40:25.960 * Residual parent diff successfully flushed to the rewritten AOF (0.00 MB)2542:S 01 Jul 2020 23:40:25.960 * Background AOF rewrite finished successfully

从节点2启动后,主节点的log如下所示

1419:M 01 Jul 2020 23:40:25.271 * Replica 192.168.100.4:6379 asks for synchronization1419:M 01 Jul 2020 23:40:25.271 * Full resync requested by replica 192.168.100.4:63791419:M 01 Jul 2020 23:40:25.272 * Starting BGSAVE for SYNC with target: disk1419:M 01 Jul 2020 23:40:25.272 * Background saving started by pid 24592459:C 01 Jul 2020 23:40:25.297 * DB saved on disk2459:C 01 Jul 2020 23:40:25.298 * RDB: 0 MB of memory used by copy-on-write1419:M 01 Jul 2020 23:40:25.341 * Background saving terminated with success1419:M 01 Jul 2020 23:40:25.361 * Synchronization with replica 192.168.100.4:6379 succeeded

1. redis复制技术

Redis复制技术是一种简单易用基于主从架构的高可用解决方案,它允许从节点精确无误的从主节点复制一份完整的数据,当网络故障恢复后,从节点会自动重新连接主节点,并根据数据是否过期决定从主节点执行一个全新或者部分数据的同步.

redis复制技术基于下述三种机制

• 主节点与从节点正常工作中,对主节点的数据修改命令会实时同步到从节点,同时会同步修改命令到一个额定大小的称为积压缓冲区(backlog)的内存块中,这些命令包括客户端的写入,修改等操作.

• 当主节点与从节点网络故障恢复后,主节点依旧会将修改命令同步到额定大小的积压缓冲区(backlog),从节点会自动连接主节点并尝试根据主节点的积压缓冲区中命令同步自故障后主节点更新的数据

• 当从节点发现主节点的额定大小的积压缓冲区的数据已被新数据覆盖后,会请求主节点进行一次全新的数据同步.

redis复制技术默认是异步的,低延迟的和高性能的,这就决定了redis同步数据到从节点后并不关心从节点是否确认数据已经写入,为此redis给出了一个妥协的解决方案,在redis的配置文件中加入以下参数

# min-replicas-to-write 3     //决定数据至少要写入几个从节点才认为写成功# min-replicas-max-lag 10   //如果从节点延迟超过多少秒后主节点禁止客户端再写入数据

下列是redis复制中一些重要特性

• redis的复制是异步的

• 一个redis主节点可以包含多个从节点,而且支持级联复制.级联复制的节点从原始的主节点接收数据

• redis的复制技术在主节点是非阻塞的,在和从节点同步数据过程中不影响客户端的读写

• redis的复制技术在从节点也是非阻塞的,从节点执行一个完整的初始化同步后,不仅可读,也可以写入,这个写入操作是发生在当前的从节点,对于级联复制的子节点来说是透明的,如果主从节点之间因网络故障断开,那么从节点的数据便不再是最新的,从节点是否将这些旧的数据提供给客户端查询取决于redis的配置参数replica-serve-stale-data,每次从节点从主节点重新同步数据后,从节点会用新的数据文件替换旧的数据文件,这个短暂的替换过程中会阻塞客户端连接.

• redis复制可以很方便扩容.

• redis主节点可以使用无盘复制技术,主节点没有启用数据持久化,有从节点连接时,主节点直接将内存数据传输到从节点生成rdb文件,从节点加载该文件从而达到和主节点一致状态,但是在生产环境中尽量不要使用无盘复制技术,主节点意外重启会导致数据丢失,因为没有启用数据持久化功能,主节点启动后依然会作为主节点,但是数据是空的,这时从节点复制主节点的数据,会连通从节点的数据一并清空.

2. redis复制技术入如何工作

redis复制的主节点都拥有一个复制id(Replication ID),复制id是一个41个字节的随机字符串,代表一个主节点下的数据集,同时每个主节点都有一个字节类型的复制偏移量(offset),每当主节点的数据被更新时,被更新的数据都会被转化成字节数据,复制偏移量在原来的基础上加上该字节,如当前的偏移量是1000,redis更新了三个键值,三个键值转化成字节值是120,那么当三个键值更新完成后,偏移量就是1000+120=1120.因此表示一个主节点的数据更新状态时按照如下:

Replication ID, offset

当从节点连接主节点后,从节点通过psync命令发送主节点的复制ID和从节点的复制偏移量,主节点接收到命令请求后查看从节点请求的复制偏移量,和自己的进行对比,就知道应该复制给从节点的数据范围,如果该范围在积压缓冲区(backlog)中,那么就将挤压缓冲中的如何从节点需求的数据发送给从节点,如果没有找到,那么主节点就将数据进行一次全新的同步到从节点.

关于全新同步的一些细节.

主节点开始一个后台线程将内存数据持久化到一个rdb文件,与此同时将后续的新的客户端写入命令写入到积压缓冲区中,当后台线程持久化rdb文件完成,主节点将该rdb文件传送到从节点保存,从节点再将该rdb文件数据加载到内存,主节点再将自己的积压缓冲区的写操作全部同步到从节点,等到从节点全部应用后,主从同步就算完成了.

3. 关于复制ID的介绍

在我们通过info命令查看复制信息时,发现有两个复制ID,replid2成为secondary ID

master_replid:ace84ebdf777439877a2ca70386ff8eb2bb14505           //主节点的复制idmaster_replid2:0000000000000000000000000000000000000000     //用于存储上次主实例的replid

一个复制ID代表代表一个给定的历史数据的集合,当一个节点启动成为一个主节点,或者一个从节点升级为主节点时,就会产生一个新的复制ID,从节点第一次连接主节点时会在握手时会继承主节点的复制ID,如果两个从节点记录的主节点复制ID和复制偏移量一致,那么我们可以说这两个从节点拥有相同的数据,如果从节点1的复制偏移量是1001,从节点2的复制偏移量是1009,那么从节点2的数据比从节点1的数据新.

一个节点为什么会有两个复制ID(一个secondary ID)?

当原来的主节点宕机,执行故障转移后一个从节点被提升为新的主节点,新的主节点仍然需要记录原来的主节点的复制ID,通过这种方法,当其他从节点从新的主节点同步数据时,由于看到自己连接的新的主节点的复制ID没有发生改变,那么从节点可以执行部分数据同步,而不是一个全新的数据的同步,新的主节点将自己第二个复制ID作为自己的主ID,当主ID切换时,新的主节点只要记住当前的复制偏移量即可.稍后,新的主节点将会生成一个随机的新的复制ID,因为一个新的数据产生,当有新的从节点连接时,新的主节点将从节点的复制ID,复制偏移量和自己的新的复制ID和secondary ID绑定做匹配,

当主节点宕机后,为什么新的主节点需要修改自己的复制ID呢?

这是为了防止原来的主节点故障恢复后,一些拥有和原主节点相同的复制ID的从节点可能会连接到原来的从节点,从而造成数据不一致的情况.