redis：主从同步总结

╰半夏微凉° 2022-09-14 15:17 186阅读 0赞

# CAP原理 #

CAP原理就好比分布式领域的牛顿定律，它是分布式存储的理论基石。自从CAP的论文发表之后，分布式存储中间件就好像雨后春笋涌现出来。

*  C：Consistent，一致性
 *  A：Availablity，可用性
 *  P：Partition tolerance，分区容忍性

**分布式系统的节点往往都是分布在不同的机器上进行网络隔离开的**，这意味着必然会有**网络断开**的风险，这个网络断开的场景的专业词汇就叫做**网络分区**

如下图所示，在网络分区发生时，两个分布式节点之间无法进行通信，我们对一个节点进行的修改操作将无法同步到另外一个节点，所以数据的**一致性**将无法满足，因为两个分布式节点的数据不再保持一直。除非我们牺牲**可用性**，也就是暂停分布式节点服务，在网络分区发生时，不同提供修改数据的功能，直到网络暂停完全恢复正常再继续对外提供服务  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_13_color_FFFFFF_t_70_g_se_x_16]  
用一句话概括CAP原理就是：**当网络分区发生时，一致性和可用性难以两全**

# 最终一致 #

redis的主从数据是异步同步的，所以分布式的redis系统并不满足**一致性**要求。当客户端在redis的主节点修改了数据后，立即返回，即使在主从网络断开的情况下，主节点依然可以正常对外提供修改服务，所以redis满足**可用性**

redis保证**最终一致性**，从节点会努力追赶从节点，最终从节点的状态会和主节点的状态保持一致。如果网络断开了，主从节点的数据将会出现大量不一致，但一旦网络修复，从节点会采用多种策略努力追赶，继续尽力保持和主节点一致。

# 主从同步和从从同步 #

redis同步支持主从同步和从从同步，如下图，从从同步是redis后继版本增加的功能，以减轻主节点的同步负担。  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_16_color_FFFFFF_t_70_g_se_x_16]

# 增量同步 #

*  redis同步的是指令流，主节点会将哪些**对自己的状态产生修改性影响的指令**记录在本地的内存buffer中，然后异步将buffer中的指令同步到从节点，从节点一边执行同步的指令流来达到和主节点一样的状态，一边向主节点反馈自己同步到哪里了（偏移量）
 *  因为内存的buffer是有限的，所以redis主节点不能将所有的指令都记录在内存buffer中。redis的复制内存buffer是一个定长的环形数组，如下图，如果数组内容满了，就会从头开始覆盖前面的内容

![在这里插入图片描述][16f1312c6e364383a3c2bc34391d1565.png]

*  如果因为网络状况不好，从节点在短时间内无法和主节点进行同步，那么当网络状况恢复时，redis的主节点中那些没有同步的指令在buffer中有可能已经被后继的指令覆盖掉了，从节点将无法直接通过指令流来进行同步，这个时候就需要用到更近复杂的同步机制------快照同步

# 快照同步 #

快照同步是一个非常耗费资源的操作，如下图所示

*  它首先需要在主节点上进行一次bgsave，将当前内存的数据全部快照到磁盘文件中，然后再将快照文件的内容全部传送到从节点
 *  从节点将快照文件接受完毕后，立即执行一次全量加载，加载之前先要将当前内存的数据清空，加载完毕后通知主节点继续进行增量同步
 *  在整个快照同步进行的过程中，主节点的复制buffer还在不停地往前移动，如果快照同步的时间过长或者复制buffer太小，都会导致同步期间的增量指令在复制buffer中被覆盖，这样就会导致快照同步完成后无法进行增量复制，然后会再次发起快照同步，如此极有可能会陷入快照同步的死循环

所以务必配置一个合适大小的buffer参数，避免快照复制的死循环  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_14_color_FFFFFF_t_70_g_se_x_16]

# 增加从节点 #

当从节点刚刚加入集群时，它必须先进行一次快照同步，同步完成后再继续进行增量同步

# 无盘复制 #

主节点在进行快照同步时，会进行很耗时的文件IO操作，在非SSD磁盘存储时，快照同步会对系统的负载产生较大影响。特别是当系统正在进行AOF的fsync操作时，如果发生快照同步，fsync将会被推迟执行，这就会严重影响主节点的服务销量。

所以从redis2.8.18开始，redis支持无盘复制。所谓**无盘复制是指主服务器直接通过套接字将快照内存发送到从节点，生成快照是一个遍历的过程，主节点会一边遍历内存，一边将序列化的内容发送到主节点，从节点还是跟以前一样，先将接收到的内存存储到磁盘文化中，再进行一次性加载**

# wait指令 #

redis的复制是异步进行的，wait指令可以让异步复制变成同步复制，确保系统的强一致性(不严格)  
![在这里插入图片描述][ee0b4571965c4eb582bd400fa0b6f32d.png]  
wait提供两个参数，第一个参数是从节点的数量N，第二个参数是时间t，以毫秒为单位。两个参数的含义是：

*  等待wait指令之间的所有写操作同步到N个从节点，最多等待时间t
 *  如果t=0，表示无限等待直到N个从节点同步完成
 *  如果此时出现了网络分区，wait指令第二个参数时间t=0，主从同步无法继续进行，wait指令会永远阻塞，redis服务器将丧失可用性

# 总结 #

主从复制是redis分布式的基础，redis的高可用离开了主从复制将无法进行。

复制功能不是必须的，如果你只用redis做缓存，就不需要从节点做备份，挂掉了重新启动一些就行。但是只要你使用了redis的持久化功能，就必须认真对待主从复制，它是系统数据安全的基础保障

[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_13_color_FFFFFF_t_70_g_se_x_16]: /images/20220828/461850470a07485f854c6c7b8bc987b6.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_16_color_FFFFFF_t_70_g_se_x_16]: /images/20220828/35b8a694e98f47de821974bcd935ac10.png
[16f1312c6e364383a3c2bc34391d1565.png]: /images/20220828/c315e89a01464e1d8973cd376c1082d3.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAT2NlYW4mJlN0YXI_size_14_color_FFFFFF_t_70_g_se_x_16]: /images/20220828/b9cda91a3c24454eb72af3745f22da86.png
[ee0b4571965c4eb582bd400fa0b6f32d.png]: /images/20220828/8e2a5f214f844eed9992080be2ad556f.png