浪潮 inBuilder 低代码平台分布式微服务架构事务一致性技术解析
技术背景
在分布式系统中,随着应用的微服务化拆分,业务数据的存储模式由单机数据库架构向分布式数据库架构转变,各个微服务之间通过远程 REST 或 RPC 请求完成业务操作,产生了跨服务的分布式事务问题,需要解决一个服务调用中多个事务的数据一致性。
根据 CAP 原则,分布式系统只能同时满足(强)一致性(Constistency)、可用性(Avaliablility)和分区容错性(Partition tolerance)中的两项,而一个稳定可用的分布式业务系统,必须同时满足 A 与 P 两者,需要牺牲数据强一致性 C,转而追求数据的最终一致性,满足 BASE 理论的三大特性:基本可用(Basically Available)、软状态(Soft State)、最终一致性(Eventual Consistency)。
业界主流技术方案对比
1) XA 事务模式:
XA 是由 Tuxedo 首先提出,属于 X/Open 组织的分布式事务协议,XA 事务在数据库层面提供了对强一致、中心化的原子提交协议——两阶段提交协议(2PC)的支持,可实现分布式事务中数据的强一致性,但牺牲了系统的可用性,降低了系统的吞吐量。
2) 可靠消息队列事务模式:
可靠消息队列事务模式,是当本地事务发起方执行完成本地事务后,发出一条消息,通过消息中间件、事务日志表、重试等机制来保障事务参与方(消息消费者)一定能够接收消息并成功处理事务的分布式事务解决方案,此方案牺牲了事务数据的隔离性,保证了系统的可用性,是一种最终一致性事务解决方案。
3) TCC(Try-Confirm-Cancel)事务模式:
TCC 事务模式在应用层面提供了对两阶段提交协议的支持,将业务操作拆分为 Try(预留资源)-Confirm(确认提交资源)-Cancel(回滚资源)三个方法满足分布式事务的两阶段提交行为,需要一个中心化的事务协调器驱动各个事务参与者提交/回滚,在 TCC 事务模式中,若所有事务参与者 Try 操作均成功,则由事务协调器通知所有事务参与者执行 Confirm 操作,反之,由事务协调器通知所有参与者执行 Cancel 操作,TCC 可以通过 Try 操作实现业务层面的事务数据隔离,是一种最终一致性事务解决方案。
4) Saga 事务模式:
Saga 事务模式是一种基于数据补偿来代替回滚的分布式事务解决方案,要求分布式事务中的所有业务操作都实现一个补偿操作,当某一个事务参与者失败时,由事务协调者通知已执行的事务参与者执行补偿操作,Saga 模式无法保障事务数据的隔离性,是一种最终一致性的柔性事务解决方案。
5) TCC-AT 事务模式:
TCC-AT(Automatic Transactiona)是一种基于“自动回滚”的思想来实现无侵入式分布式事务的分布式事务解决方案,它通过对特定关系型数据库语句进行 SQL 解析,得到事务执行对应的反向回滚 SQL 并记录日志,当事务参与者发生异常时,根据反向 SQL 日志实现业务数据的回滚,此方案存在仅适用于关系型数据库,需适配多种数据库类型的,存在全局锁,无法支持存储过程等无法反向解析的 SQL 语法等问题。
综上,对几种分布式事务方案对比,得出以下结论:
浪潮 inBuilder 低代码平台分布式一致性技术方案
在浪潮 inBuilder 低代码平台的技术选型设计过程中,在参考上述业界分布式事务解决方案基础上,结合企业级复杂应用系统的数据关系复杂性高、业务规则密集、应用规模庞大等实际应用场景需求,基于 TCC 模式提出了一种新的综合技术方案,在满足最终一致性、普适性、性能及事务数据隔离需求的同时,对于简单场景也提供一种基于自动化模式的解决方案,最大程度降低开发成本,提升分布式事务开发效率,做到了鱼与熊掌兼得。其具备以下特性:
1) 良好的普适性
支持 SQL/NoSQL 多种事务资源
支持长/短事务多种场景
同一分布式事务支持自动模式与手工模式混合使用
2) 低开发成本
无侵入式开发
提供自动事务模式
支持自动锁定
与低代码平台内置集成
3) 高可靠性
支持资源预留和锁,实现业务隔离性
支持自动回滚
支持自动防悬挂
支持自动重试机制
兼容空回滚/空提交
支持框架级幂等控制
4) 高性能
支持多隔离级别设置
分布式日志
内存、数据库两阶段增量提交
5) 高效运维
提供事务运维管理工具
提供事务状态监控
提供事务调用链路查看
若想了解更多关于 inBuilder 低代码平台的更多相关内容,可点击下述地址下载安装 inBuilder 低代码平台社区版https://ibc.inspures.com/
评论