摘要: 微服务架构流行的今天,一次交易需要跨越多个“服务”、多个数据库来实现,传统的技术手段,已经无法应对和满足微服务情况下这些复杂的场景了。针对微服务下的交易业务如何保障数据一致性,本文尽量做到理论结合实际,将我们在实际产品中用到的分布式事务实现机制,和大家扒一扒,希望能帮助到读者。
微服务架构流行的今天,一次交易需要跨越多个“服务”、多个数据库来实现,传统的技术手段,已经无法应对和满足微服务情况下这些复杂的场景了。针对微服务下的交易业务如何保障数据一致性,本文尽量做到理论结合实际,将我们在实际产品中用到的分布式事务实现机制,和大家扒一扒,希望能帮助到读者。
谈到分布式事务,必须先把”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主要完成对状态上下文、正反操作执行。
相关推荐
这是一个开撕的话题,我经历过太多的关于分布式事务的需求:“有没有简单的方案,像使用数据库事务那样,解决分布式数据一致性的问题”。特别是微服务架构流行的今天,一次交易需要跨越多个“服务”、多个数据库来...
这类协议虽然可以确保数据的即时一致性,但同时也可能带来较高的延迟和较小的吞吐量,因为所有的数据更新都需要经过复杂的验证流程。 #### 二、强一致性与弱一致性 - **强一致性**指的是所有节点的数据始终保持...
分布式事务是指在一个分布式系统中,多个参与节点共同完成的一个业务操作。这些操作要么全部成功,要么全部失败,确保系统的整体一致性。分布式事务处理是分布式系统设计中非常重要的一环,尤其是在涉及多个服务或...
- **定义**:一种基于 BASE(基本可用、软状态、最终一致性)原则的事务模型,强调在一定程度上放宽一致性要求以换取更高的系统吞吐量。 - **优点**: - 提升系统性能:通过降低一致性要求,减少资源锁定时间,提高...
在微服务架构中,一个完整的业务逻辑可能涉及多个服务,每个服务都有自己的数据库,这就引入了跨数据库的事务需求,即分布式事务。传统的单数据库事务模型无法满足跨库事务的需求。 ### 常用的分布式事务解决方案 ...
分布式事务架构是现代大型互联网应用中不可或缺的一部分,它在微服务架构中扮演着关键角色,确保数据一致性并处理跨服务的复杂交易。本篇主要探讨了基于流计算的分布式事务解决方案,包括传统的两阶段提交(2PC)、...
2. 分布式事务:在分布式环境中,通过两阶段提交(2PC)或三阶段提交(3PC)协议协调各个节点,保证全局一致性。 3. 数据版本控制:采用乐观锁或悲观锁策略,防止并发操作导致的数据冲突。 4. 数据校验:在数据写入...
3. **两阶段提交(2PC)**:一种经典的分布式事务处理协议,通过预提交和提交两个阶段来确保数据的一致性。 4. **分布式锁机制**:通过加锁机制来控制并发操作,确保在同一时间只有一个操作可以修改数据。 5. **...
### 多库多事务降低数据不一致概率 #### 案例缘起 在实际的业务场景中,为了确保数据的正确性和完整性,通常会利用...对于业务架构师而言,如何在数据一致性和系统吞吐量之间找到最佳平衡点是一项极具挑战性的任务。
- **关系型数据建模与ACID一致性**:即使采用了分布式架构,Oracle 分片依然支持标准的关系型数据模型和ACID事务特性,确保数据的一致性和完整性。 - **SQL编程接口**:提供多种SQL编程接口,如PL-SQL、OCI、JDBC等...
分布式数据库技术在大数据时代扮演着至关...然而,实现分布式数据库也需权衡CAP原则,选择适合业务需求的一致性模型和事务处理策略。随着技术的发展,分布式数据库将不断优化,为大数据应用提供更高效、可靠的服务。
这些模式可以根据业务对事务一致性的容忍度来选择,以平衡性能和数据一致性。 **四、数据库加密** 数据安全是企业信息系统的重要组成部分。ShardingSphere支持透明数据加密,可以在数据传输和存储过程中对敏感信息...
1. **两阶段提交 (2PC)**:一种经典的分布式事务处理协议,协调参与者之间的事务提交,确保原子性和持久性,但可能存在死锁和延迟问题。 2. **三阶段提交 (3PC)**:2PC的扩展,引入了中止操作,以解决死锁问题,但...
在解决传统分布式数据库中的事务一致性问题上,TBase采取了创新的解决方案,确保了在分布式环境下的数据一致性。 **TBase产品架构** TBase的架构主要包括以下几个关键组件: 1. **Coordinator(协调节点CN)**:...
- 提升系统的吞吐量和响应时间,满足高并发访问需求。 - 实现数据的高可用性和容错性,确保业务连续性。 - 确保数据的一致性,满足不同业务场景的强一致性或最终一致性要求。 - 降低运维复杂性,提供易于管理和监控...
分布式技术选型不仅仅包含选择合适的服务框架,还应考虑网络通信机制、数据一致性保障、故障转移机制和分布式事务管理等关键问题。 例如,分布式服务框架中的Spring Cloud不仅能够帮助我们快速构建分布式系统,还能...
分布式秒杀系统是一种在高并发环境下处理大量用户请求的技术,常用于电商平台的限时...这涉及到如限流算法(如漏桶、令牌桶)、分布式事务处理、数据一致性保证等多个高级主题,是理解分布式系统设计和实践的重要案例。
总结来说,Tx-Lcn 5.0.2.RELEASE作为一个强大的分布式事务管理器,为解决分布式环境下的事务一致性问题提供了有力工具。无论是TCC还是Saga模式,都能有效地帮助开发者构建高可用、高并发的分布式系统。在实际项目中...
GTS是一种高性能、高可用的分布式事务协调服务,它支持跨数据库、跨服务的分布式事务处理,确保在分布式环境中的多个操作能够原子化执行,即所有操作要么全部成功,要么全部失败,从而实现ACID(原子性、一致性、...