系列目录：
- 《分布式事务（一）—— 事务的基本概念》
一、CAP理论
cap理论是分布式系统的理论基石
1、Consistency[一致性]
即操作成功并返回客户端后，所有节点在同一时间的数据完全一致，这就是分布式的一致性。一致性的问题在并发系统中不可避免，对于客户端来说，一致性的问题是并发访问时更新过的数据如何获取的问题。从服务端来说，则是更新如何复制分布到整个系统，以保持数据的一致。
2、Availability[可用性]
可用性是指读取和写入操作一致能工成功，即服务一直可用，而且是正常的响应时间。好的可用性指系统能够很好的为用户提供服务，不出现用户操作失败或者访问超时等用户体验不好的情况。
3、Partition Tolerance[分区容错性]
即分布式系统在遇到某个节点分区故障的时候，仍然能够对外提供满足一致性和可用性的服务。分区容错性要求能够使应用虽然是一个分布式系统，但是看上去却是一个可以正常运转的整体。比如现在分布式系统中某一个或者几个机器宕机了，其他剩下的机器还是能够正常运转并满足系统需求，对于用户而言并没有什么体验上的影响。
如果你是一个分布式系统，那么你就必须要满足分区送错性，因为分布式系统就是为了解决高并发和提高系统的可用性，要不然就不用将系统做成分布式系统了。
二、CAP的取舍策略
CAP三个特性只能满足其中两个，那么取舍策略就有三种：
- CA：如果不需要P，则一致性和可用性是可以保证的。但是放弃P的同时也就意味着放弃了系统的扩展性，也就是分布式节点受限，没有办法部署子节点，这是违背分布式系统的设计初衷的。
- CP：保证一致性和分区容错性，放弃可用性。相当于每个请求在服务器之间保持强一致，而P（分区容错）也会导致同步时间的延长（也就是需要等待数据同步完成才能正常访问系统），一旦发生网络故障或者消息丢失的情况，就要牺牲用户体验，等到所有数据全部一致后再让用户访问系统。设计成CP的系统其实不少，最典型的就是分布式数据库，如Redis、HBase等。对于这些分布式数据库来说，数据的一致性是基本的要求，因为如果连这个都打不到，那么直接采用关系型数据库就好了，没必要再浪费资源部署分布式数据库。
- AP：高可用并容许分区，则要放弃一致性。一旦分区发生，节点之间可能会失去联系，为了高可用，每个节点只能用本地数据库提供服务，而这样会导致全局数据的不一致。
三、Base理论
分布式系统中的一致性是弱一致性，单数据库mysql的一致性是强一致性
Base是Basically Available（基本可用）、Soft status（软状态）和Eventually consistent（最终一致性）三个短语的缩写。Base理论对于CAP中一致性和可用性权衡的结果。其来源对于大规模互联网系统分布式实践的总结，是基于CAP定理逐步演化而来的。
Base理论的核心思想是：即使没有办法做到强一致，但是可以做到最终一致。
Base理论的三要素
1、基本可用
基本可用是指分布式系统在出现不可预知故障的时候，允许损失部分可用性，注意：这里并不是说系统不可用，比如：
- (1) 响应时间上的损失：正常情况下，一个在线搜索需要在0.5秒内返回给用户响应的查询结果。但由于出现故障，查询结果的响应时间增加了1~2秒
- (2) 系统功能上的损失：正常情况下，在一个电商网站上进行购物的时候，消费者几乎能顺利完成每一笔订单，但是在一些节日大促购物高分期的时候，由于消费者的购物行为激增，为了保护购物系统的稳定性，部分消费者可能会被引导到一些降级页面。
2、软状态
软状态指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点数据副本之间进行数据同步的时候可以存在延时。
3、最终一致性
最终一致性强调的是所有的数据副本，在经过一段时间的同步之后，最终能达到一个一致的状态。因此，最终一致的本质需要系统保证最终数据能够达到一致，而不需要实时保持数据的强一致。
总体来说，Base理论面向的是大型高可用可扩展的系统，和传统的事物ACID特性是相反的，它完全不同于ACID的强一致模型，而是牺牲强一致来获得可用性，并允许数据在一段时间内不一致，但最终达到一致状态。同时，在实际的分布式场景中，不同业务单元和组建对数据一致性的要求不同，因此在具体的分布式系统架构设计的过程中ACID特性和Base理论往往又会结合在一起。
一句话：CAP就是要告诉你：要想同时满足C、A、P就是做梦，Base才是你最终的归宿
后记
个人总结，欢迎转载、评论、批评指正
