如何在系统设计中使用CAP定理？

什么是CAP定理？在Consistency一致性, Availability可用性, Partition-tolerance分区容错性三者之中只能选两。

CP: 高一致性C和分区容错性P的系统，放弃可用性A。
AP: 可用性A和分区容错性P的系统，放弃高一致性C。
AC: 可用性A和高一致性C系统，放弃分区容错性P。

根据CAP定理，存在网络分区的状况下，只能在可用性和一致性之间选择。

如下面一个简单案例为例，写操做在主节点服务器，读操做在从节点服务器：

CLient ----> Web-API -----> 分布式缓存/DB(写操做在主节点+读操做在从节点)

假设有一个网络分区：

CLient ----> Web-API -----> 分布式缓存/DB(主节点+ 这里增长了网络分区 +从节点)

若是由于网络分区通信出错，致使主从服务器节点没法同步数据，写入主节点的数据，没法在从节点服务器读出。

咱们只能作两件事，在事务完成后发送500错误响应给用户，放弃了可用性，破坏用户体验，这是一种悲观作法，另一个乐观作法是早点发送200正确响应给用户，放弃一致性，保住可用性，保住了用户体验。

哪一个更好？没有哪一个更好，彻底取决于场景状况决定。

那么谁在两个方案中作决定呢？若是是开发团队，也许不太对，任何一种方法选择须要根据如下因素决定：
1. 实现高一致性C的成本是多少？或者不一致性的成本是多少？
2.达到高可用性有多重要?仍是仍出一个错误信息更合适？
3.能够容忍多长的延迟？接近无穷大∞的高延迟等于没有可用性。
4.方案复杂性如何？

那么除了以上方案，有没有可选的设计思路？

PACELC定理

PACELC定理以下：

If there is Partition,
       how does the system trade-off 
       between Availability and Consistency
Else
       how does the system trade-off
       between Latency and Consistency

若是有分区P，那就是在可用性和一致性之间平衡选择。
不然，就是在延迟Latency和一致性之间平衡选择。

高可用性和高一致性是咱们完美的追求，可是存在网络分区状况下，鱼和熊掌是不可兼得的。

变通方法：放弃一点高一致性，得到一点高可用性(低延迟)，也就是最终一致性方式。

如何针对咱们这个案例实现最终一致性？

1. 针对耗时的API调用使用异步响应给用户。
2. 在后台作全部的写操做工做。
3. 在数据库集群和缓存达成共识，同时不让用户等待。

这样作的结果是开发与业务两个方面共赢。

结论 在系统设计中考虑CAP定理是重要的。必须考虑整个系统的全部故障点。Casandra，Zoo Keeper，Kafka等技术能够在数据层面实现最终一致性。在AP和CP之间选择并不容易。在大多数状况下，它取决于业务要求。