一篇文章彻底搞懂“分布式事务”
文章图片
为什么需要分布式事务
由于近十年互联网的发展非常迅速,很多网站的访问越来越大,集中式环境已经不能满足业务的需要了,只能按照业务为单位进行数据拆分(包含:垂直拆分与水平拆分),以及按照业务为单位提供服务,从早期的集中式转变为面向服务架构的分布式应用环境。
举一个典型的例子,阿里的淘宝网站随着访问量越来越大,只能按照商品、订单、用户、店铺等业务为单位进行数据库拆分,以及按照业务为单位提供服务接口。
文章图片
这个时候 为了完成一个简单的业务功能,比如:购买商品后扣款,有可能需要横跨多个服务,涉及用户订单、商品库存、支付等多个数据库,而这些操作又需要在同一个事务中完,这就涉及到到了分布式事务。
本质上来说,分布式事务就是为了保证不同资源服务器的数据一致性。
分布式的一致性理论
最早加州大学伯克利分校 Eric Brewer教授提出一个分布式系统特性的CAP理论。
1.CAP 理论的不可能三角
文章图片
- 一致性(Consistency)
- 可用性(Availability)
- 分区容错性(Partition tolerance)
一句话总结:一致性、可用性和分区容错在分布式事务中不可兼得。
在绝大多数的场景,都需要牺牲强一致性来换取系统的高可用性,系统往往只需要保证最终一致性。
这也是是后来发展出的BASE理论的基础。
2.BASE 理论
文章图片
- Basically Available(基本可用)
- Soft state(柔软状态)
- Eventually consistent(最终一致性)三个短语的简写。
分布式事务的解决方案 1.基于XA协议的两阶段提交 2PC(2-phase commit protocol) XA是一个分布式事务协议,XA中大致分为两部分:事务管理器和本地资源管理器,其中本地资源管理器往往由数据库实现,而事务管理器作为全局的调度者,负责各个本地资源的提交和回滚。
文章图片
大致的流程:
第一阶段是表决阶段,所有参与者都将本事务能否成功的信息反馈发给协调者;
第二阶段是执行阶段,协调者根据所有参与者的反馈,通知所有参与者,步调一致地在所有分支上提交或者回滚。
优缺点
尽量保证了数据的强一致,实现成本较低,在各大主流数据库都有自己实现,存在单点故障问题、性能问题、跨数据库问题。
2.事务补偿TCC模式 TCC方案其实是两阶段提交的一种改进,将整个业务逻辑的每个分支显式的分成了Try、Confirm、Cancel三个操作。
Try部分完成业务的准备工作,confirm部分完成业务的提交,cancel部分完成事务的回滚,基本原理如下图所示:
文章图片
优缺点
对代码有侵入性,降低了锁冲突,提高了吞吐量,缺点是有时候并没有那么好实现。
案例
蚂蚁金服的DTS(prepare、commit、rollback)
3.消息队列最终一致性方案 通过异步解耦的方式,通过第三方中间件
文章图片
案例
RocketMQ RabbitMQ等均可实现,RocketMQ 还有专门的事务型消息,新版的kafka也有。
总之,分布式系统中事务更多的是对CAP权衡,在实际应用中,根据业务要求、开发人员情况以及所用框架不同进行调整。
下面分享我这些年总结的一些Java后端架构以及面试资料,希望能帮助到还在努力奋斗的码农们。
文章图片
【获取方式】
关注+转发后,私信回复【Java】即可获取!
【一篇文章彻底搞懂“分布式事务”】重要的事情说三遍,关注+转发、关注+转发、关注+转发,然后私信,才可以拿到哦!
推荐阅读
- 宽容谁
- 一个人的旅行,三亚
- 第6.2章(设置属性)
- 布丽吉特,人生绝对的赢家
- 家乡的那条小河
- 讲述,美丽聪明的海欧!
- PMSJ寻平面设计师之现代(Hyundai)
- 夜游宫|夜游宫 心语
- 增长黑客的海盗法则
- 画画吗()