《大型网站系统与Java中间件实践》读书笔记——CAP理论

分布式事务希望在多机环境下可以像单机系统那样做到强一致，这需要付出比较大的代价。而在有些场景下，接收状态并不用时刻保持一致，只要最终一致就行。

CAP理论是Eric Brewer在2000年7月份的PODC会议上提出的，CAP涵义如下：

• Consistensy：all nodes see the same data at the same time,所有的节点在同一时间读到同样的数据。这就是数据上的一致性，也就是当数据写入成功后，所有的节点会同时看到这个新的数据。
• Availability：a guarantee that every request receives a response about whether it was successful or failed,保证无论是成功还是失败，每个请求都能收到一个反馈。这就是数据的可用性，这里的重点是系统一定要有相应。
• Partition-tolerance：the system continues to operate despite arbitrary message loss or failure of part of the system,即便系统中有部分问题或者有消息丢失，系统仍然能够继续运行。即系统的一部分出现问题时，系统仍能继续工作。

在分布式系统中并不能同时满足以上三项，最多在只能选择其中两项。

• 选择CA，放弃分区容忍性，加强一致性和可用性。其实就是传统的单机数据库的选择。
• 选择AP，放弃一致性，追求分区容忍性及可用性。这是很多分布式系统在设计时的选择，例如很多NoSQL系统就是如此。
• 选择CP，放弃可用性，追求一致性和分区容忍性。这种选择下的可用性会比较低，网络的问题会直接让整个系统不可用。

从上面的分析可以看出，在分布式系统中，一般选择加强可用性和分区容忍性而牺牲一致性。当然，这里所讲的并不是不关心一致性，而是首先满足A和P，然后看如何解决C的问题。

来看看BASE模型，涵义如下：

• Basically available：基本可用，允许分区失败。
• Soft state：软状态，接受一段时间的状态不同步。
• Eventually consistent：最终一致，保证最终数据的状态是一致的。

当分布式系统中选择了CAP中的A和P后，对于C采用的策略是保证最终一致。也就是不保证数据变化后所有节点立刻一致，但是保证它们最终是一致的。在大型网站中，为了更好地保持扩展性和可用性，一般都不会选择强一致性，而是采用最终一致的策略来实现。