分布式CAP理论简介

CAP

基本含义

1、一致性（Consistency）

对于单个节点，读操作总是能够读取到之前写入的值。

2、可用性（Available）

读写操作在单台机器发生故障的情况下仍然能够正常执行。返回成功或者失败都表示可用。

3、分区容错性（Partition Tolerance）

机器故障、网络故障、机房停电等异常情况下仍然能够满足一致性和可用性。

问题

1、分区容错性和可用性有什么区别？

分区容错：

I、如果每个分区的数据都是一样的，那么分区就没有问题，但是想要保证每个分区的数据都一样，各个分区之间就需要进行数据同步 ，如果要求强一致性，那么在各个分区进行数据同步的时候就不能够对外提供服务，此时的可用性就会有问题。

II、如果每个分区保存不一样的数据，就需要做到各个模块独立，如果耦合性太高，就会导致一个分区挂掉，影响其他分区的业务。 例如在订单在支付的过程中，如果支付挂掉，那么我们就会返回支付失败，此时挂号模块还是可用的，但是就需订单模块修改该订单为失败，做逻辑上的事务回滚，此时的强一致性就无法保证。

2、使用缓存保证一致性需要注意的问题。

保持一致性的做法还可以通过缓存实现，使用Spring在业务层做一个缓存，每次写数据的时候先写缓存，后写数据库，每次读数据库的时候，先读缓存，再读数据库，这样会有很好的可用性。但是同样会产生一个问题，如果写缓存成功，但是写数据库的时候失败了，此时就需要删除缓存中的值。

https://www.jianshu.com/p/c8d5df3338aa（缓存同步，缓存雪崩）

个人理解

对于CAP理论而言 ，需要单独拆开来看，控制变量，对于高并发的分布式系统而言，我们最需要保证的就是服务的高可用，那我们怎么样来保证呢？

服务的高可用我想到有以下解决方案：

1、对于应用服务器而言，我们可以使用dubbo或者SpringCloud，提供多个节点的服务。

2、使用F5硬负载或者Nginx做软负载。

3、如果是Redis想要做到高可用，那么我们可以使用redis的哨兵模式，如果并发量太大，我们做集群的时候同时可以考虑主从模式。

这是一个简化版的分布式架构图，如果有其他中间件，如MQ，ZK等，原理都是一样，只是配置和部署会稍有不同。

引用知乎上的一个回答（https://www.zhihu.com/question/54105974）：
一个分布式系统里面，节点组成的网络本来应该是连通的。然而可能因为一些故障，使得有些节点之间不连通了，整个网络就分成了几块区域。数据就散布在了这些不连通的区域中，这就叫分区。当一个数据项只在一个节点中保存，那么分区出现后，和这个节点不连通的部分就访问不到这个数据了。这时分区就是无法容忍的。提高分区容忍性的办法就是一个数据项复制到多个节点上，那么出现分区之后，这一数据项就可能分布到各个区里。容忍性就提高了。然而，要把数据复制到多个节点，就会带来一致性的问题，就是多个节点上面的数据可能是不一致的。要保证一致，每次写操作就都要等待全部节点写成功，而这等待又会带来可用性的问题。总的来说就是，数据存在的节点越多，分区容忍性越高，但要复制更新的数据就越多，一致性就越难保证。为了保证一致性，更新所有节点数据所需要的时间就越长，可用性就会降低。