(13)分布式协议对比

一、2PC(XA),3PC是一路

因为实现“Atomic Commit”。生产中2PC(XA)有个严重问题,1)事务管理器或实际执行者任何一方不工作,整体不工作。2)要XA协议支持,不是所有资源都支持XA。一些数据库和队列支持XA。自己编写服务接口没法用XA。3)2PC实现性能很差。

另外就是用TCC或者SAGA。都不满足“Atomic Commit”。从db角度来看,是多事务,不是整体。期间用户可能会有感觉。对于TCC,用户会有很短时间发现自己数据被冻住

二、TCC:

2次操作:冻结 + 提交/取消;手动写回滚和提交。如果有人修改了逻辑,还有可能导致bug的出现

每个存储服务都暴露三个接口Try、Commit、Cancel,Try冻钱,不真扣款,Commit时才真扣,Cancel被调用或者Commit超时,冻款解封。Transaction Manager是大Boss,协调各个实现TCC

1、中途问题:正常顺序:Try A、Try B   Commit A、Commit B

中途时Commit B失败,调Cancel A,Try A取消掉。如有可靠的Event Bus的话,几个存储间处理顺序不重要,就更简单

2、Coordinator:挂掉整个系统不能工作,因此 1)多节点;2)节点间数据严格一致。用Paxos和Raft等(ms~s内自动恢复,好过没法自动恢复的XA)

3、kafka做Cooridinator(少用,任何一方都可是协调者):改ABC,Kafka写入“做XXX业务“的记录,作为Coordinator。其他的Consumer根据event各自修改ABC。吞吐高,因为队列写入吞吐比修改数据高但同时,引入两个问题:

    1)修改异步,等待所有完成(异步改同步);先扣库存,但是“支付中”。

    2)难回滚。kafka中记录不会自己回滚。必须有代码盯着ABC一个失败,撤销整个

4、自动补偿:1)如何判定数据不一致。如通过跑批对账支付下单金额对不上就有问题。如监控一致没完全commit的多处修改。如超时触发补偿2)如何补偿:写补偿反逻辑。TCC代表。产品配合减轻用户体验。做“正在支付1000元“的提示。

三、SAGA

执行 + 可能回滚。用户先发现被执行了,随后回滚(如订单先下,又自己撤销)。需产品设计配合,让这事情显得不扎眼,常规说“最终一致”。

1、2、3、4是Do,1’、2‘、3’、4‘是Undo,蓝色箭头顺利,1、2、3、4做完,但1完时,4还没做,如1扣款,4加积分,有一段时间钱扣了,积分没加,最终积分会到账,就是『最终一致性』。如果中间一个步骤失败了,如4失败,走下面那一行,因已做1、2、3,先做3’,把3消掉,再做2‘、1’补偿掉,扣钱补回(如undo失败就retry)

先下单,成功则支付;失败,再回滚下单撤销。一小段时间用户会看到下单成功。其他读取交易记录ETL等也会看到这条数据,并开始统计,就很麻烦。避免用额外标记来表明这个数据“基本上成功,但还没最终成功”。

TCC叫做“冻结”,在“prepare commit”。

本质就是2PC,没像XA锁数据,在业务层面2PC。分布式一致性如果希望数据正确性得到保障,总是能绕到2PC。

总结

无论2PC,TCC,SAGA,如事务执行期间节点恢复就成问题。2PC尤其严重。引入多backup解决。如服务本身有状态就很麻烦。要保证所有backup状态必须精确的和原来的服务一摸一样,就得让backup成为masterreplica

如replica不能保证和master如完全一致,要实现带容错性的分布式事务,一致性算法如选举(要实现全序广播算法如用paxos,zab 和raft),实现状态复制机。leader挂重选,自动恢复系统 。避免2PC难以恢复,人工介入问题。

但正确实现一个具有分布式一致性且Fault Tolerant的系统实在是太过于困难,中小公司一般也只能凑合。考虑到技术储备和资源怎么没法”放心“,但现实需求怼Fault Tolerant和Performance又是必须的。于是一般的做法就是凑合实现一个的分布式事务,再配合”人工对账“的形式来彻底封死错误。即使是有像TiDB这样的已经实现了分布式事务的数据库引入,谁又能担保100%不出问题呢?终归是double check下才能放心。换一个角度,如果凑合实现的分布式事务不那么靠谱,但成本极低。对账如果发现问题,就赔款。赔的钱远小过实现完备分布式一致性的成本,从业务角度也是蛮划算的(但要测算一下大概会赔多少,再做决策)。

如果是跨公司(如一个电商公司和一个支付渠道公司)的协作,技术对接都很困难,对账这种看起来有点糙但管用的办法就更加必不可少了。

链接:https://www.zhihu.com/question/363054486/answer/951634231

https://www.zhihu.com/question/403855775

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 218,036评论 6 506
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 93,046评论 3 395
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 164,411评论 0 354
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 58,622评论 1 293
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 67,661评论 6 392
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 51,521评论 1 304
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 40,288评论 3 418
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 39,200评论 0 276
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 45,644评论 1 314
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,837评论 3 336
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,953评论 1 348
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 35,673评论 5 346
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 41,281评论 3 329
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,889评论 0 22
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 33,011评论 1 269
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 48,119评论 3 370
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,901评论 2 355