看起来很唬人，然而却简单实用的CAP理论

在做分布式系统开发时，经常会或多或少的听到CAP理论、或者是处理节点间数据一致性的问题。
CAP理论很简单，但却是很多软件设计的宏观指导，因此也有人将之称为架构师必须掌握的理论之一。
鉴于理论的东西相对来说比较抽象而且繁琐，因此我们先举个例子：
有一天你打王者荣耀连跪，于是找了一个大神鲁班，带你起飞：

于是就发生了下边的对话
（1）
射手鲁班：救救我，谢谢

辅助蔡文姬：收到
（2）
辅助蔡文姬：我来抓人了

射手鲁班：收到

如果一切良好，那么一切都OK

但是假若这时候YY语音突然挂掉了
（1）射手鲁班：救救我，谢谢

蔡文姬，没有响应

（2）辅助蔡文姬：我来抓人了

射手鲁班，没有响应

那么接下来有两种策略：
1、 暂时先不管YY语音的问题，继续打好游戏。
2、先不打游戏了，切屏打电话给对方，看下是不是发生了什么状况

是的，这涉及到所谓的CAP理论了，
也就是在分布式场景下，如果不同节点之间的通信出现了问题，那么不同节点的响应策略应该是什么样的。是该暂停响应，等待连接恢复，还是应该坚持响应，忽略数据的不一致性。
我们先来看下计算机领域中，CAP的专业解释：
一致性 Consistency：在分布式系统中，所有的数据备份，在任意时刻都要求一致；
可用性 Availability：对于分布式系统中的节点，在任意时候都可以正常的进行读写响应，并且不超时；
分区容错性 Partition tolerance：当节点之间的通信出现(防盗连接：本文首发自http://www.cnblogs.com/jilodream/ )故障时，整个分布式系统仍然可以运行起来，不至于直接崩溃掉；
P是背景，也就是在分布式系统下，如果节点之间的通信出现了问题，那么整个系统仍然在运行，等待网络恢复后，整个系统仍然可以正常操作。

经过理论以及实际的推演，我们发现在P的背景下，AC不可以共存。
也就是你无法做到既保证了节点的可用性，还保证了一致性。
专业的推演证明，这里就不说了，笔者自己的理解是这样的：
当节点之间的网络崩溃时，节点如果想要能够支持可用性，势必会造成数据的修改，从而造成数据的不一致，而网络又崩溃掉，因此没有办法进行节点间的数据同步。现在对于接下来的处理策略有两个选择：
（1）如果节点想要支持一致性呢，那么唯一的选择就是不能进行数据的写，这是因为节点之间无法进行数据的同步，因此只能放弃写操作，这就导致失去了高可用性。
（2）如果支持了写，那么就会出现节点间的数据不一致，并且由于网络问题，无法及时同步，这就失去了高一直性。

这套理论有什么用呢？
他可以明确指出，对于分布式系统来说，无法做出数据完美一直，而且有高可用的场景。架构设计必须要做出取舍。
1：遵从可用性，放弃高一致性
2：支持高一直性，放弃高可用性
具体应该如何选择，由业务来决定。如果你的系统支持短暂的业务停顿，但是系统不能出错，那么就要倾向于CP方案，如实时通话系统，财务交易系统。如果你的系统支持暂时的数据不一致性，但是一定要保证高可用性，如直播点赞，评论。那么就要倾向于AP方案。无所谓哪种方案更优秀，而是需要由业务来驱动技术的选型。
很多人说，不是CAP，三者取其二么？为什么你这里只有CP，和AP?
这两种理解其实都可以，但是（注意，要画重点了）
P所代表的是分区容忍性，是指分布式场景下，对于网络通信问题下仍然可用，这个是前提。
CP和AP是基于这个前提讨论的两种方案。如果划掉P，取AC，也就是单机场景下的一致性和可用性(防盗连接：本文首发自http://www.cnblogs.com/jilodream/ )问题，这就失去了讨论的意义。这好比在中学物理中R=U/I ,电阻等于电压除以电流。但是你不能理解为电阻与电压成正比，与电流成反比，因为电阻只与材料和规格相关。你可以按照公式推算出数据，但是不代表是字面的含义。

另外需要注意的是，上述情况下，都是理论模型，其中忽略了数据一致性所需要的网络延迟。也就是说，在实际情况中，由于网络的延时问题，高效的CP系统非常难实现。同时又由于互联网产品中本身需要的快速响应，所以在实际的开发中，往往AP模式的设计，相对来说占比会更大一点。那么如何规避掉一致性的影响呢？
这里提供两个思路
1、 数据的最终一致性，出现一致性问题没关系，只要不影响到核心的数据计算，是可以接受的。只要最终的数据能够保证一致性，满足幂等性即可。
2、 缩短数据一致性恢复的时间，也就是如果出现数据不一致的问题，系统可以想办法缩短恢复数据的耗时，如果当请求再次进来时，如果数据已经恢复完成，那么对于外界来说，就不会感知到此次的不一致。