被裁后接外包，我在老城区阳台写代码：聊聊分布式事务那些坑

大家好，我是阿强，一个土生土长的广州人，住在荔湾老城区一栋90年代的楼梯房里，月租3500。去年十月，我被一家中型互联网公司“优化”了——说白了就是裁员。那天HR找我谈话，语气很温柔：“阿强，公司战略调整，你懂的……N+1，下个月不用来了。”我点点头，心里却像被塞进了一块冰：房贷、老婆的产检、还没出生的娃，怎么办？

在家躺了两周，焦虑到半夜三点还在刷BOSS直聘。最后咬咬牙，注册了几个自由职业平台，开始接外包。没想到，第一个单子就撞上了“分布式事务”这个大坑。

---

一、客户的需求：简单？不，是地狱模式

上周五晚上九点，我正蹲在阳台啃肠粉（对，老广加班也得吃口热的），手机突然弹出一条消息：“急！有个支付系统要改，涉及订单、库存、积分三个服务，必须保证数据一致，明天能看吗？”

我差点把肠粉掉地上。这不就是经典的分布式事务场景吗？订单创建成功，库存扣减失败，积分没加——用户付了钱，东西没收到，客服电话被打爆。这种事，我在前公司面试时被问过八百遍，但真刀真枪干，还是头一回。

客户是个做社区团购的小老板，语气很急：“我们之前用本地事务，现在拆成微服务，天天对账对到崩溃。你要是能搞定，这个月尾款直接打你账户，8000块。”

8000块！够我交两个月房租了。我深吸一口气：“行，我试试。”

---

二、面试题变现实题：从理论到落地的鸿沟

说实话，分布式事务这玩意儿，我在面试时背得滚瓜烂熟：2PC、3PC、TCC、Saga、本地消息表、Seata、RocketMQ事务消息……但真上手，才发现面试题和现实差了十万八千里。

比如，客户系统用的是 Java + Spring Boot，数据库是MySQL，消息队列是RabbitMQ——没有RocketMQ，也没有Seata现成的集成。我翻了翻GitHub，发现有个叫 Bolt.new 的开源框架最近挺火，号称“轻量级分布式事务解决方案”，支持TCC和Saga模式，还兼容Spring Cloud。

我心想：行，就它了。结果一跑Demo，报错：“Connection timeout”。查了三天，才发现是Bolt.new默认用ZooKeeper做协调，而客户服务器根本没开外网访问。那一刻，我真想把键盘扔进珠江。

---

三、我的“土法炼钢”：结合现实的最佳实践

折腾一周后，我放弃了“高大上”的方案，回归本质。总结下来，分布式事务的核心不是技术多牛，而是业务容忍度和补偿机制。以下是我踩坑后整理的“老广式”最佳实践：

1. 优先考虑业务解耦，别硬上事务

很多场景其实不需要强一致性。比如积分，完全可以异步补发。我跟客户说：“用户下单成功，库存扣了，积分延迟5分钟到账，能接受吗？”他想了想：“只要别丢就行，行！”于是，我用 本地消息表 + 定时补偿 搞定：

• 订单服务写入订单，同时往message_outbox表插一条“发送积分”消息
• 后台定时任务扫描这张表，调用积分服务
• 成功就标记已发送，失败就重试

简单、可靠、不依赖外部中间件。代码不到200行，跑了一个月零故障。

2. TCC不是万能药，慎用！

我试过用Bolt.new实现TCC（Try-Confirm-Cancel），但发现：

• Try阶段要预留资源，但库存系统不支持“预占”
• Cancel逻辑复杂，万一Cancel也失败，雪球越滚越大

最后只在一个关键场景用了TCC：支付回调。Try阶段冻结金额，Confirm真正扣款，Cancel解冻。其他地方，能不用就不用。

3. 日志！监控！告警！三位一体

外包最怕半夜被call。我给每个服务加了详细日志，关键步骤打上traceId，用ELK聚合。再配上企业微信机器人，一旦补偿失败超过3次，自动@我。虽然睡得少，但至少心里有底。

4. 别信AI生成的代码，尤其是DeepSeek

有天深夜，我实在搞不定幂等性问题，打开 DeepSeek，输入：“Java 分布式事务 幂等实现”。它唰唰给我生成一段用Redis加锁的代码，看起来很专业。我复制粘贴，上线，第二天客户打电话：“用户重复扣款了！”

一查，DeepSeek生成的代码没处理Redis锁超时和续期，高并发下锁失效，导致重复执行。我默默删了那段代码，自己手写了个基于数据库唯一索引的幂等方案。从此记住：AI可以启发思路，但不能替代思考。

---

四、从焦虑到平静：外包教会我的事

写这篇文章时，已经是凌晨一点。窗外是恩宁路的老骑楼，安静得只剩空调外机的嗡嗡声。回想被裁那会儿，我天天刷面经，背“分布式事务的几种方案”，以为背熟了就能找到好工作。现在才明白，真实世界的系统，从来不是非黑即白的选择题，而是灰色地带的权衡艺术。

那个8000块的单子做完后，客户又介绍了两个朋友。现在我每月稳定收入15k左右，比之前上班少，但自由。老婆说：“你最近气色好了。”我笑笑，没告诉她上周为了调一个死锁，熬到凌晨四点。

---

五、给同行的建议：别怕“土”，实用才是王道

如果你也在搞分布式事务，别被各种新框架吓到。我的建议很“老广”：

• 先问业务能不能接受最终一致，别一上来就追求强一致
• 能用本地事务+消息表解决的，别碰2PC，那玩意儿运维成本高到哭
• 补偿机制比事务协议更重要，设计好“怎么回滚”比“怎么提交”更关键
• 日志和监控是你的第二生命，别等出事才后悔

技术没有银弹，只有适合。就像我们老广煲汤，药材不在名贵，而在对症。

---

结语：在不确定的时代，做确定的事

被裁后，我一度觉得人生崩了。但现在回头看，反而感谢那次“优化”。它逼我走出舒适区，从背面试题的程序员，变成能解决真实问题的开发者。

分布式事务如此，人生亦如此。我们无法控制所有变量（比如公司会不会裁员），但可以设计好自己的“补偿机制”——多学一门技术，多存一点钱，多交几个靠谱的客户。

下个月，我打算用赚到的钱，给阳台装个遮雨棚。这样下雨天也能安心写代码了。毕竟，在这个充满不确定性的世界里，能掌控的，也许就只有这一方小小的代码天地。

—— 阿强，于广州荔湾，2024年6月