分布式事务常用解决方案

Posted 途牛技术中心

tags:

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



背景介绍

早期途牛系统大都运行在一个应用上,随着业务量的不断增长,虽然有集群,但已逐渐满足不了系统对性能方面的需求。因此系统的重构被提上日程,单体应用被拆分成多个相对独立的系统,途牛的分布式系统应运而生。

在拆分系统初期,系统间的交互我们遵循了restful规范,而由于各种原因,比如网络不稳定,特殊场景下的系统bug,随着系统的不断拆分,系统间的接口API成指数级的上升,接口的管理维护让研发人员头疼等等

总结一下主要有以下几方面:

1、系统拆分后,系统间的通讯和故障处理变的更加复杂

2、拆分后系统数量众多,测试、部署、监控、运维等都变得更加困难

3、一个对外开放的API接口,其内部可能需要调用多个应用、操作多个数据库,由于各种不可预知的原因,其中部分调用会出现异常,导致系统间数据不一致,也就是分布式事务的问题


01

针对第1个问题,途牛自研发了TSP和Pebble服务治理平台来解决,业界也有开源的组件如spring cloud、dubbo等

02

针对第2个问题,途牛也自研发了tardis平台来管理docker容器,自动化运维工具的推出,此问题也逐步得到改善

03

而对于第3个问题,目前还没有很好的通用解决方案,因此我们来聊聊分布式架构下,分布式事务的各种解决方案

两阶段事务提交

XA是一个分布式事务协议,由Tuxedo提出。

XA中大致分为两部分:事务管理器和本地资源管理器。其中本地资源管理器往往由数据库实现,比如Oracle、DB2这些商业数据库都实现了XA接口,而事务管理器作为全局的调度者,负责各个本地资源的提交和回滚。

XA实现分布式事务的原理如下:

分布式事务常用解决方案

总的来说,XA协议比较简单,而且一旦商业数据库实现了XA协议,使用分布式事务的成本也比较低。

但是,XA也有致命的缺点,那就是性能不理想,最终时间依赖系统最慢的功能,锁定资源时间比较长,拖慢系统整体性能。


TCC

TCC 将事务提交分为 Try - Confirm - Cancel 3个操作

  • Try:预留业务资源/数据效验

  • Confirm:确认执行业务操作

  • Cancel:取消执行业务操作

TCC事务处理流程和 2PC 二阶段提交类似,不过 2PC通常都是在跨库的DB层面,而TCC本质就是一个应用层面的2PC

分布式事务常用解决方案

TCC优点:

让应用自己定义数据库操作的粒度,使得降低锁冲突、提高吞吐量成为可能。


TCC不足之处:

  • 对应用的侵入性强。业务逻辑的每个分支都需要实现try、confirm、cancel三个操作,应用侵入性较强,改造成本高。

  • 实现难度较大。需要按照网络状态、系统故障等不同的失败原因实现不同的回滚策略。为了满足一致性的要求,confirm和cancel接口必须实现幂等。


消息事务+最终一致性

所谓的消息事务就是基于消息中间件的两阶段提交,本质上是对消息中间件的一种特殊利用,它是将本地事务和发消息放在了一个事务里,保证要么两者都成功,要么两者都失败。

基于消息中间件的两阶段提交往往用在高并发场景下,将一个分布式事务拆成一个消息事务(A系统的本地操作+发消息)+B系统的本地操作,只要消息事务成功,那么A操作一定成功,消息也一定发出来了。

而对于B系统的操作,则依赖B系统的重试机制。

虽然上面的方案能够完成A和B的操作,但是A和B并不是严格一致的,而是最终一致的,我们在这里牺牲了一致性,换来了性能的大幅度提升。当然,这种做法也是有风险的,如果B一直执行不成功,那么一致性会被破坏。


途牛实践

针对我们旅游行业,由于预订到最终出游时间跨度长的特点,供应商对客人下单的信息实时性要求并不是很高。因此我们的设计方案中,供应商查询客人下单信息(询位单、占位单、确认单等)采用的是“消息事务+最终一致性”这种方案。

消息体内只记录了单据id等重要信息,下游系统通过单据id,采用定时任务的方式将其它详情信息异步方式同步过来后呈现给了供应商,异步方式会记录每条消息处理结果,如果失败会进行重试,若重试N次后仍然不成功,我们会人工介入查明失败原因并解决,后期针对此消息还可再重试处理,保证数据的最终一致性。

分布式事务常用解决方案
分布式事务常用解决方案

总结:

分布式事务,本质上是对多个数据库的事务进行统一管理,按照控制粒度不同可以分为:不控制、部分控制和完全控制。

不控制就是不引入分布式事务;部分控制就是各种变种的两阶段提交,包括上面提到的消息事务+最终一致性、TCC;完全控制就是完全实现两阶段提交。

部分控制的好处是并发量和性能很好,缺点是数据一致性减弱了,完全控制则是牺牲了性能,保障了一致性,具体用哪种方式,最终还是取决于业务场景,不同场景根据各自特点具体分析评估。

作为技术人员,不能忘了技术是为业务服务的,不要为了技术而技术,而针对不同业务进行技术选型是作为研发一种很重要的能力!

分布式事务常用解决方案

扫二维码,加入途牛技术粉丝微信群

敲门砖:“途牛技术”

牛牛等着你哦~

以上是关于分布式事务常用解决方案的主要内容,如果未能解决你的问题,请参考以下文章

常用分布式事务解决方案

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

基于数据库的事务消息解决分布式事务方案

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

分布式事务常用解决方案

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