业务开发算法 50 讲
黄清昊
Hashdata 数据库内核工程师,LeetCode 高赞答主,公众号微扰理论作者
23293 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 51 讲
业务开发算法 50 讲
15
15
1.0x
00:00/00:00
登录|注册

36|分布式事务:如何理解两阶段提交?

协调者失败
参与者失败
3. 处理提交失败的情况
2. 参与者完成事务提交
1. 协调者指示参与者提交事务
3. 协调者收集投票结果
2. 参与者准备事务并记录日志
1. 协调者发起投票请求
核心思想:引入协调者来管理分布式事务
目的:在分布式系统中保证事务的原子性
性能优化的可能性
两阶段提交协议的弊端
分布式系统中全局信息的获取
两阶段提交协议的作用和重要性
协调者宕机导致的系统不可用
性能问题
分阶段处理减少了错误的可能性
保证了分布式事务的一致性
异常处理
提交阶段
投票阶段
分布式系统中的事务性挑战
单体应用中的事务保证
例子:用户创建过程中的事务性需求
微服务架构下的事务性问题
分布式应用场景中的挑战
课后思考
总结
协议的缺点
协议的优点
两阶段提交协议
事务的原子性
分布式事务问题
分布式事务与两阶段提交

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

你好,我是微扰君。
今天我们来聊一个经典问题“分布式事务”,以及它的常见解决方案“两阶段提交”。
关于事务,我们之前在介绍日志型文件系统的时候就已经一起学习过了(戳这里复习),主要特点就是需要保证在应用程序中,一系列连续操作要么全部成功执行,要么一个都不能执行,这个特点我们一般也称为原子性。
在单体应用中,通常用来保证事务特性的主要手段就是引入日志,比如 MySQL 中的 redo log 就是这样一种通过日志保证数据完整性的机制。
但是随着互联网不断发展,我们的应用规模也在稳固提升,单机服务已经没有办法满足需要,分布式系统自然而然也就登上了历史舞台。在分布式系统下,如何保证应用的事务性,就是所谓的分布式事务问题,也是我们今天要研究的内容。

分布式事务问题

在分布式应用场景中,分布式事务问题是不可回避的,在目前流行的微服务场景下更是如此。
我来举一个工作遇到的实际例子。在我参与开发的一款云产品的建设中,我们引入了开源的 Keycloak 组件,作为用户鉴权和账号创建的认证中心服务,但同时,因为业务也有许多和用户相关的字段需要在创建用户时生成,这一部分数据我们最终选择在数据库中自行维护。
因此,创建用户的步骤就分成了两个部分,首先要去 Keycloak 中创建账号,然后再在我们的数据库中存储一些额外的用户信息数据。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

分布式事务是分布式系统中不可避免的问题,特别是在微服务场景下。本文介绍了分布式事务的问题以及常见解决方案——两阶段提交协议。在分布式系统中,保证事务的原子性需要引入一个有全局信息的协调者,通过将事务提交分成投票和提交两个阶段,最终保证整个系统在大部分时刻都处于正确的状态。两阶段提交协议通过投票和提交两个阶段,保证了事务的一致性,但也存在一些弊端,需要进一步提高性能,减少系统的阻塞情况。文章通过实际例子和技术细节生动地介绍了两阶段提交协议的工作原理和应对失败情况的处理方式,为读者提供了深入理解分布式事务和两阶段提交协议的基础知识。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《业务开发算法 50 讲》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(2)

  • 最新
  • 精选
  • 有个问题,老师说: C阶段失败的话:有全局信息的协调者,如果收到了任意参与者发来的提交失败或者等待超时,都应该像第一个阶段一样,立刻终止事务,并向所有参与者发起回滚的请求。 如果收到失败或者超时前,有部分参与者已经commit了,这个怎么回滚?感觉没办法吧。
    2022-08-30归属地:上海
    3
    3
  • shupian416
    在提交阶段有部分参与者已committed了,部分参与者失败了,后续是如何处理的?没有表述清楚!
    2023-09-16归属地:北京
收起评论
显示
设置
留言
2
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部