云时代架构读后感3--CAP定理

架构设计之【CAP定理】

原文地址：https://mp.weixin.qq.com/s?__biz=MzAwNTQ4MTQ4NQ==&mid=2453562294&idx=1&sn=45d3ab6fb0f1f4e14d22606fb562bbda&chksm=8cd136d4bba6bfc28fcaeee41c08e4510a7742471f42edcc151e01e279a050018e0fd7d65768&mpshare=1&scene=23&srcid=#rd

通过阅读这篇文章，对CAP有了一定了解。

文章中指出CAP是每一名技术架构师必须掌握的基础原则，因为现在稍微大一点的项目都采用了分布式结构，一个系统可能有多个节点组成，每个节点都可能需要维护一份数据。

而CAP定理是分布式系统中最基础的原则，理解和掌握了CAP，对系统架构的设计至关重要。

「 CAP定理 」又被称为 布鲁尔定理，它提出对于一个分布式系统而言，不能同时满足以下三点：

• Consisteny（一致性）

• Availability（可用性）

• Partition tolerance（分区容错性）

也就是说CAP定理指明了，任何分布式系统只能同时满足这三项中的两项。

上述三项属性的基本含义如下：

1. Consisteny（一致性）

   一致性的要求是指，对于任何客户端（上图Actor）来说，每次的读操作，都能获得最新的数据。即，当有客户端向A节点写入了新数据之后，其它客户端从B节点中进行读操作所获得的数据必须也是最新的，是与A节点数据保持一致的。

2. Availability（可用性）

   可用性的要求是指，每个请求都能在合理的时间内获得符合预期的响应（不保证获取的结果是最新的数据）。

3. Partition tolerance（分区容错性）

   分区容错性是指，当节点之间的网络出现问题之后，系统依然能正常提供服务。

分布式系统理论上是不可能有CA组合的，所以我们只能选择 CP 和 AP组合架构。

1.CP架构即 Consisteny（一致性）与 Partition tolerance（分区容错性）的组合。

如果由于网络问题，节点A和节点B之前不能互相通讯。当有客户端向节点A进行写入请求时（准备写入Message 2），节点A会不接收写入操作，导致写入失败，这样就保证了节点A和节点B的数据一致性，即保证了Consisteny（一致性）。

然后，如果有另一个客户端向B节点进行读请求的时候，B请求返回的是网络故障之前所保存的信息（Message 1），并且这个信息是与节点A一致的，是整个系统最后一次成功写入的信息，是能正常提供服务的，即保证了Partition tolerance（分区容错性）。

上述情况就是保障了CP架构，但放弃了Availability（可用性）的方案。

2.AP架构即 Availability（可用性）与 Partition tolerance（分区容错性）的组合架构。

若果网络问题，节点A和节点B之前不能互相通讯。当有客户端向节点A进行写入请求时（准备写入Message 2），节点A允许写入，请求操作成功。但此时，由于A和B节点之前无法通讯，所以B节点的数据还是旧的（Message 1）。当有客户端向B节点发起读请求时候，读到的数据是旧数据，与在A节点读到的数据不一致。但由于系统能照常提供服务，所以满足了Availability（可用性）要求。

因此，这种情况下，就是保障了AP架构，但其放弃了 Consisteny（一致性）。

在基本了解了CAP定理后，对于开发者而言，当我们构建服务的时候，就需要根据业务特性作出权衡考虑，判断出哪些点是当前系统可以取舍的，哪些是应该重点保障的。

即使是在同一个系统中，不同模块的数据可能应用的CAP架构都是不同的。

举个例子，在某个电商系统中，属于用户模块的数据（账密、钱包余额等）对一致性的要求很高，就可以采用CP架构。而对于一些商品信息方面的数据对一致性要求没那么高，但为了照顾用户体验，所以对可用性要求更高一些，那么这个模块的数据就可以采用AP架构。

而且即使我们按照CAP定理，三个中只能取其二，但不代表我们只需要保障其中的两点，而完全的放弃第三点，我们应该为不能保障的第三点也做一些防备措施或者冗余方案，来使系统更加的完善健全。