在做分布式系统开发时，常常会或多或少的听到 CAP 实践、或者是解决节点间数据一致性的问题。
CAP 实践很简略，但却是很多软件设计的宏观指导，因而也有人将之称为架构师必须把握的实践之一。
鉴于实践的货色相对来说比拟形象而且繁琐，因而咱们先举个例子：
有一天你打王者光荣连跪，于是找了一个大神鲁班，带你腾飞：
于是就产生了下边的对话
（1）
射手鲁班：救救我，谢谢
辅助蔡文姬：收到
（2）
辅助蔡文姬：我来抓人了
射手鲁班：收到
如果所有良好，那么所有都 OK
然而假若这时候 YY 语音忽然挂掉了
（1）射手鲁班：救救我，谢谢
蔡文姬，没有响应
（2）辅助蔡文姬：我来抓人了
射手鲁班，没有响应
那么接下来有两种策略：
1、临时先不论 YY 语音的问题，持续打好游戏。
2、先不打游戏了，切屏打电话给对方，看下是不是产生了什么情况
是的，这波及到所谓的 CAP 实践了，
也就是在分布式场景下，如果不同节点之间的通信呈现了问题，那么不同节点的响应策略应该是什么样的。是该暂停响应，期待连贯复原，还是应该保持响应，疏忽数据的不一致性。
咱们先来看下计算机领域中，CAP 的业余解释：
一致性 Consistency：在分布式系统中，所有的数据备份，在任意时刻都要求统一；
可用性 Availability：对于分布式系统中的节点，在任意时候都能够失常的进行读写响应，并且不超时；
分区容错性 Partition tolerance：当节点之间的通信呈现 (防盗连贯：本文首发自 http://www.cnblogs.com/jilodr…) 故障时，整个分布式系统依然能够运行起来，不至于间接解体掉；
P 是背景，也就是在分布式系统下，如果节点之间的通信呈现了问题，那么整个零碎依然在运行，期待网络复原后，整个零碎依然能够失常操作。
通过实践以及理论的推演，咱们发现在 P 的背景下，AC 不能够共存。
也就是你无奈做到既保证了节点的可用性，还保障了一致性。
业余的推演证实，这里就不说了，笔者本人的了解是这样的：
当节点之间的网络解体时，节点如果想要可能反对可用性，势必会造成数据的批改，从而造成数据的不统一，而网络又解体掉，因而没有方法进行节点间的数据同步。当初对于接下来的解决策略有两个抉择：
（1）如果节点想要反对一致性呢，那么惟一的抉择就是不能进行数据的写，这是因为节点之间无奈进行数据的同步，因而只能放弃写操作，这就导致失去了高可用性。
（2）如果反对了写，那么就会呈现节点间的数据不统一，并且因为网络问题，无奈及时同步，这就失去了高始终性。
这套实践有什么用呢？
他能够明确指出，对于分布式系统来说，无奈做出数据完满始终，而且有高可用的场景。架构设计必须要做出取舍。
1、听从可用性，放弃高一致性
2、反对高始终性，放弃高可用性
具体应该如何抉择，由业务来决定。如果你的零碎反对短暂的业务进展，然而零碎不能出错，那么就要偏向于 CP 计划，如实时通话零碎，财务交易系统。如果你的零碎反对临时的数据不一致性，然而肯定要保障高可用性，如直播点赞，评论。那么就要偏向于 AP 计划。无所谓哪种计划更优良，而是须要由业务来驱动技术的选型。
很多人说，不是 CAP，三者取其二么？为什么你这里只有 CP，和 AP?
这两种了解其实都能够，然而（留神，要画重点了）
P 所代表的是分区容忍性，是指分布式场景下，对于网络通信问题下依然可用，这个是前提。
CP 和 AP 是基于这个前提探讨的两种计划。如果划掉 P，取 AC，也就是单机场景下的一致性和可用性 (防盗连贯：本文首发自 http://www.cnblogs.com/jilodr…) 问题，这就失去了探讨的意义。这好比在中学物理中 R =U/I , 电阻等于电压除以电流。然而你不能了解为电阻与电压成正比，与电流成反比，因为电阻只与资料和规格相干。你能够依照公式推算出数据，然而不代表是字面的含意。
另外须要留神的是，上述情况下，都是实践模型，其中疏忽了数据一致性所须要的网络提早。也就是说，在理论状况中，因为网络的延时问题，高效的 CP 零碎十分难实现。同时又因为互联网产品中自身须要的疾速响应，所以在理论的开发中，往往 AP 模式的设计，相对来说占比会更大一点。那么如何躲避掉一致性的影响呢？
这里提供两个思路
1、数据的最终一致性，呈现一致性问题没关系，只有不影响到外围的数据计算，是能够承受的。只有最终的数据可能保障一致性，满足幂等性即可。
2、缩短数据一致性复原的工夫，也就是如果呈现数据不统一的问题，零碎能够想方法缩短复原数据的耗时，如果当申请再次进来时，如果数据曾经复原实现，那么对于外界来说，就不会感知到此次的不统一。