当前位置:首页 > 经验

微服务和分布式的区别 分布式是什么概念

先不管CAP是什么,就谈谈对于一个分布式的系统,它有哪些特征或行为。

(1)分布式系统会把服务部署在多个节点上

(2)每个节点都有可能存储数据,一份数据可能在多个节点上有副本

(3)节点之间通过网络进行数据的同步

假设有个服务,需要部署在3个节点上,每个节点都需要存储同一份数据id,id的初始值都是1。

常说的分布式系统核心理论CAP与BASE到底是什么

现在对节点1写入id=2,当网络正常的情况下,节点1会向节点2与节点3进行数据同步,此时3个节点的id值都是2。不管访问哪个节点,读取的id都是一样的值

常说的分布式系统核心理论CAP与BASE到底是什么

再对节点1写入id=3时,由于此时发生网络闪断,节点1无法联系到节点2与节点3,那么此时访问节点1与节点2将会得到不一样的值,出现了不一致性

常说的分布式系统核心理论CAP与BASE到底是什么


CAP理论是分布式系统中的核心理论,由三个单词的首字母组成,分别是

C(Consistence)一致性,对于指定的副本数据,访问任意一个节点,都能读到相同的值。

A(Availability)可用性,访问非故障的节点,总能在合理的时间内得到合理的响应。

P(Partition Tolerance)分区容错性,发生网络分区时,整个系统依然能对外提供服务。

一致性

对节点1执行数据更新的操作后,如果不进行同步操作,这个时候再去读取节点2的数据,就会得到不一样的结果,从而产生不一致。如果任意用户能在任意时间访问不同节点,都能得到相同的数据,那么这个分布式系统就是强一致的

CAP中的C代表的就是强一致性,并且不考虑数据同步之间的延迟。

此外,还有

弱一致性,指的是在更新某个节点的数据之后,访问其余一小部分的节点得不到最新的结果。

最终一致性,指的是某个节点的数据之后,在一段时间内访问其他节点得不到最新的结果,但在稍后的某一个时刻,能够得到最新的结果。

可用性

指的是能在合理的时间内得到合理的响应,或者说在有限的时间内得到一个可以理解的响应。对于不同的系统,有不同的“有限时间”。“可以理解的响应”指的是要么返回执行成功,要么执行失败(但状态码是200),而不是返回404、500等

分区容错性

网络分区指的是,由于网络是不可靠的,本来A机房与B机房可以互相访问,是一个整体。当A机房与B机房的光纤断了,A机房便不能与B机房进行通信,整体被划分成了两个区域(区域内部是可以互相通信的),于是网络也被划分成了两个区域,形成所谓的网络分区


对于一个分布式系统,发生网络分区是必然存在的。必定不发生网络分区的系统,那就是一个单体系统,并不是分布式系统。

当然,一个分布式系统,在极端的情况下,如果要牺牲P保证AC也是可以的。

一般来说,分布式系统都会选择满足P。

那么,剩余的CA可以同时满足吗?

先说结论,在存在网络分区的情况下(即满足P),那就不可以同时满足A与C

假设节点1存在于分区a中,节点2与节点3存在于分区b中。

常说的分布式系统核心理论CAP与BASE到底是什么


此时修改节点1的副本数据,将id变为2

常说的分布式系统核心理论CAP与BASE到底是什么

由于存在网络分区,无法将id的新值2同步到其他分区的节点下。

如果此时要满足A(可用性),且节点2与节点3只是在另外一个分区中,并没有发生节点本身的故障,由可用性的定义,三个节点都可以进行访问。

此时用户访问节点1,得到id=2,访问节点2时,得到id=1,发生数据不一致的情况。

所以,满足A的情况下,就满足不了C(一致性)。

如果一开始要满足C呢?

为了保证访问各个节点,都能用户最新更新的值,就要禁止任何对节点2与节点3的读写操作,这就违背了A。

所以,在满足C的情况下,就满足不了A。


既然在发生网络分区的时候,不能同时满足A与C,那么怎么在两者之间进行权衡呢?

选择AP

在发生网络分区的情况下,选择可用性,就要放弃一致性。

Eureka就是典型的AP系统

在Eureka集群中,各个server节点没有主从之分,都是相互平等的个体。

各个server节点会互相复制数据,产生冲突时,直接用最新的数据覆盖掉旧数据即可。

每一个client只会向一个server节点注册,server会将该client的ip等信息放入到注册列表中。

之后client会向server节点定时发送心跳并同时拉取注册列表到client的本地缓存中,超过一定时间不发送,server会将该client从注册列表中剔除。

如果一个client下线,首先需要过一段时间才能在server的注册列表中体现出来,随后才能在其他的client上的本地缓存中体现出来。因此client上本地缓存中的服务注册数据并不是最新的,因此这里不能保证强一致性。

一个server节点宕机或出现网络分区联系不上其他节点,其他节点仍然能提供注册与查询服务,因此保证了可用性。该server节点没有将自己的注册列表同步到其他节点,就会使得部分client的注册信息丢失,因此这里不能保证一致性。

当上述server节点重新上线或网络稳定后,就能将当前的注册列表同步到其他节点,整体又能达到最终一致性。

Eureka作为一个专门的服务注册与发现的系统,能够容忍数据不一致的情况(例如当A调用B,B已经下线,但A查询server时,依然能够获得B的注册信息。A随后发起对B的调用,结果肯定是调用失败,这个时候A选择重试或者直接熔断即可)。即使发生不一致的情况,也基本上是少数数据的不一致,如果这个时候直接强行让注册中心不可用,显然是忍受不了的。

声明:此文信息来源于网络,登载此文只为提供信息参考,并不用于任何商业目的。如有侵权,请及时联系我们:fendou3451@163.com
标签:

  • 关注微信

相关文章