技术资讯:分布式事务

Posted ECP微服务

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了技术资讯:分布式事务相关的知识,希望对你有一定的参考价值。

在《微服务架构与ECP》一文中,提到微服务面临着分布式事务的挑战。本文就这个问题,与大家进行一些关于分布式事务知识学习与探索。
事务是由一组操作构成的可靠、独立的工作单元。具有ACID特性,即Atomicity(原子性)、Consistency(一致性)、Isolation(隔离性)、Durability(持久性)。说的简单一点就是所有操作要么成功,要么回到初始状态。这个难点就是在高度并发、资源分布、大时间跨度的环境下,如何保证高性能运行。
对于分布式事务,目前业界的解决方案,一种是两阶段提交,一种就是事务补偿,还有一种是复合模式(TCC模式)。下面分别介绍这三种方案。

1、 两阶段提交:所谓的两个阶段是指:准备阶段和提交阶段。见下图:




将提交分成两阶段进行的目的很明确,就是尽可能晚地提交事务,让事务在提交前尽可能地完成所有能完成的工作,这样,最后的提交阶段将是一个耗时极短的微小操作,这种操作在一个分布式系统中失败的概率是非常小的,也就是所谓的“网络通讯危险期”非常的短暂,这是两阶段提交确保分布式事务原子性的关键所在。这也是一种实时一致性的事务模式,具备通用性的特点,所有分布式应用在不更改业务的前提下,都可以使用这种模式。但是它的缺点也同样明显:带来协议成本、准备阶段的持久成本、全局事务状态的持久成本、潜在故障点多带来的脆弱性、准备后,提交前的故障引发、一系列隔离与恢复难题。说得简单一点,就是性能不高,为了保证0.1%失败操作安全,而浪费了99.9%正常操作的性能。

2、 事务补偿:事务补偿机制即在事务链中的任何一个正向事务操作,都必须存在一个完全符合回滚规则的可逆事务。如果是一个完整的事务链,则必须事务链中的每一个业务服务或操作都有对应的可逆服务。这种事务机制,允许数据暂时的不一致性,但是数据会最终一致性。BASE(BA:Basic Availability、S: Soft state、E: Eventuall consistency)策略中的基于消息的最终一致性是比较好的解决方案。这种方案真正实现了两个服务的真正解耦,解耦的关键就是异步消息和消息持久化机制。见下图:




业务活动的主动方,在完成业务处理的同一个本地事务中,记录消息数据、业务处理事务提交后、通过消息服务通知业务被动方,通知成功后删除消息数据;消息恢复系统定期找到未成功发送的消息,交给消息服务补发送。这种方式必需保证消息服务的可靠性,在业务服务调用的时候,必需保证业务服务的幂等性(重复调用多次产生的业务结果与调用一次产生的业务结果相同)。这种方式,也可以叫分段式事务。很明显, 每一个事务域的性能都很高,这充分保证系统的可用性,牺牲了一致性。这种事务的场景也经常有,比如银行周六转款,客户可能下周一才得到通知到账。这种模式降低了用户体验,需要考虑用户的容忍程度。

3、 复合模式(TCC模式),TCC是Try - Confirm - Cancel,一个事务也是分成两个阶段提交,但是在Try操作可以灵活选择业务资源的锁定粒度。而不是由数据库控制。这种业务资源的锁定必需是可以事务补偿的,当进行Cancel时候,能进行回退。见下图:




Try: 尝试执行业务,完成所有业务检查(一致性),预留必须业务资源(准隔离性);Confirm:确认执行业务,真正执行业务,不作任何业务检查,只使用Try阶段预留的业务资源,Confirm操作满足幂等性;Cancel: 取消执行业务,释放Try阶段预留的业务资源,Cancel操作满足幂等性。这种模式能在一致性(准一致性)与可用性中获得比较好的平衡,但是有比较高的开发成本。
上面介绍的几种模式,各有利弊,必需考虑具体的应用场景。企业应用使用第一种模式是主流;对于互联网应用,第三种是主流,高并发的核心业务也使用第二种。对于微服务架构,推荐第三种模式,因为“平衡”是一个很好的理由。

以上是关于技术资讯:分布式事务的主要内容,如果未能解决你的问题,请参考以下文章

用户积分技术揭秘之分布式事务

搞懂分布式技术17,18:分布式事务总结

分布式技术专题「架构实践于案例分析」总结和盘点目前常用分布式事务特别及问题分析(上)

搞懂分布式技术19:使用RocketMQ事务消息解决分布式事务

分布式技术专题「架构实践于案例分析」总结和盘点目前常用分布式事务特别及问题分析(中)

这些分布式事务技术点,你知道吗?