手记

【九月打卡】第15天 CAP理论及数据一致性抉择

课程名称:Spring Cloud 进阶 Alibaba 微服务体系自媒体实战
课程章节: 第3章 开发通行证有关服务
主讲老师: 风间影月

课程内容

分布式系统

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

CAP 概念

在分布式系统中,必定会遇到CAP,如下:

  • C(Consistency):一致性

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

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

  • A(Availability):可用性

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

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

  • P(Partition tolerance):分区容错性

    • 在整个分布式系统中,我们都是部署在不同的节点上,或者是不同的机房甚至是不同的地域,部署的时候会有一些子网,某一些服务会部署在不同的子网,每个子网就是一个区,也就是网络分区,分区和分区之间的通信也有可能出现通信故障。某个节点或者网络或者地域(分区)出现问题,整体整个系统还是照样能够提供一致性和可用性的服务。也就是说部分系统故障不会影响整体。为什么会这样,主要是因为有程序bug,计算机硬件问题,网络问题,网线被挖断了等等造成的综合因素。所以呢,我们的诉求就是即使小部分出问题,也要保全整体。并且对于任何分布式系统来讲,都需要去考虑分区容错的问题。


CAP 无法同时满足

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

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

上图中,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等,他们肯定是强一致性,因为需要提供给你的网站数据服务。

慕课新闻的弱一致性

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


课程截屏



0人推荐
随时随地看视频
慕课网APP