摘要: 微服务架构流行的今天,一次交易需要跨越多个“服务”、多个数据库来实现,传统的技术手段,已经无法应对和满足微服务情况下这些复杂的场景了。针对微服务下的交易业务如何保障数据一致性,本文尽量做到理论结合实际,将我们在实际产品中用到的分布式事务实现机制,和大家扒一扒,希望能帮助到读者。
微服务架构流行的今天,一次交易需要跨越多个“服务”、多个数据库来实现,传统的技术手段,已经无法应对和满足微服务情况下这些复杂的场景了。针对微服务下的交易业务如何保障数据一致性,本文尽量做到理论结合实际,将我们在实际产品中用到的分布式事务实现机制,和大家扒一扒,希望能帮助到读者。
谈到分布式事务,必须先把”CAP"拿出来说说事......,当然还有”BASE"......
从架构的角度来看,业务拆分(数据分区)、数据一致性、性能(可用性)永远是个平衡的艺术:
1)在微服务架构下,为了获得更高的性能与灵活性,将业务应用拆分为多个,交易跨多个微服务编排,数据一致性的问题产生;
2)为了解决数据一致性问题,需要采用不同的事务机制来保障,这又会产生性能(可用性)问题;
在计算机世界里,为了解决一件事情,另外的问题就会接踵而至,从另一个层面印证了IT架构永远是一种平衡的艺术。
“BASE”其核心思想是根据业务特点,采用适当的方式来使系统达到最终一致性(Eventualconsistency);在互联网领域,通常需要牺牲强一致性来换取系统的高可用性,只需要保证数据的“最终一致”,只是这个最终时间需要在用户可以接受的范围内;但在金融相关的交易领域,仍然需要采用强一致性的方式来保障交易的准确性与可靠性。
分布式事务介绍
接下来为大家介绍业界常见的事务处理模式,包括两阶段提交、三阶段提交、Sagas长事务、补偿模式、可靠事件模式(本地事件表、外部事件表)、可靠事件模式(非事务消息、事务消息)、TCC等。不同的事务模型支持不同的数据一致性。如果读者对这几种分布式事务比较熟悉,可以直接参考下图并结合自身业务需求选择合适的事务模型。
一、两阶段提交、三阶段提交
这种分布式事务解决方案目前在各种技术平台上已经比较成熟:JavaEE架构下面的JTA事务(各应用服务器均提供了实现,tomcat除外)。
目前两阶段提交、三阶段提交存在如下的局限性,并不适合在微服务架构体系下使用:
1)所有的操作必须是事务性资源(比如数据库、消息队列、EJB组件等),存在使用局限性(微服务架构下多数使用HTTP协议),比较适合传统的单体应用;
2)由于是强一致性,资源需要在事务内部等待,性能影响较大,吞吐率不高,不适合高并发与高性能的业务场景;
二、Sagas长事务
在Sagas事务模型中,一个长事务是由一个预先定义好执行顺序的子事务集合和他们对应的补偿子事务集合组成的。典型的一个完整的交易由T1、T2、......、Tn等多个业务活动组成,每个业务活动可以是本地操作、或者是远程操作,所有的业务活动在Sagas事务下要么全部成功,要么全部回滚,不存在中间状态。
Sagas事务模型的实现机制:
1)每个业务活动都是一个原子操作;
2)每个业务活动均提供正反操作;
3)任何一个业务活动发生错误,按照执行的反顺序,实时执行反操作,进行事务回滚;
4)回滚失败情况下,需要记录待冲正事务日志,通过重试策略进行重试;
5)冲正重试依然失败的场景,提供定时冲正服务器,对回滚失败的业务进行定时冲正;
6)定时冲正依然失败的业务,等待人工干预;
Sagas长事务模型支持对数据一致性要求比较高的场景比较适用,由于采用了补偿的机制,每个原子操作都是先执行任务,避免了长时间的资源锁定,能做到实时释放资源,性能相对有保障。
Sagas长事务方式如果由业务去实现,复杂度与难度并存。在我们实际使用过程中,开发了一套支持Sagas事务模型的框架来支撑业务快速交付。
开发人员:业务只需要进行交易编排,每个原子操作提供正反交易;
配置人员:可以针对异常类型设定事务回滚策略(哪些异常纳入事务管理、哪些异常不纳入事务管理);每个原子操作的流水是否持久化(为了不同性能可以支持缓存、DB、以及扩展其它持久化方式);以及冲正选项配置(重试次数、超时时间、是否实时冲正、定时冲正等);
Sagas事务框架:提供事务保障机制,负责原子操作的流水落地,原子操作的执行顺序,提供实时冲正、定时冲正、事务拦截器等基础能力;
Sagas框架的核心是IBusinessActivity、IAtomicAction。IBusinessActivity完成原子活动的enlist()、delist()、prepare()、commit()、rollback()等操作;IAtomicAction主要完成对状态上下文、正反操作执行。
相关推荐
这是一个开撕的话题,我经历过太多的关于分布式事务的需求:“有没有简单的方案,像使用数据库事务那样,解决分布式数据一致性的问题”。特别是微服务架构流行的今天,一次交易需要跨越多个“服务”、多个数据库来...
由于分布式系统本身的复杂性,分布式事务的解决方案通常也较为复杂,需要在一致性、性能、复杂度等多个因素之间做出平衡。因此,对分布式事务的管理,不仅需要深入理解分布式计算的相关理论,还需要结合具体业务场景...
RocketMQ分布式事务是分布式系统中处理消息事务一致性的重要组件,它允许系统在分布式环境下进行可靠的事务消息传递。分布式事务通常面临CAP理论的挑战,即在一个分布式系统中,一致性(Consistency)、可用性...
TCC模式的优点在于提供了一种强一致性的事务处理方式,相比两阶段提交(2PC)等传统分布式事务处理方式,它减少了对资源锁定的时间,提高了系统的吞吐量。然而,它也存在缺点,如实现复杂度高,对开发人员的要求较高...
案例中可能会展示如何使用特定的框架或库来实现跨服务的事务一致性,以及在不同阶段事务是如何被协调和管理的。 对于分布式事务的监控和管理,也是一大挑战。分布式事务可能涉及多个服务,这就要求事务管理工具能够...
6. 性能与一致性的权衡:在实现分布式事务时,通常需要在系统性能和事务一致性之间进行权衡。例如,强一致性可能会牺牲系统的吞吐量和响应时间,因此开发者需要根据业务场景来决定一致性的级别。 【压缩包子文件的...
这类协议虽然可以确保数据的即时一致性,但同时也可能带来较高的延迟和较小的吞吐量,因为所有的数据更新都需要经过复杂的验证流程。 #### 二、强一致性与弱一致性 - **强一致性**指的是所有节点的数据始终保持...
分布式事务是一种在分布式系统中保证数据一致性、完整性的一种机制,它允许跨多个节点或数据库进行数据操作,同时保证这些操作要么全部成功,要么全部失败,以达到事务的原子性。TCC(Try-Confirm-Cancel)是分布式...
开发者在设计和实现分布式事务时需要综合考虑系统的需求和特点,选择合适的解决方案,并深入掌握相关的技术细节,以确保数据的一致性和系统的稳定性。了解和实践这些知识点对于构建和维护高性能、高可用的分布式系统...
分布式事务是指在一个分布式系统中,多个参与节点共同完成的一个业务操作。这些操作要么全部成功,要么全部失败,确保系统的整体一致性。分布式事务处理是分布式系统设计中非常重要的一环,尤其是在涉及多个服务或...
- **定义**:一种基于 BASE(基本可用、软状态、最终一致性)原则的事务模型,强调在一定程度上放宽一致性要求以换取更高的系统吞吐量。 - **优点**: - 提升系统性能:通过降低一致性要求,减少资源锁定时间,提高...
在微服务架构中,一个完整的业务逻辑可能涉及多个服务,每个服务都有自己的数据库,这就引入了跨数据库的事务需求,即分布式事务。传统的单数据库事务模型无法满足跨库事务的需求。 ### 常用的分布式事务解决方案 ...
一个专注于稳定、性能和分布式事务的MySQL数据库中间件,需要具备高效的数据处理能力、灵活的流量调度策略、以及强大的事务一致性保证。它在架构设计上要兼顾易用性和性能,在技术实现上需提供丰富的功能和良好的可...
分布式事务架构是现代大型互联网应用中不可或缺的一部分,它在微服务架构中扮演着关键角色,确保数据一致性并处理跨服务的复杂交易。本篇主要探讨了基于流计算的分布式事务解决方案,包括传统的两阶段提交(2PC)、...
2. 分布式事务:在分布式环境中,通过两阶段提交(2PC)或三阶段提交(3PC)协议协调各个节点,保证全局一致性。 3. 数据版本控制:采用乐观锁或悲观锁策略,防止并发操作导致的数据冲突。 4. 数据校验:在数据写入...
3. **两阶段提交(2PC)**:一种经典的分布式事务处理协议,通过预提交和提交两个阶段来确保数据的一致性。 4. **分布式锁机制**:通过加锁机制来控制并发操作,确保在同一时间只有一个操作可以修改数据。 5. **...
### 多库多事务降低数据不一致概率 #### 案例缘起 在实际的业务场景中,为了确保数据的正确性和完整性,通常会利用...对于业务架构师而言,如何在数据一致性和系统吞吐量之间找到最佳平衡点是一项极具挑战性的任务。
- **关系型数据建模与ACID一致性**:即使采用了分布式架构,Oracle 分片依然支持标准的关系型数据模型和ACID事务特性,确保数据的一致性和完整性。 - **SQL编程接口**:提供多种SQL编程接口,如PL-SQL、OCI、JDBC等...
分布式数据库技术在大数据时代扮演着至关...然而,实现分布式数据库也需权衡CAP原则,选择适合业务需求的一致性模型和事务处理策略。随着技术的发展,分布式数据库将不断优化,为大数据应用提供更高效、可靠的服务。