后端存储实战课
李玥
美团高级技术专家
44005 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 30 讲
结束语 (1讲)
后端存储实战课
15
15
1.0x
00:00/00:00
登录|注册

05 | 分布式事务:如何保证多个系统间的数据是一致的?

缺陷
优点
适用性
实现思路
订单与购物车的数据一致性问题
缺陷
适用场景
异常情况
正常情况
二阶段提交
订单与优惠券的数据一致性问题
业务系统微服务化后的数据一致性问题
微服务化趋势
适用于什么样的业务场景
3PC和TCC
本地消息表
2PC
兼顾性能和高可用
ACID四个特性
分布式事务的实现原理
实际问题解决
跨系统、跨数据库的交易
思考题
分布式事务的解决方案
分布式事务的特性
分布式事务概念
数据一致性问题
分布式事务

该思维导图由 AI 生成,仅供参考

你好,我是李玥。
上节课,我和你一起通过账户系统学习了数据库事务,事务很好地解决了交易类系统的数据一致性问题。
事务的原子性和持久性可以确保在一个事务内,更新多条数据,要么都成功,要么都失败。在一个系统内部,我们可以使用数据库事务来保证数据一致性。那如果一笔交易,涉及到跨多个系统、多个数据库的时候,用单一的数据库事务就没办法解决了。
在之前大系统的时代,普遍的做法是,在设计时尽量避免这种跨系统跨数据库的交易。
但是,现在的技术趋势是云原生和微服务,微服务它的理念是什么?大系统被打散成多个小的微服务,每个微服务独立部署并且拥有自己的数据库,大数据库也被打散成多个小的数据库。跨越微服务和数据库的交易就成为一种越来越普遍的情况。我们的业务系统微服务化之后,不可避免地要面对跨系统的数据一致性问题。
如何来解决这种跨系统、跨数据库的数据一致性问题呢?你可能会脱口而出:分布式事务。但是,分布式事务可不像数据库事务那样,在开始和结尾分别加上 begin 和 commit,剩下的问题数据库都可以帮我们搞定。在分布式环境下,没有这么简单的事儿,为什么?
因为在分布式环境中,一个交易将会被分布到不同的系统中,多个微服务进程内执行计算,在多个数据库中执行数据更新操作,这个场景比数据库事务支持的单进程单数据库场景复杂太多了。所以,并没有什么分布式事务服务或者组件能在分布式环境下,提供接近数据库事务的数据一致性保证。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

分布式事务是解决跨多个系统、多个数据库间数据一致性问题的关键。随着云原生和微服务的兴起,跨系统交易变得更加普遍,因此需要解决分布式数据一致性问题。然而,分布式环境下的事务处理比单一数据库事务复杂得多,因此需要掌握分布式事务的实现原理。在分布式系统中,由于需要兼顾性能和高可用性,无法完全满足ACID特性,因此常用的分布式事务实现方法都是“残血版”的事务。常见的分布式事务解决方案包括2PC、3PC、TCC、Saga和本地消息表等,每种方法都有其适用的场景和优劣势。因此,了解并掌握这些分布式事务的解决方案,才能在实际问题中选择合适的方法。 2PC(两阶段提交)是一种常用的分布式事务实现方法,适用于对数据一致性要求较高的场景。它引入了事务协调者的角色,通过准备阶段和提交阶段来确保分布式事务的一致性。然而,2PC也存在一些缺陷,如阻塞服务端线程、单点故障等,因此在并发量不大且需要强一致性的场景下使用较为合适。 另一种解决方案是本地消息表,适用于需要保证最终一致性的场景。它的实现简单,性能好,能够满足大部分情况下的数据最终一致性要求。然而,本地消息表不适合有依赖资源的异步操作,如库存锁定等。 总的来说,了解分布式事务的不同解决方案,包括其优势和局限性,对于在实际应用中选择合适的方法至关重要。在实际应用中,需要根据业务场景的要求和系统的特点来选择合适的分布式事务解决方案,以达到数据一致性和系统稳定性的最佳平衡。 分布式事务的研究和实践仍在不断发展,对于读者来说,理解不同分布式事务方法的特点和适用场景,将有助于在实际工作中做出更明智的决策,确保系统的可靠性和性能。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《后端存储实战课》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(47)

  • 最新
  • 精选
  • 李玥
    置顶
    Hi,我是李玥。 这里说一下上节课的思考题: 课后希望你能动手执行一下我们今天这节课中给出的例子,看一下多个事务并发更新同一个账户时,RC 和 RR 两种不同的隔离级别,在行为上有什么不同? 这个思考题的主要目的还是希望你不要光是听和看,还要能真正动手去试一下,以便加深理解。RC和RR在并发更新数据的时候,都需要对数据加锁(一般是行锁)在二个事务同时更新一条记录的时候,先更新的那个事务会抢占到锁,在它结束事务之前,其它需要更新这条记录的事务都会卡住等待这个锁。这一点二种隔离级别是一样的。
    2020-03-07
    46
  • 小袁
    老师为啥不说下2pc情况下,一个db宕机重启的问题呢?是不是由一个脚本定期扫描发现有哪些订单出现异常的呢?

    作者回复: 由于事务执行器有超时机制,数据库本身也有事务超时机制,如果是第一阶段失败或者超时的话,会自动回滚。 对于第二阶段的问题,如果db宕机,确实有可能出现数据不一致的问题,对于这种情况,可以用脚本根据业务做一些补偿处理。

    2020-03-18
    3
    21
  • stanley
    在本地消息表方案的例子中,后续需要去清空购物车,同时要把之前记录在本地的那一条记录删掉,这是不是另一个分布式事务的问题?

    作者回复: 这个过程就不需要再用事务保证了,否则就死循环了。 可以先清空购物车,再删除本地消息(一般都是更新状态)。即使出现不一致,购物车清了,本地消息表没更新成功,下次再执行一次清空购物车,也问题不大。

    2020-03-29
    5
    13
  • 几字凉了秋丶
    老师,库存系统,锁定库存的一般操作是什么样的,可以说一说吗

    作者回复: 一般是直接减掉,但需要记录锁定库存的商品、时间戳,后续超时未支付的情况下,再把库存释放出来。

    2020-04-23
    2
    8
  • 1
    实现2pc是自己写吗?还是有第三方可以用?

    作者回复: 还是要自己实现的。

    2020-03-10
    5
    8
  • 乖,摸摸头
    锁定库存锁定,和用户余额 锁定 这种具体是怎么做的了? 是直接减掉吗? 比如我在下单的时候 库存减了,用户余额也减了,但是我没支付?这时我怎么处理了

    作者回复: 一般是先锁定库存,然后定时扫描未支付的订单,自动取消超时未支付订单,取消订单的流程中自然就会释放库存。 你会发现,很多秒杀活动要求支付时间都很短,就是这个原因。

    2020-05-11
    2
    7
  • Dovelol
    老师好,想问下2pc性能不好,该如何优化呢?我听说蚂蚁金服有方案是在大促的高峰将2阶段的第二阶段延后到低峰在唤起执行,因为如果第一阶段资源已经预留,基本上最终状态也已经确定了,业界有这种方案吗?

    作者回复: 你说的这种降级方案感觉像是降级成了本地消息表。

    2020-03-15
    9
    7
  • 旭东(Frank)
    老师好,订单和优惠券的两阶段提交,先提交优惠券还是先提交订单有没细微区别?

    作者回复: 理论上这两个RM是并行提交的,无所谓谁先谁后。要说细微区别,就是如果某一个数据库宕机后,数据不一致的情况会有区别。

    2020-03-20
    6
  • ray
    老师您好, 我对2pc有个疑问,如果是走http协定(发出response后连结就关闭了),实作上一般的程序要如何在参与者完成准备阶段后,持续将事务保持在未提交的状态,等待协调者告知可以提交事务? 谢谢老师的解答^^

    作者回复: 如果是HTTP协议的话,可以在RM(事务参与方)Session中,或者内存中维护进行中的事务,通过事务ID区分。 第二阶段提交命令从协调者发到RM上之后,根据事务ID查找对应的数据库会话,进行提交。

    2020-03-18
    3
    4
  • 划过天空阿忠
    就拿下单需要锁库存这个业务来说,下单接口调锁库存接口,锁定库存成功之后下单接口提交事务,锁定库存失败下单接口回滚事务。 其中最关键的一步是锁库存之后要重新调一下库存查询接口,检查是否真正锁定,若没有真正锁定,订单服务手动抛异常,回滚订单事务。 小弟浅薄理解,各位指点一下😄

    作者回复: 👍👍👍

    2020-03-27
    6
    3
收起评论
显示
设置
留言
47
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部