【分布式开发】之 CAP 原则一、CAP 的定义二、CAP 取舍策略

75 阅读 0 评论 50 点赞

我是靠谱客的博主时尚天空，最近开发中收集的这篇文章主要介绍【分布式开发】之 CAP 原则一、CAP 的定义二、CAP 取舍策略，觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

一、`CAP` 的定义

1、`C` 的全拼是 `Consistency`，表示一致性

其代表的意思是，在分布式系统中，某个节点的更新操作成功并返回客户端后，所有节点在同一时间的数据完全一致，这就是分布式的一致性。

由于各个节点进行数据同步时会消耗一定的时间，而一致性要求了数据要实时同步，所以，想要保证数据的一致性就不能部署过多的节点。

2、`A` 的全拼是 `Availability`，表示高可用性

其代表的意思是，在整个分布式系统中，服务要保持一直可用，即保证能够响应客户端的请求。因此在分布式系统中想要保证高可用性的话，就要求我们需要部署更多的节点，以保证部分节点挂掉之后不会影响服务供功能。

3、`P` 的全拼是 `Partition tolerance`，表示分区容错性

其代表的意思是，分布式系统在遇到某节点或网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务。

分区容错性要求表明，虽然系统是一个分布式系统，但看上去却好像是在一个可以运转正常的整体。比如现在的分布式系统中有某一个或者几个机器宕掉了，其他剩下的机器还能够正常运转满足系统需求，对于用户而言并没有什么体验上的影响。

二、`CAP` 取舍策略

1、`CAP` 原则

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

2、`CAP` 取舍策略

1）CA

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

2）CP

如果不要求A（高可用），相当于每个请求都需要在服务器之间保持强一致，而 P（分区）会导致同步时间无限延长(也就是等待数据同步完才能正常访问服务)，一旦发生网络故障或者消息丢失等情况，就要牺牲用户的体验，等待所有数据全部一致了之后再让用户访问系统。设计成CP的系统其实不少，最典型的就是分布式数据库，如 Redis、HBase 等。对于这些分布式数据库来说，数据的一致性是最基本的要求，因为如果连这个标准都达不到，那么直接采用关系型数据库就好，没必要再浪费资源来部署分布式数据库。

3）AP

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

总结：

现如今，对于多数大型互联网应用的场景，主机众多、部署分散，而且现在的集群规模越来越大，节点只会越来越多，所以节点故障、网络故障是常态，因此分区容错性也就成为了一个分布式系统必然要面对的问题。那么就只能在C和A之间进行取舍。但对于传统的项目就可能有所不同，拿银行的转账系统来说，涉及到金钱的对于数据一致性不能做出一丝的让步，C必须保证，出现网络故障的话，宁可停止服务，可以在A和P之间做取舍。