843-CAP问题在Redis中怎么得到解决的？

CAP理论

CAP理论是什么？可以这么说吧cap理论是分布式系统的奠基石吧，这个理论论述分布式系统设计的3个最大问题：

一致性 (Consistency)
可用性 (Availability)
分区容错性 (Partition Tolerance)

什么是一致性？假设一个集群有2个节点A-1和A-2，这两个节点为主从关系，例如redis里面的主从模式。主节点负责写入数据，从节点负责从主节点同步数据到本机。

A-1和A-2 通过网络进行数据同步，要怎么保证两台机子上的数据一致的呢？这个就是数据一致性问题。

那什么是可用性？A-1和A-2两台机子做成一个集群，实际上真实情况可能更多，在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求，例如A-1挂掉以后，A-2会马上接管这些请求的，保持整体可用性。

那什么是分区容错性？一个集群都靠着网络进行通讯的，如果网络波动，这个集群中的部分节点网络和集群上的其他节点联通不了，那么数据一致性就很难保持了，网络一断开，那么那么整个集群可能被划分成多个独立的小分区了，如果在短时间内不能联通同步数据，这就是出现网络分区问题。

网络分区

如上图 A-1和A-3网络连接出现了故障，那么这个集群就已经存在了网络分区问题！但是整体集群而看上去却好像是在一个可以运转正常，其他剩下的机器还能够正常运转满足系统需求，对于用户而言并没有什么体验上的影响。

所以在设计分布式系统时，CAP问题必会出现！除非你玩单机系统????！怎么优雅解决问题，就看设计者了在A和C、P之前怎么做决策了。用这些问题我去套用在redis集群模式上，看redis集群是怎么解决CAP问题的。

Redis哨兵

哨兵

Redis早期版本，redis单机情况下即便性能强的一批，但是大规模数据或者海量请求下还是为支撑不了可用性和稳定性，后面redis官方有一个解决方案就是哨兵模式。

哨兵模式：上面提到了主从架构，主从切换技术方案是，当主服务器宕机后，需要手动把一台从服务器切换为主服务器，这中间就需要人工干预，例如大半夜收到报警，爬起来手动切换服务器？？？需要手动将 从节点 晋升为 主节点，同时还要通知 客户端 更新 主节点地址，显然这种问题怎么可能忍？大家都是程序员自己写个程序自动化不就好了，为什么要用这么笨方式。。。哨兵模式哨兵就是解决这个问题的，哨兵是一个独立的进程，作为进程，它会独立运行，其原理是哨兵通过发送命令，等待Redis服务器响应，从而监控运行的多个Redis实例，当有一个节点挂掉的时候，客户端连接其节点失败，就会向哨兵服务器询问新的节点地址然后继续使用，其他从节点也会跟着把主节点调整到新节点上，哨兵还会记录当前挂掉节点状态，还会定时进行查看如果复活了还会添加到哨兵集群里，从而达到无人干扰。

增量同步&全量同步

上面哨兵模式切换过程，提到了主从，那主从节点数据，怎么保证一致性的的？在redis集群情况下同步模式有两种：

增量同步
全量同步
设想一下主从节点在某个网络情况出现问题波动，这是客户端正在朝着服务器端主节点，写数据，而从节点又在从主节点读取同步被写入的数据，这时网络一波动，那么就出现网络分区了。出现网络分区了，此时两个节点就处于独立的单机状态，如图：

正如上图所话的，主从在短时间内出现网络分区，redis的设计者针对这个方案提出了一个方案叫增量复制，如下图，当然这个图我之前讲go中的channel的时候画的，反正是同用的，所以懒得话了，直接拿过来用一用。

增量同步

redis在每个主节点上分配一快ring也可以叫为buf，这个ring是里面就记录它自身大小元素个数的最近客户端执行命令记录，如果从节点短时间内恢复了链接，此时从节点直接去主节点的ring中拿取命令记录数据，然后在自己本机上跑一遍。

增量复制不是没有问题的，设想一下如果这个网络分区出现很长时间，这个ring容量是不是不够用，所有第二套解决方案出现了，全量同步这个过程是怎么样的？

直接把redis在内存里面的数据通过序列化然后通过网络发送到从节点，从节点在本地保存，然后全量加载到内存里面完成数据恢复，在全量同步的时候，可能也有其他命令漏掉，还会配上增量复制进行。

最后

以上就是无奈眼神为你收集整理的843-CAP问题在Redis中怎么得到解决的？的全部内容，希望文章能够帮你解决843-CAP问题在Redis中怎么得到解决的？所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。