分布式学习（二）——CAP定理理解篇

前言：CAP定理是学习分布式所必备的知识点之一，所以先深入的理解一下这个知识点。初看CAP定理时，有些不以为意，在后续的学习中发现这是个特别值得仔细揣摩的点。

一、CAP定理

我们了解到分布式是将一个业务拆分成多个子业务，就有了我们的分布式系统，而CAP定理就是针对分布式系统的。CAP定理（CAP theorem），又被称作布鲁尔定理（Brewer’s theorem），也称为帽子原理。

1. C：Consistence，一致性（强一致性）。所有子业务在同一时刻读取的数据都具有相同的值。

2. A：Availability，可用性，好的响应性能。每次请求都能获取到非错的响应。

3. P：Partition tolerance，分区容忍性（分区容错性）。某个子业务发生故障时，系统仍能够继续运行。

二、关于三选二

• 通过字面意思我们可以理解为这是分布式系统的三个重要属性。也可以这样说，这个分布式系统有一致性，有可用性，有分区容错性（这里可能会因为这个词的陌生而觉着别扭，需要简单理解下）。
• 很多资料说明对一个分布式系统来说不可能同时满足以上三点，只能实现其中俩点。  也有说分区容忍性是必须实现的，我们只能在剩余俩点中二选一。 可以看出矛盾点来自于分区容忍性，让我们来了解下。

三、分区容忍性

分区：一个分布式系统里各子业务的网络应该是连通的。因一些原因使得这些子业务之间的网络不通了，从而导致系统被切分成若干个孤立的区域。这就是分区。

分区容忍性：如果数据只保存在一个子业务中，那么出现分区时，其它子业务就访问不到数据了，这时出现的分区是无法容忍的。

如何提高分区容忍性：提高分区容忍性的办法就是一个数据项复制到多个节点上，那么出现分区之后，这一数据项就可能分布到各个区里，容忍性就提高了。

举个例子：一个简单的分布式商城，它有俩个业务，一个库存子业务，一个订单子业务。当用户通过订单子业务下单时，订单子业务需要告诉库存让其数量-1，当他们之间网络不通时，就形成了俩个孤立的区域，形成了分区。这时就没实现分区容忍性。我们想要避免这种情况就需要在下单时将下单进行复制同时告诉库存，这样即使出现了分区，下单这一数据项也分布到了这俩个区，容忍性就提高了。

然而，要把数据复制到多个子业务，就会带来一致性的问题，就是多个子业务上面的数据可能是不一致的。要保证一致，每次写操作就都要等待全部子业务写成功，而这等待又会带来可用性的问题。

小结

关系型数据库是单节点无复制的，因此不具备分区容忍性。所以CAP仅适用于原子读写的NOSQL场景中。而分布式系统都需要满足分区容忍性P。所以对于分布式系统来说我们要在一致性C与可用性A之间进行权衡。

四、一致性与可用性的矛盾

上面我们通过复制下单这一数据项提高了分区容忍性。解决问题的同时又出现了新的问题，如果订单业务写的时候出现错误，就会出现没订单但是库存却少了的情况，导致数据不一致。如果想要解决这个问题，我们就需要等待订单写成功后再写库存，这个过程中必须暂停库存的操作，就失去了可用性。所以在实际应用中就要根据实际场景来进行取舍。

五、思考

在这种情况下有没有办法进一步的优化呢，让我们带着这个疑问继续学习吧。