文档章节

分布式服务的事务如何处理

rock912
 rock912
发布于 2016/07/14 15:52
字数 1757
阅读 103
收藏 14

首先是不建议采用XA两阶段提交方式去处理分布式事务,要知道要能够支持XA分布式事务,必须是要实现XA规范才可以,而Service本身是无状态的,如果这样去做了等于是把Service内部的东西暴露了出去。对于分布式事务最好的方式还是事务补偿或者BASE基于消息的最终一致性。

可以设想一个最简单的分布式事务场景,对于跨银行的转账操作,该操作涉及到调用两个异地的Service服务,一个是本地提供的取款服务,一个是目标银行提供的存款服务,该两个服务本身无状态且独立,构成一个完整的事务。对于事务的处理初步分析:

事务补偿机制

事务补偿即在事务链中的任何一个正向事务操作,都必须存在一个完全符合回滚规则的可逆事务。如果是一个完整的事务链,则必须事务链中的每一个业务服务或操作都有对应的可逆服务。对于Service服务本身无状态,也不容易实现前面讨论过的通过DTC或XA机制实现的跨应用和资源的事务管理,建立跨资源的事务上下文。因此也较难以实现真正的预提交和正式提交的分离。

在这种情况下以上面例子来说,首先调用取款服务,完全调用成功并返回,数据已经持久化。然后调用异地的存款服务,如果也调用成功,则本身无任何问题。如果调用失败,则需要调用本地注册的逆向服务(本地存款服务),如果本地存款服务调用失败,则必须考虑重试,如果约定重试次数仍然不成功,则必须log到完整的不一致信息。也可以是将本地存款服务作为消息发送到消息中间件,由消息中间件接管后续操作。

在上面方式中可以看到需要手工编写大量的代码来处理以保证事务的完整性,我们可以考虑实现一个通用的事务管理器,实现事务链和事务上下文的管理。对于事务链上的任何一个服务正向和逆向操作均在事务管理和协同器上注册,由事务管理器接管所有的事务补偿和回滚操作。

基于消息的最终一致性

在这里首先要回答的是我们需要时实时一致性还是最终一致性的问题,如果需要的是最终一致性,那么BASE策略中的基于消息的最终一致性是比较好的解决方案。这种方案真正实现了两个服务的真正解耦,解耦的关键就是异步消息和消息持久化机制。

还是以上面的例子来看。对于转账操作,原有的两个服务调用变化为第一步调用本地的取款服务,第二步发送异地取款的异步消息到消息中间件。如果第二步在本地,则保证事务的完整性基本无任何问题,即本身就是本地事务的管理机制。只要两个操作都成功即可以返回客户成功。

由于解耦,我们看到客户得到成功返回的时候,如果是上面一种情况则异地卡马上就能查询账户存款增加。而第二种情况则不一定,因为本身是一种异步处理机制。消息中间件得到消息后会去对消息解析,然后调用异地银行提供的存款服务进行存款,如果服务调用失败则进行重试。

异地银行存款操作不应该长久地出现异常而无法使用,因此一旦发现异常我们可以迅速的解决,消息中间件中异常服务自然会进行重试以保证事务的最终一致性。这种方式假设问题一定可以解决,在不到万不得已的情况下本地的取款服务一般不进行可逆操作。

在本地取款到异地存款两个服务调用之间,会存在一个真空期,这段时间相关现金不在任何一个账户,而只是在一个事务的中间状态,但是客户并不关心这个,只要在约定的时间保证事务最终的一致性即可。

关于等幂操作的问题

重复调用多次产生的业务结果与调用一次产生的业务结果相同,简单点讲所有提供的业务服务,不管是正向还是逆向的业务服务,都必须要支持重试。因为服务调用失败这种异常必须考虑到,不能因为服务的多次调用而导致业务数据的累计增加或减少。

关于是否可以补偿的问题

在这里我们谈的是多个跨系统的业务服务组合成一个分布式事务,因此在对事务进行补偿的时候必须要考虑客户需要的是否一定是最终一致性。客户对中间阶段出现的不一致的承受度是如何的。

在上面的例子来看,如果采用事务补偿机制,基本可以是做到准实时的补偿,不会有太大的影响。而如果采用基于消息的最终一致性方式,则可能整个周期比较长,需要较长的时间才能给得到最终的一致性。比如周六转款,客户可能下周一才得到通知转账不成功而进行了回退,那么就必须要考虑客户是否能给忍受。

其次对于前面讨论,如果真正需要的是实时的一致性,那么即使采用事务补偿机制,也无法达到实时的一致性。即很可能在两个业务服务调用中间,客户前台业务操作对持久化的数据进行了其它额外的操作。在这种模式下,我们不得不考虑需要在数据库表增加业务状态锁的问题,即整个事务没有完整提交并成功前,第一个业务服务调用虽然持久化在数据库,但是仍然是一个中间状态,需要通过业务锁来标记,控制相关的业务操作和行为。但是在这种模式下无疑增加了整个分布式业务系统的复杂度。

本文转载自:http://www.zhihu.com/question/29483490

共有 人打赏支持
rock912
粉丝 30
博文 79
码字总数 23641
作品 0
宁波
程序员
私信 提问
保证分布式系统数据一致性的6种方案

问题的起源 在电商等业务中,系统一般由多个独立的服务组成,如何解决分布式调用时候数据的一致性? 具体业务场景如下,比如一个业务操作,如果同时调用服务 A、B、C,需要满足要么同时成功;...

huojiao2006
2017/03/06
0
0
分布式之《保证分布式系统数据一致性的6种解决方案》

原文:http://weibo.com/ttarticle/p/show?id=2309403965965003062676 编者按:本文由「高可用架构后花园」群讨论整理而成。 有人的地方,就有江湖 有江湖的地方,就有纷争 问题的起源 在电商...

无信不立
2016/04/20
0
0
保证分布式系统数据一致性的6种方案

保证分布式系统数据一致性的6种方案问题的起源 在电商等业务中,系统一般由多个独立的服务组成,如何解决分布式调用时候数据的一致性? 具体业务场景如下,比如一个业务操作,如果同时调用服...

秋风醉了
2016/05/12
656
0
保证分布式系统数据一致性的6种方案(转载)

保证分布式系统数据一致性的6种方案(转载) 问题的起源 在电商等业务中,系统一般由多个独立的服务组成,如何解决分布式调用时候数据的一致性? 具体业务场景如下,比如一个业务操作,如果同时...

tantexian
2016/06/19
359
0
REST微服务的分布式事务实现-分布式系统、事务以及JTA介绍

事务,是操作数据库中的数据的逻辑单元。在处理一个业务过程中,事务保证多个数据修改的操作,要么都修改成功,要么都失败。同时,几个事务之间又相互独立,不会相互影响。 在这篇文章中,我...

tyou
2017/11/07
0
0

没有更多内容

加载失败,请刷新页面

加载更多

OSChina 周二乱弹 —— 请上车吧

Osc乱弹歌单(2018)请戳(这里) 【今日歌曲】 @2amor :分享王菲的单曲《闷》 《闷》- 王菲 手机党少年们想听歌,请使劲儿戳(这里) @開源中國周杰倫 :昨天睡觉肚子疼,妈蛋,半夜爬起来...

小小编辑
28分钟前
123
6
工作中如何做好技术积累

参考:https://tech.meituan.com/study_vs_work.html 看了这篇文章,觉得总结得非常好,因此摘抄了一些关键点,以便自己经常翻阅。 引言 在繁忙的工作中做好技术积累,构建个人核心竞争力. 在...

grace_233
38分钟前
6
0
day146-2018-11-13-英语流利阅读-待学习

5 岁“牛娃”简历给 985 精英一个暴击 Lala 2018-11-13 1.今日导读 “不要让孩子输在起跑线上”,似乎已成为了当下最流行的名句,每个身为家长或还未成为家长的人都不得不思考这句话的分量。...

飞鱼说编程
51分钟前
4
0
Mariadb二进制包安装,Apache安装

安装mariadb 下载二进制包并解压 [root@test-a src]# wget https://downloads.mariadb.com/MariaDB/mariadb-10.2.6/bintar-linux-glibc_214-x86_64/mariadb-10.2.6-linux-glibc_214-x86_64.t......

野雪球
今天
4
0
ConcurrentHashMap 高并发性的实现机制

ConcurrentHashMap 的结构分析 为了更好的理解 ConcurrentHashMap 高并发的具体实现,让我们先探索它的结构模型。 ConcurrentHashMap 类中包含两个静态内部类 HashEntry 和 Segment。HashEnt...

TonyStarkSir
今天
5
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部