CAP原则-分布式应用的基础原理（一）

问题由来，由于互联网的发展，用户数据的增多，在同一时间登录系统的用户数以亿计，单体的应用不能负载此用户容量，由此产生了分拆功能的需求，比如：一个淘宝首页的查询，在同一时间有一亿人访问，单体的应用肯定得崩溃呀。这样，就把后台的查询功能分散到1千台机器提供的服务，这样就分摊了压力。现实的情况，可以理解为有一座桥在10分钟通过十万人，肯定通不过呀，就再造1000坐桥，这样就分摊了压力。 在分摊的过程中，出现问题就需要相互沟通交流，CAP的问题就来了。

1、概念

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

2、分析 2.1 一致性（C-Consistency）：

在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本） 从客户端角度来看，一致性主要指多个用户并发访问时更新的数据如何被其他用户获取的问题； 从服务端来看，一致性则是用户进行数据更新时如何将数据复制到整个系统，以保证数据的一致。 对于一致性，一致的程度不同大体可以分为强、弱、最终一致性三类。 （1）强一致性 比如，1000座桥，桥1通过了100人，桥2通过了50人，那么，就得强制同步通知其他桥已经通过了150人，保持数据的统一。 （2）弱一致性 比如，桥1通过了100人，桥2通过了50人，其他桥并不知道所有桥通过了多少人。 （3）最终一致性 比如，桥1通过了100，桥2通过了50人，过10秒钟才通知其他桥，通过了150人，也最终保持了数据的统一。 2.2 可用性（A-Availability） 保证每个请求不管成功或者失败都有响应。 好的可用性主要是指系统能够很好地为用户服务，不出现用户操作失败或者访问超时等用户体验不好的情况。在通常情况下，可用性与分布式数据冗余、负载均衡等有着很大的关联。 2.3 分区容错性（P-Partition tolerance） 系统中任意信息的丢失或失败不会影响系统的继续运作。 分布式系统在遇到某节点或网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务。 分区容错性和扩展性紧密相关。在分布式应用中，可能因为一些分布式的原因导致系统无法正常运转。分区容错性高指在部分节点故障或出现丢包的情况下，集群系统仍然能提供服务，完成数据的访问。分区容错可视为在系统中采用多副本策略。 CAP原则的精髓就是要么AP，要么CP，CA，不存在CAP。 CA 如果不要求 Partition Tolerance，即不允许分区，则强一致性和可用性是可以保证的。其实分区是始终存在的问题，因此 CA 的分布式系统更多的是允许分区后各子系统依然保持CA。 CP 如果不要求可用性，相当于每个请求都需要在各服务器之间强一致，而分区容错性会导致同步时间无限延长，如此 CP 也是可以保证的。很多传统的数据库分布式事务都属于这种模式。 AP 如果要可用性高并允许分区，则需放弃一致性。一旦分区发生，节点之间可能会失去联系，为了实现高可用，每个节点只能用本地数据提供服务，而这样会导致全局数据的不一致性。

3、总结 在实践中，可根据实际情况进行权衡，或者在软件层面提供配置方式，由用户决定如何选择 CAP 策略。 CAP 理论可用在不同的层面，可以根据 CAP 原理定制局部的设计策略，例如，在分布式系统中，每个节点自身的数据是能保证 CA 的，但在整体上又要兼顾 AP 或 CP。

每天进步一点点！