标签：
最近在看《大型网站系统与java中间件事件》这本书，收获颇多。
分布式事务希望在多机环境下可以像单机系统那样做到强一致，这需要付出比较大的代价。而在有些场景下，接受状态并不用时刻保持一致，只要最终一直就行。
CAP(Consistency Availability Partition-Tolerance)
Consistency: 即所有的节点在同一时间读到同样的数据，这就是数据上的一致性。
Availability: 保证无论时成功还是失败，每个请求都能够收到一个反馈。这里的重点是系统一定要有响应。
Partition-Tolerance:即便系统中有部分问题或者有消息的丢失，但系统仍能够继续运行。这被称为分区容忍性。
但是，在分布式系统中并不能同时满足上面三项。
1 选择CA，放弃分区容忍性，加强一致性和可用性。这其实就是传统的单机数据库的选择。
2 选择AP，放弃一致性，追求分区容忍性及可用性。这是很多分布式系统在设计时的选择，例如很多nosql系统就是如此。
3 选择CP，放弃可用性，追求一致性和分区容忍性。这种选择下的可用性会比较低，网络的问题会直接让整个系统不可用。
从上面的分析可以看出，在分布式系统中，我们一般还是选择加强可用性和分区容忍性而牺牲一致性，而是首先满足A和P，然后看如何解决C的问题。
BASE(Basically Available Soft state Eventually consistent)
Basically Available: 基本可用，允许分区失败。
Soft state: 软状态，接受一段时间的状态不同步。
Eventually consistent: 最终一致，保证最终数据的状态时一致的。
当我们在分布式系统中选择了CAP中的A和P后，对于C，我们采用的方式策略就是保证最终一致，也就是不保证数据变化后所有节点立刻一致，但是保证它们最终是一致的。在大型网站中，为了更好地保持扩展性和可用性，一般都不会选择强一致性，而是采用最终一致的策略来实现。
标签：
原文地址：http://www.cnblogs.com/gzhold/p/5890627.html
