微服务分布式系统CAP理论与数据一致性抉择

分布式系统

我们知道分布式系统就是一个系统由多个组成部分共同构成，用户的一个请求可能会经过多个不同的计算机节点之后，通过运算才会把结果响应给用户，那么这个请求所经过的不同的几个系统就是分布式系统。对于用户来讲，你是不是分布式系统，对他来讲是透明的。参考如下图：

image.png

图中就表示一个用户在经历下单过程会经过多个系统，他们是分布式的，共同组成一个整体。

CAP 概念

在分布式系统中，必定会遇到CAP，如下：

• C（Consistency）：一致性
  • 在分布式系统中，所有的计算机节点的数据在同一时刻都是相同的，数据都是一致的。不能因为分布式导致不同系统拿到的数据不一致。也就是说，用户在某一个节点写了数据，在其他节点获得该数据的值是最新的；如若是更新操作，那么所有用户看到的也是更新后的新的值，不论哪个节点，不论集群，不论主备，获得的数据都是相同的。

    • 如下图：共有5个节点，往A节点去写，那么其他节点的数据在同一时间都是相同的，其他用户读取的时候也都是相同的，数据的一致性很强。

      
      image.png

• A（Availability）：可用性
  • 保证你的系统可用，也就是说无论任何时候，系统都可以被用户访问到，用户可以获得正常的响应结果。比如做好集群啊，做好主备啊等等，这个就是高可用。

    • 如下图：集群是一个整体，不论是否有节点宕机，那么作为整体，他还是可以继续对外提供服务的，保证了系统的可用性。

      
      image.png

• P（Partition tolerance）：分区容错性
  • 在整个分布式系统中，我们都是部署在不同的节点上，或者是不同的机房甚至是不同的地域，部署的时候会有一些子网，某一些服务会部署在不同的子网，每个子网就是一个区，也就是网络分区，分区和分区之间的通信也有可能出现通信故障。某个节点或者网络或者地域（分区）出现问题，整体整个系统还是照样能够提供一致性和可用性的服务。也就是说部分系统故障不会影响整体。为什么会这样，主要是因为有程序bug，计算机硬件问题，网络问题，网线被挖断了等等造成的综合因素。所以呢，我们的诉求就是即使小部分出问题，也要保全整体。并且对于任何分布式系统来讲，都需要去考虑分区容错的问题。
  • 附，以腾讯云为例，图中就有两处不同分区，第一个是在上海这个地域有不同的区域，不同区域通信走公网，可能有通信故障。其次就是私有网络，也就是子网络，他可以创建很多个，自己去定义不同的网段ip。

image.png

CAP 无法同时满足

如果从理论上来讲，以上三点C/A/P都应该满足吧，但是系统是人开发的，那肯定会或多或少有各种各样的问题。在分布式系统中同时满足这三点是不可能的。所以对于CAP来讲，只能满足其中两者，要么AP，要么CP，要么CA。如下图：

image.png

为什么会这样呢？我们举一个例子，来看一下CAP能不能同时满足，如下图：

image.png

上图中，ABCDE这5个节点都是分别部署在不同地域的机房的节点，假设现在我们的分区容错性P做的很好，保证不会出现网络方面的故障，这个时候我们来看一下一致性C和可用性A。现在有一个请求把数据写入到了A节点，随后用户的下一个请求要访问B节点，那么由于他们之间在不同的地域，数据同步需要有时间延迟，可能几百毫秒可能1-2秒。那么读请求要请求到一致的数据，就会被阻塞，阻塞的时候当前这个系统就不可用了，因为数据同步需要时间，所以此时的可用性A就无法满足，只能满足CP；那么再来看，假设要满足系统可用性，那么请求读到的数据，在节点同步的过程中就会是一个老的数据，数据就不能达到一致性C，所以这个时候就是AP。OK不？那么我们平时开发系统倒是在C和A之间取其一来搭配P的

组合搭配

那么 CP,AP,CA，这三种，哪个好呢？

• CP：满足一致性和分区容错的系统，性能不会很高，因为一致性是时时保持的。就比如说我提交一个订单，这个订单的数据要同步到各个系统，保证强一致性。那么这样用户请求大多都会被阻塞。需要耗时等待。redis，mongodb，hbase都是CP。（redis集群如果一个主节点挂了，那么slave成为master，他会有一个时间段导致不可用，A不满足）
• CA：满足一致性，满足可用性，一般来说都是以单体存在的集群架构，可扩展性不高。一般都是关系型数据库。
• AP：满足可用性和分区容错，那么这样就不是一致性了，往往会采用弱一致性，或者最终一致性。这也是通常用的最多的。 我们平时开发的系统就是以AP来展开工作的。

对于我们平时开发的时候，分区容错P是一定要满足的，因为我们在部署的时候往往都都是多节点集群部署，设置异地互备，比如北京机房和上海机房都提供服务 ，所以，一定要容错。

那么接下来我们要抉择一致性还是可用性呢？
一般来说，往往我们在大家网站架构的时候，我们都会采用AP，主流的互联网公司也是如此，也就是数据的弱一致性，因为要保证系统的整体的高可用性以及容错性。啥叫弱一致性，比如我们经常看头条，头条的点赞数评论数或者微博粉丝数，具体的数值每个人浏览的时候可能不一样，这个其实无所谓的，这就是弱一致性。而像Redis啊MongoDB这样的中间件，是CP，也就是要保证数据的一致性，因为毕竟要为网站提供数据服务的，一致性必须满足。

关于弱一致性

其实现在的互联网环境里，很多项目都不会采用强一致性，因为很难做，而往往采用弱一致性，因为用户可以接受。比如双11或者618的时候，订单蹭蹭蹭的海量增加，我们只需要关注订单下单成功就行，具体多少订单，具体多少金额，我们不会去实时的统计计算的，因为没必要，会在高峰期过后逐步去统计，慢慢的实现一致性。那么这个就是目前主流的做法。

但是一定要注意，数据层面的交互，关系型数据库，redis，mongodb等，他们肯定是强一致性，因为需要提供给你的网站数据服务。

数据的弱一致性

在保证数据库和缓存一致的情况之下，静态页面中的数据比如用户昵称可能会和后端数据库不一致，这是弱一致性的表现，如果要保证强一致性，则每个页面都必须和后端交互，但是如果有并发请求导致后端压力过大可能会导致这个接口所在的服务直接挂掉，如此一来系统不可用。
如果弱一致性，那么后端接口不会有那么大的压力，但是一致性会延后。以目前的互联网情况来讲，都是必须保证系统可用的前提下再去更新数据的一致性，在超高并发下，哪怕有脏数据，也要保证系统可用。这一点必须熟知。
以电商平台为例，首页的一些交易数据，比如商品销售数量，这个就是弱一致性的体现。
或者再按照某些系统来讲，用户信息修改以后，需要重新登录才会达到数据有效，这是让用户自己去做一次一致性，而不是让系统来自动做一致性。所以，很多场景下都是如此，都是先保可用性，再谈一致性。