「cap」浅谈CAP的理解

cap

学Nosql理论基础时，重新回顾了CAP理论，在此对所查资料的理解，以方便后续的学习及回顾。

什么是CAP？

C：Consistency 一致性：数据在多个副本之间是否能够保持一致的特性。（当一个系统在一致状态下更新后，应保持系统中所有数据仍处于一致的状态）

A：Availability 可用性：系统提供的服务必须一直处于可用状态，对每一个操作的请求必须在有限时间内返回结果。

P：Tolerance of network Partition 分区容错性：分布式系统在遇到网络分区故障时，仍然需要保证对外提供一致性和可用性的服务，除非整个网络都发生故障。

CAP理论

一个分布式系统不可能同时满足一致性、可用性和分区容错性这三个需求，只能最多满足两个。

为什么只能同时满足两个？

我个人的理解是，服务器中原本存储的ch=0，当客户端A修改ch=1时，为了保证数据的一致性，要写到3个服务器中，当服务器C故障时，数据无法写入服务器C，则导致了此时服务器A、B和C的ch是不一致的。这时候要保证分区容错性，即当服务器C故障时，仍然能保持良好的一致性和可用性服务，则Consistency和Availability不能同时满足。为什么呢？因为如果满足了一致性，则客户端A的写操作ch=1不能成功，这时服务器中所有ch=0；若满足可用性，即所有客户端都可以提交操作并得到返回的结果，则此时允许客户端A写入服务器A和B，客户端C将得到未修改之前的ch=0结果。

注意，这只是针对从同一数据在网络上多个副本出发的解释，这是最基本也是最好理解的一个层面，即在分布式系统中在必须满足P的情况下，C和A只能选一个。

但只是从这个层面来讲，针对关系数据库中的说法：“保证CA牺牲P”又是什么呢？

如果只将CAP理论当做分布式系统中数据副本之间的读写一致问题来看待，那么可以认为：CAP既适用于Nosql数据库，也适合关系数据库，它是NoSQL数据库、关系数据库、乃至一切分布式系统在设计数据多个副本之间读写一致问题时需要遵循的共同原则。而简单的讲NoSQL就是CP或AP，关系数据库就是CA是不准确的。

对于CAP中C的理解，除了数据副本的一致性问题以外，分布式环境中还有两个非常重要的情形------事物&关联

事物

关系数据库中遵循ACID（原子性、一致性、独立性、持久性）原则，其中的C（一致性）是说，一个事物中关联的数据在事物操作结束后必须是一致的。例如银行存钱事物将导致银行流水中增加一条记录，同时账户的余额也必须相应的改变，这两个操作必须在一个事务中完成，保证数据的一致性（用户不希望存了钱，账户余额没变！银行不希望账户余额变多了，但却没有这条入账记录！），而之前说的CAP中的C是对同一数据的备份的读写一致性问题，乍看不同，其实都是一个道理：数据请求会等待多个相关数据操作完成后才返回。

在实践中，如果我们扩展数据容量而采用分部存储的话，事务的一致性要求不能降低，自然可用性就会降低，所以一般都采用不分散存储。这也说明，我们的关系数据库由于这个原因，扩展性（分区容错性P）受到了限制，这个是符合CAP理论的。关系数据库应该具有强大的事务功能，因此如果分区可扩展，那么可用性就会降低，所以一般不扩展分区。 NoSQL数据库则弱化甚至去除了事务的概念，因而分区可扩展性就加强了。

关联

再看分布式环境中的关联，乍看，关系数据库中常用的关联操作与CAP不沾边，但仔细思考也能用来解释分区扩展对关联造成影响。当采用分区扩展技术后，数据被分散了，关联操作的性能就会下降，当我们要保证数据的高可用性，同时要实现强大的关联操作，那么分区可扩展性就会受到限制。（好比说将学生表、课程表、学生选课表都放在不同的分区上，那么要实现对一个学生信息进行删除操作时，要通过关联来删除学生表和选课表中的数据，在保证关联操作这种一致性操作和高可用性时，那么对数据进行分区就是一个不明智的选择了）。NoSQL数据库弱化了甚至去除了关联操作，那么他的水平可扩展性就很高，但一致性就不能得到保证了，因此可以说是选择了AP牺牲了C。

总结

如果将CAP理论中的C理解为数据副本的读写一致性、事物与关联操作的合并概念，那么关系数据库就选择了CA，NoSQL数据库则在设计的大方向上都选择了AP（对于C，不同产品有不同的策略），而没有完全选择CP的。

参考文献：

何小朝. 纵横大数据[M]. 电子工业出版社, 2014.

浅谈CAP的理解

cap

什么是CAP？

CAP理论

为什么只能同时满足两个？

事物

关联

总结

相关阅读

栏目导航

推荐阅读

热门阅读