CAP定理

CAP定理

CAP定理又称CAP原则，指的是在一个分布式系统中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），最多只能同时三个特性中的两个，三者不可兼得。

---

Consistency (一致性)

“all nodes see the same data at the same time”,即更新操作成功并返回客户端后，所有节点在同一时间的数据完全一致，这就是分布式的一致性。

Availability（可用性）

可用性指“Reads and writes always succeed”,即服务一直可用，而且是正常响应时间。
好的可用性主要是指系统能够很好的为用户服务，不出现用户操作失败或者访问超时等用户体验不好的情况

Partition tolerance（分区容错性）

大多数分布式系统都分布在多个子网络，每个子网络就叫做一个区。
分区容错的意思是，区间通信可能失败。
比如，一台服务器放在本地，另一台服务器放在外地（可能是外省，甚至是外国），这就是两个区，它们之间可能无法通信两台跨区的服务器。Server1 向 Server2 发送一条消息，Server2 可能无法收到。系统设计的时候，必须考虑到这种情况。
一般来说，分区容错无法避免，因此可以认为 CAP 的 P 总是成立,即分布式系统在遇到某节点或网络分区故障的时候，仍然能够对外提供满足一致性或可用性的服务。
分区容错性要求能够使应用虽然是一个分布式系统，而看上去却好像是在一个可以运转正常的整体。

---

Consistency 和 Availability 的矛盾

如果保证 Server2 的一致性，那么 Server1 必须在写操作时，锁定 Server2 的读操作和写操作。只有数据同步后，才能重新开放读写。锁定期间，Server2 不能读写，没有可用性。

如果保证 Server2 的可用性，那么势必不能锁定 Server2，所以一致性不成立

---

取舍策略

CAP三个特性只能满足其中两个，那么取舍的策略就共有三种：

CA without P：

如果不要求P（不允许分区），则C（强一致性）和A（可用性）是可以保证的。
但放弃P的同时也就意味着放弃了系统的扩展性，也就是分布式节点受限，没办法部署子节点，
这是违背分布式系统设计的初衷的。

CP without A：

如果不要求A（可用），相当于每个请求都需要在服务器之间保持强一致，而P（分区）会导致同步时间无限延长(也就是等待数据同步完才能正常访问服务)。
一旦发生网络故障或者消息丢失等情况，就要牺牲用户的体验，等待所有数据全部一致了之后再让用户访问系统。

AP wihtout C:

要高可用并允许分区，则需放弃一致性。
一旦分区发生，节点之间可能会失去联系，为了高可用，每个节点只能用本地数据提供服务，而这样会导致全局数据的不一致性。
抢购商品时，可能前几秒你浏览商品的时候页面提示是有库存的，当你选择完商品准备下单的时候，系统提示你下单失败，商品已售完。这其实就是先在 A（可用性）方面保证系统可以正常的服务，然后在数据的一致性方面做了些牺牲，虽然多少会影响一些用户体验，但也不至于造成用户购物流程的严重阻塞。

没有最好的策略，好的系统应该是根据业务场景来进行架构设计的，只有适合的才是最好的

---

详细讲解： https://blog.csdn.net/yeyazhishang/article/details/80758354?utm_medium=distribute.pc_relevant.none-task-blog-opensearch-1.channel_param&depth_1-utm_source=distribute.pc_relevant.none-task-blog-opensearch-1.channel_param