分布式 ACP

分布式系统中的三个重要特性:
**一致性(Consistency)
可用性(Availability)
分区容错性(Tolerance of network Partition)**

CAP原理是指这三个要素最多只能同时实现两点,不可能三者兼顾。因此在进行分布式架构设计时,必须做出取舍。而对于分布式数据系统,分区容忍性是基本要求,否则就失去了价值。因此设计分布式数据系统,就是在一致性和可用性之间取一个平衡。对于大多数WEB应用,其实并不需要强一致性,因此牺牲一致性而换取高可用性,是多数分布式数据库产品的方向。

一致性(Consistency)

一致性就是数据保持一致,在分布式系统中,可以理解为多个节点中数据的值是一致的,比如修改、添加,删除操作后能其他的节点能同时看到变化。同时,一致性也是指事务的基本特征或特性相同,其他特性或特征相类似。
由于分布式中最多只能同时实现CAP中的两点而分区容忍性是基本要求,所以就要在一致性和可用性两者之间取业务上的平衡,因此一致性分为了强一致性、弱一致性。

  1. 强一致性:

强一致性可以理解为在任意时刻,所有的分布式节点中的数据是一样的。比如当你在A服务中变更了数据后,在其他所有使用到该数据的服务中能马上看到你在A服务中对数据的变更。但是分布式中的强一致性一般都伴随着庞大的资源消耗,分为了线性化(Linearizable consistency)、顺序一致性(Sequential consistency)

  1. 弱一致性:

弱一致性最后也是会实现一致性的,只是相对于强一致性来说,它在一致性中间是有一段等待时间的,这段时间就是“不一致性窗口”,也就是说当你在A服务中变更了数据后,在使用到该数据的服务中不能马上看到你在A服务中对数据的变更,这是需要时间的,当“不一致性窗口”过去后我们才能看到其他服务中的数据一致,这段时间是不固定的,弱一致性又分为因果一致性 (Causal consistency)、最终一致性(Eventual consistency)

  • 因果一致性 (Causal consistency):

因果一致性可以理解为是最终一致性的变种,当一个读操作后面跟着一个写操作时,这两个事件就具有潜在的因果关系,同样,读操作也与为读操作提供数据的写操作因果相关。没有因果关系的操作被称为并发的。
所有进程必须以相同的顺序看到具有潜在因果关系的写操作,不同机器上的进程可以以不同的顺序被看到并发的写操作。
实现因果一致性要求跟踪哪些进程看到了哪些写操作。这就意味着必须构建和维护一张记录哪些操作依赖于哪些操作的依赖关系图。一种实现方法是向量时间戳。 如果进程 A 通知进程 B 它已经更新了一个数据项,那么进程 B 的后续访问将返回更新后的值,并且写操作将被保证取代前一次写入。和进程 A 没有因果关系的 C 的访问将遵循正常的最终一致性规则。

  • 最终一致性(Eventual consistency):

是系统保证如果没有对某个对象的新更新操作,最终所有的访问将返回这个对象的最后更新的值。这里就有比较多的取舍了, 比如最终是多久之类的,比如我现在A服务上做的一个操作将会更新多个不同服务上的数据,在B服务上将收到将会修改这一服务上的数据后,C服务也要修改相关数据,这个时候他得到的数据数据将会是B修改后的最终数据,其中A服务修改的

数据也在这就是最终一致性。可用性(Availability)

可用性就是分布式系统中某一个服务在某台或者多台台服务器出问题后,在其他服务器上依然能够完成用户的操作,比如当用户签到时,在领取签到奖励时有一个提供领取签到奖励服务的服务器出现问题后将会将这个任务移交给其他提供这个服务的服务器执行,不让用户领不到奖励的情况发生。

分区容错性(Tolerance of network Partition)

分区容错性就是整个系统集群中有单台服务器,或多台服务器出现故障后(不是提供的同一个服务),正常服务的服务器依然能正常提供服务,并且满足设计好的一致性和可用性 。

这个我只是根据我自己的理解写的,我也是一个刚学习这个的菜鸟,有什么不对的地方望大佬指点,
有兴趣的朋友可以加群我们一起讨论交流,群里有很多的资料,还有一位学习资料的叮当猫,群号:606278528

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值