一、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成为master的replica。
如replica不能保证和master如完全一致,要实现带容错性的分布式事务,一致性算法如选举(要实现全序广播算法如用paxos,zab 和raft),实现状态复制机。leader挂重选,自动恢复系统 。避免2PC难以恢复,人工介入问题。
但正确实现一个具有分布式一致性且Fault Tolerant的系统实在是太过于困难,中小公司一般也只能凑合。考虑到技术储备和资源怎么没法”放心“,但现实需求怼Fault Tolerant和Performance又是必须的。于是一般的做法就是凑合实现一个的分布式事务,再配合”人工对账“的形式来彻底封死错误。即使是有像TiDB这样的已经实现了分布式事务的数据库引入,谁又能担保100%不出问题呢?终归是double check下才能放心。换一个角度,如果凑合实现的分布式事务不那么靠谱,但成本极低。对账如果发现问题,就赔款。赔的钱远小过实现完备分布式一致性的成本,从业务角度也是蛮划算的(但要测算一下大概会赔多少,再做决策)。
如果是跨公司(如一个电商公司和一个支付渠道公司)的协作,技术对接都很困难,对账这种看起来有点糙但管用的办法就更加必不可少了。
链接:https://www.zhihu.com/question/363054486/answer/951634231
网友评论