没有合适的资源?快使用搜索试试~ 我知道了~
分布式系统一致性(ACID、CAP、BASE、二段提交、三段提交、TCC、幂等性)原理详解1
需积分: 0 10 下载量 173 浏览量
2022-08-03
23:11:53
上传
评论 1
收藏 2.06MB PDF 举报
温馨提示
试读
37页
1背景分布式系统致性(ACID、CAP、BASE、段提交、三段提交、TCC、幂等性)原理详解-掘的是按照功能拆分,秉着 “专业的人干专业的事儿” 的原则,把
资源推荐
资源详情
资源评论
2019/5/13
分
布
式
系
统
⼀
致
性
(
ACID
、
CAP
、
BASE
、
⼆
段
提
交
、
三
段
提
交
、
TCC
、
幂
等
性
)
原
理
详
解
-
掘
⾦
https://juejin.im/post/5c9443406fb9a070fe0dd9a9#heading-21 1/37
分布式系统一致性(ACID、CAP、
BASE、二段提交、三段提交、TCC、幂等
性)原理详解
一致性是一个抽象的、具有多重含义的计算机术语,在不同应用场景下,有不同的定义和含
义。在传统的 IT 时代,一致性通常指强一致性,强一致性通常体现在你中有我、我中有你、
浑然一体;而在互联网时代,一致性的含义远远超出了它原有的含义,在我们讨论互联网时
代的一致性之前,我们先了解一下互联网时代的特点,互联网时代信息量巨大、需要计算能
力巨大,不但对用户响应速度要求快,而且吞吐量指标也要向外扩展(既:水平伸缩),于
是单节点的服务器无法满足需求,服务节点开始池化,想想那个经典的故事,一只筷子一折
就断,一把筷子怎么都折不断,可见人多力量大的思想是多么的重要,但是人多也不一定能
解决所有事情,还得进行有序、合理的分配任务,进行有效的管理,于是互联网时代谈论最
多的话题就是拆分,拆分一般分为 “水平拆分” 和“垂直拆分”(大家不要对应到数据库或
者缓存拆分,这里主要表达一种逻辑)。这里,“水平拆分”指的是同一个功能由于单机节
点无法满足性能需求,需要扩展成为多节点,多个节点具有一致的功能,组成一个服务池,
一个节点服务一部分的请求量,团结起来共同处理大规模高并发的请求量。“垂直拆分”指
1 背景
2019/5/13
分
布
式
系
统
⼀
致
性
(
ACID
、
CAP
、
BASE
、
⼆
段
提
交
、
三
段
提
交
、
TCC
、
幂
等
性
)
原
理
详
解
-
掘
⾦
https://juejin.im/post/5c9443406fb9a070fe0dd9a9#heading-21 2/37
的是按照功能拆分,秉着 “专业的人干专业的事儿” 的原则,把一个复杂的功能拆分到多个
单一的简单的元功能,不同的元功能组合在一起,和未拆分前完成的功能是一致的,由于每
个元功能职责单一、功能简单,让维护和变更都变得更简单、安全,更易于产品版本的迭
代,在这样的一个互联网的时代和环境,一致性指分布式服务化系统之间的弱一致性,包括
应用系统一致性和数据一致性。
无论是水平拆分还是垂直拆分,都解决了特定场景下的特定问题,凡事有好的一面,都会有
坏的一面,拆分后的系统或者服务化的系统最大的问题就是一致性问题,这么多个具有元功
能的模块,或者同一个功能池中的多个节点之间,如何保证他们的信息是一致的、工作步伐
是一致的、状态是一致的、互相协调有序的工作呢?
本节列举不一致会导致的种种问题,这也包括一例生活中的问题。
假如你想要享受生活的随意,只想买个两居,不想让房贷有太大压力,而你媳妇却想要买个
三居,还得带花园的,那么你们就不一致了,不一致导致生活不愉快、不协调,严重情况下
还会吵架,可见生活中的不一致问题影响很大。
2 问题
案例 1:买房
案例 2:转账
2019/5/13
分
布
式
系
统
⼀
致
性
(
ACID
、
CAP
、
BASE
、
⼆
段
提
交
、
三
段
提
交
、
TCC
、
幂
等
性
)
原
理
详
解
-
掘
⾦
https://juejin.im/post/5c9443406fb9a070fe0dd9a9#heading-21 3/37
转账是经典的不一致案例,设想一下银行为你处理一笔转账,扣减你账户上的余额,然后增
加别人账户的余额;如果扣减你的账户余额成功,增加别人账户余额失败,那么你就会损失
这笔资金。反过来,如果扣减你的账户余额失败,增加别人账户余额成功,那么银行就会损
失这笔资金,银行需要赔付。对于资金处理系统来说,上面任何一种场景都是不允许发生
的,一旦发生就会有资金损失,后果是不堪设想的,严重情况会让一个公司瞬间倒闭,可参
考 案例 。
电商系统中也有一个经典的案例,下订单和扣库存如何保持一致,如果先下订单,扣库存失
败,那么将会导致超卖;如果下订单没有成功,扣库存成功,那么会导致少卖。两种情况都
会导致运营成本的增加,严重情况下需要赔付。
服务化的系统间调用常常因为网络问题导致系统间调用超时,即使是网络很好的机房,在亿
次流量的基数下,同步调用超时也是家常便饭。系统 A 同步调用系统 B 超时,系统 A 可以
明确得到超时反馈,但是无法确定系统 B 是否已经完成了预定的功能或者没有完成预定的功
能。于是,系统 A 就迷茫了,不知道应该继续做什么,如何反馈给使用方。(曾经的一个
B2B 产品的客户要求接口超时重新通知他们,这个在技术上是难以实现的,因为服务器本身
可能并不知道自己超时,可能会继续正常的返回数据,只是客户端并没有接受到结果罢了,
因此这不是一个合理的解决方案)。
案例 3:下订单和扣库存
案例 4:同步超时
2019/5/13
分
布
式
系
统
⼀
致
性
(
ACID
、
CAP
、
BASE
、
⼆
段
提
交
、
三
段
提
交
、
TCC
、
幂
等
性
)
原
理
详
解
-
掘
⾦
https://juejin.im/post/5c9443406fb9a070fe0dd9a9#heading-21 4/37
此案例和上一个同步超时案例类似,不过这个场景使用了异步回调,系统 A 同步调用系统 B
发起指令,系统 B 采用受理模式,受理后则返回受理成功,然后系统 B 异步通知系统 A。在
这个过程中,如果系统 A 由于某种原因迟迟没有收到回调结果,那么两个系统间的状态就不
一致,互相认知不同会导致系统间发生错误,严重情况下会影响核心事务,甚至会导致资金
损失。
分布式系统中,两个系统协作处理一个流程,分别为对方的上下游,如果一个系统中存在一
个请求,通常指订单,另外一个系统不存在,则导致掉单,掉单的后果很严重,有时候也会
导致资金损失。
这个案例与上面掉单案例类似,不同的是两个系统间都存在请求,但是请求的状态不一致。
交易相关系统基本离不开关系型数据库,依赖关系型数据库提供的 ACID 特性(后面介
绍),但是在大规模高并发的互联网系统里,一些特殊的场景对读的性能要求极高,服务于
交易的数据库难以抗住大规模的读流量,通常需要在数据库前垫缓存,那么缓存和数据库之
间的数据如何保持一致性?是要保持强一致呢还是弱一致性呢?
案例 5:异步回调超时
案例 6:掉单
案例 7:系统间状态不一致
案例 8:缓存和数据库不一致
2019/5/13
分
布
式
系
统
⼀
致
性
(
ACID
、
CAP
、
BASE
、
⼆
段
提
交
、
三
段
提
交
、
TCC
、
幂
等
性
)
原
理
详
解
-
掘
⾦
https://juejin.im/post/5c9443406fb9a070fe0dd9a9#heading-21 5/37
一个服务池上的多个节点为了满足较高的性能需求,需要使用本地缓存,使用了本地缓存,
每个节点都会有一份缓存数据的拷贝,如果这些数据是静态的、不变的,那永远都不会有问
题,但是如果这些数据是半静态的或者常被更新的,当被更新的时候,各个节点更新是有先
后顺序的,在更新的瞬间,各个节点的数据是不一致的,如果这些数据是为某一个开关服务
的,想象一下重复的请求走进了不同的节点(在 failover 或者补偿导致的场景下,重复请求
是一定会发生的,也是服务化系统必须处理的),一个请求走了开关打开的逻辑,同时另外
一个请求走了开关关闭的逻辑,这导致请求被处理两次,最坏的情况下会导致灾难性的后
果,就是资金损失。
这个案例会时有发生,某系统需要种某一数据结构的缓存,这一数据结构有多个数据元素组
成,其中,某个数据元素都需要从数据库中或者服务中获取,如果一部分数据元素获取失
败,由于程序处理不正确,仍然将不完全的数据结构存入缓存,那么缓存的消费者消费的时
候很有可能因为没有合理处理异常情况而出错。
案例 9:本地缓存节点间不一致
案例 10:缓存数据结构不一致
3 模式
3.1 生活中不一致问题的解决
剩余36页未读,继续阅读
资源评论
宝贝的麻麻
- 粉丝: 32
- 资源: 294
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功