分布式基础，通俗易懂CAP？

分布式系统很是关注三个指标：

• 数据一致性
• 系统可用性
• 节点连通性与扩展性

关于一致性

数据“强一致性”，是但愿系统只读到最新写入的数据，例如：经过单点串行化的方式，就可以达到这个效果。

关于session一致性，DB主从一致性，DB双主一致性，DB与Cache一致性，数据冗余一致性，消息时序一致性，分布式事务一致性，库存扣减一致性，详见文章《究竟啥才是互联网架构“一致性”》。

关于可用性

若是系统每运行100个时间单位，会有1个时间单位没法提供服务，则说系统的可用性是99%。

可用性和可靠性是比较容易搞混的两个指标，以一台取款机为例：

• 正确的输入，可以取到正确的钱，表示系统可靠
• 取款机7*24小时提供服务，表示系统可用

保证系统高可用的方法是：

• 冗余
• 故障自动转移

反向代理层，站点层，服务层，缓存层，数据库层各层保证系统高可用的方法，详见文章《究竟啥才是互联网架构“高可用”》。

关于连通性与扩展性

分布式系统，每每有多个节点，每一个节点之间，都不是彻底独立的，须要相互通讯，当发生节点没法联通时，数据是否还能保持一致，系统要如何进行容错处理，是须要考虑的。

同时，连通性和扩展性紧密相关，想要加机器扩展性能，必须有良好的连通性。当一个节点脱离系统，系统就出现问题，每每意味着系统是没法扩展的。

反向代理层，站点层，服务层，缓存层，数据库层各层保证系统扩展性的方法，详见文章《究竟啥才是互联网架构“可扩展”》。

什么是CAP定理？

CAP定理，是对上述分布式系统的三个特性，进行了概括：

• 一致性(Consistency)
• 可用性(Availability)
• 分区容忍性(Partition Tolerance)
  而且，定理指出，在系统实现时，这三者最多兼顾两点。

一致性，可用性，多节点扩展性三者只能取其二，既然加锁已经加上，常见的最佳工程架构实践是什么呢？
互联网，最多见的实践是这样的：

• 节点连通性，多节点扩展性，连通性异常的处理必须保证，知足P
• 一致性C与可用性A通常二选一
• 选择一致性C，举例：传统单库水平切分，就是这类选型的典型
• 选择可用性A，举例：双主库同步高可用，就是这类选型的典型

强一致很难怎么办？

单点串行化，虽然能保证“强一致”，但对系统的并发性能，以及高可用有较大影响，互联网的玩法，更多的是“最终一致性”，短时间内未必读到最新的数据，但在一个可接受的时间窗口以后，可以读到最新的数据。

例如：数据库主从同步，从库上的数据，就是一个最终的一致。

总结

• CAP能够理解为一致性，可用性，联通与扩展性
• CAP三者只能取其二
• 最多见的实践是AP+最终一致性

思路比结论重要。

架构师之路-分享可落地的技术文章

推荐阅读：《究竟啥才是互联网架构“一致性”》《究竟啥才是互联网架构“高可用”》《究竟啥才是互联网架构“可扩展”》《分布式基础，啥是两阶段提交？》《分布式事务，原来能够这么玩？》