Redis-主从同步(有备无患-解决单点故障)

CAP

CAP原理就好比分布式领域的牛顿定律，它是分布式理论的基石。
原理简单讲解：
C - Consistent， 一致性
A - Availability ，可用性
P - Partition tolerance，分区容忍性
分布式系统的节点往往是分布在不同的机器上进行网络隔离开的，这必然会有网络断开的风险，那么这个网络断开的场景叫做网络分区。
当网络分区发生时，两个分布式节点之间无法进行通信，对一个节点进行修改的操作无法同步到另外一份节点，则数据一致性无法满足。除非牺牲可用性，即暂停分布式节点服务，在发生网络分区时，不在对外提供修改数据的功能，直至网络恢复正常。如下图：

主从复制.png

画外音：当网络分区发生时，一致性和可用性两难全。

最终一致性

Redis的主从数据是异步同步的，则分布式的Redis是不满足一致性要求的。当客户端在主节点上修改了数据，立即返回，即使发生网络分区，主节点依旧可以对外提供服务，所以Redis是满足可用性的。
Redis保持最终一致性，从节点努力的追赶主节点，最终从节点与主节点的状态保持一致。如果发生了网络分区，主从节点将出现大量的不一致性，当网络恢复后，从节点会以各种策略追赶主节点，最终保持与主节点一致。

主从同步

• 增量同步
  Redis同步的是指令流，主节点会将那些对自己的状态发生修改的指令记录在本地的内存buffer中，然后异步将buffer中指令同步到从节点，从节点一边执行同步来的指令流来达到与主节点保持一致，一边向主节点反馈自己同步的偏移位置。
  由于buffer的容量是有限的，则主节点不能将所有的指令全部记录下来。buffer是个定长的环形数组，满了之后，会从头开始覆盖前面的指令内容。
  根据上述描述，会发生这样的场景，网络分区期间，从节点无法同步到主节点内的指令，主节点发生的修改指令记录到buffer中，可能发生覆盖，则从节点无法直接通过指令流来不同，这个时候就该--快照同步登场了。

  
  
  buffer.png

• 快照同步
  主节点进行依稀bgsave,将内存的数据全部快照到磁盘文件中(dump.rpd)，然后再将快照文件同步给从节点。从节点接收到快照文件完毕后，先将本地的数据清空，再全量加载快照文件，家在完毕后再进行增量同步。
  根据上述描述，有种极端场景会发生，快照同步中，主节点的buffer还在不停的往前移动，如果同步快照的时间较长而这时buffer满了，就发生了覆盖，这样就会导致快照同步完毕后无法进行增量同步。则需再次发起同步快照。
  

  快照同步.png
  
  所以务必配置合适大小的buffer参数，避免快照复制死循环
  buffer配置：repl-backlog-size

增加从节点

当从节点加入集群后，必须先同步一下快照，然后再增量同步。

小结

主从复制不是必需品，如果只是拿来做缓存，也就不需要从节点做备份，挂掉了重启即可。但是使用到了Redis的持久化功能，必须严谨对待主从复制，它是系统数据安全的基础。

扩展下，单机、单节点、单实例存在什么问题？
答：1，单点故障； 2，容量有限； 3，压力；
主从复制解决了上述什么问题？
答：单点故障
其他的问题，如何应对？
答：看后续... hehe
————————————————————
坐标帝都，白天上班族，晚上是知识的分享者
如果读完觉得有收获的话，欢迎点赞加关注