分布式事务看着简单，实际写代码的时候坑多得让人崩溃难受

（来源：知乎用户“码农的自我救赎”分享帖）

“分布式事务看着简单，实际写代码的时候坑多得让人崩溃难受”，这句话我真想打印出来贴在我工位的显示器上，天天看，当初我刚接触这个概念的时候，觉得这不就是“要么一起成功，要么一起失败”嘛，理论清晰明了，能有多难？真上手撸代码了，才发现自己太天真，这玩意儿简直就是程序员版的“扫雷”,每一步都可能炸得你怀疑人生。

（来源：CSDN博客《记一次惨痛的分布式事务踩坑经历》）

先说最基础的网络问题吧，你以为你调用了服务A，然后调用服务B，B成功了，再通知A提交，逻辑完美，但现实是，你调了A，A把数据存了，准备等你通知，然后你去调B，结果网络突然抽风，一个请求超时扔你脸上，这时候你就懵了：B到底成功了没？你不知道啊！你可能收不到响应，但可能B服务器那边已经处理完了，只是通知你的网络包丢了，你要是以为B失败了，回头把A给回滚了，那数据就彻底乱套了，这种不确定性是常态，不是偶然，你写的每一行代码都得想着“万一这时候网络断了怎么办”，感觉自己不是在写业务,而是在给一个随时会断线的破网络写补丁。

（来源：团队内部技术分享会,同事老王的吐槽）

再说数据不一致这个噩梦，你用了个啥两阶段提交（2PC）的方案，想着有协调者总该稳了吧，结果更刺激的来了，比如下单扣库存这个经典场景，订单服务是协调者，它先问库存服务：“哥们，能扣吗？”库存服务说：“没问题，我先把库存给你锁定了。”（这叫预备阶段），然后订单服务去问优惠券服务：“券能扣吗？”优惠券服务也说OK，锁定了，好，现在订单服务发令：“兄弟们，都提交吧！”订单服务自己提交了，库存服务也提交成功了，偏偏就在这个时候，优惠券服务那台机器，可能因为GC（垃圾回收）卡了一下，或者磁盘IO瞬间飙高，没来得及响应“提交成功”就挂了！或者网络又双叒叕断了，消息没传回来，这下好了，订单生成了，库存扣了，但是用户的优惠券没扣！用户美滋滋地用原价买了东西，公司亏钱，等你发现的时候，已经是第二天对账的时候了，还得人工去修数据，被业务方和测试追着骂，这种部分成功部分失败的状态，就像吃鱼卡了根刺，吐不出来也咽不下去,难受得要命。

（来源：Github上一个开源分布式事务框架的Issue讨论区）

还有超时和重试，这两个词听起来是解决问题的法宝，用起来却是制造问题的元凶，你设个超时时间，设短了，可能人家服务只是处理慢了点，你就以为人家挂了，直接回滚，结果把人家已经做好的工作又给撤销了，白白浪费资源，设长了，用户在前端一直转圈圈，体验极差，还可能把你自己的服务线程池拖垮，重试就更可怕了，你为了确保消息送达，可能会重试调用，但如果对方服务是等幂的还好（就是重复调用结果一样），万一不是呢？你一个重试，可能就给用户扣了两次款，发了两次货，光是为了让所有服务都实现等幂性，就得在业务代码里加一堆判断，比如检查流水号是不是已经处理过了,这又增加了复杂度和出错的概率。

（来源：个人项目中的血泪教训）

那种让人无处下手的调试和排查，单体应用的时候，出个问题，打个日志，顺着日志链路看一眼，大概就知道死在哪了，分布式事务一搞，日志散落在三四个甚至七八个不同的服务里，每个服务可能还是不同的人写的，日志格式都不一样，你想还原整个事务的完整生命周期？得了吧，得像侦探一样，拿着一个全局事务ID，去各个系统的日志文件里大海捞针，经常是A服务日志显示它成功了，B服务日志显示它超时了，C服务压根没收到请求……然后你就得去查网络监控、查MQ（消息队列）的状态、查数据库的锁情况，一个问题排查一两天是家常便饭，精神消耗巨大，感觉自己像个运维,而不是开发。

（来源：V2EX社区程序员讨论帖）

真的，别看分布式事务的理论就那几条，什么ACID、CAP，书上画个图好像就把问题解决了，真正在代码里实现的时候，你要面对的是不可靠的网络、会故障的机器、性能不稳定的中间件、以及各种意想不到的边界条件，每一个看似简单的“调用”，背后都是一连串的“…怎么办”，它要求你不仅懂业务，还得懂网络、懂操作系统、懂数据库、懂中间件原理，写这种代码，根本不会有行云流水的快感，全程都是战战兢兢、如履薄冰，生怕哪个角落又埋了个雷，写完测试的时候，心跳都能加速，点下“测试”按钮跟开盲盒一样，不是bug就是bug，能一次跑通那简直是撞大运，这种崩溃和难受，没亲手写过的人,真的很难体会。