分布式事务解决方案：最佳实践 —— 一个老广奶爸的深夜踩坑实录
大家好，我是阿强，坐标广州荔湾老城区，白天写代码，晚上哄娃睡觉的老广程序员。家里两个崽，大的三岁半，小的一岁八个月，老婆在越秀做会计。我们租的房子月租3500，是那种老西关骑楼改造的单间，厨房小得只能侧身过，但胜在楼下有肠粉店和糖水铺，生活气息浓。
今天这篇文章，不是什么高屋建瓴的架构师指南，而是我在深夜11点哄完两个娃、泡了杯速溶咖啡后，一边刷LeetCode一边回想去年十月那段“分布式事务”踩坑经历的真实记录。如果你也在一线城中村租房、被KPI追着跑、还要兼顾家庭，或许能从我的故事里找到一点共鸣。
一、事情起因：一个“简单”的爬虫需求
时间回到2023年10月12日，那天周五，我刚开完周会，老板把我叫到茶水间（其实就是公司角落放了个饮水机的地方），递给我一杯瑞幸：“阿强，有个新项目，要做个数据聚合平台，抓取全网电商价格，然后比价、存库、发告警。你来牵头。”
听起来不难？错。
问题出在：我们要用Python写爬虫集群，每天抓百万级商品数据，每条记录要同时写入MySQL主库（用于前端展示）和MongoDB（用于分析），还要触发一个Kafka消息通知风控系统。三个操作必须“要么全成功，要么全失败”——这不就是典型的分布式事务场景吗？
我当时心里咯噔一下。因为我知道，本地事务（比如MySQL的InnoDB）根本搞不定跨数据库的操作。更别提Kafka还不是数据库。
回家路上，我一边挤地铁一边刷知乎，看到一堆“Seata”、“TCC”、“Saga”、“MQ事务消息”的术语，头都大了。到家已经8点半，老婆抱着小的在喂饭，大的在地板上打滚喊“爸爸陪我搭乐高”。我苦笑：哪有时间研究这些？
二、第一次尝试：天真地用“try-except”硬扛
第一版方案，我用了最朴素的想法：
try:
mysql_conn.execute("INSERT INTO products ...")
mongo_db.products.insert_one({...})
kafka_producer.send("price_alert", ...)
except Exception as e:
# 回滚？
pass
结果呢？上线第三天就炸了。
那天凌晨2点，运维打电话：“阿强，MongoDB写满了，但MySQL里没数据！用户投诉说价格没更新！”
我冲到电脑前一看：原来爬虫某个商品ID重复了，MongoDB插入报了DuplicateKeyError，但MySQL那条已经commit了！数据不一致，而且没法自动恢复。
老婆被我吵醒，迷迷糊糊问：“又加班？”
我说：“不是加班，是救火。”
她叹口气：“你这个月第几次了？上次说好陪孩子去动物园……”
我心里一阵愧疚。技术债，最终都是用家庭时间来还的。
三、面试题里的“正确答案”，现实里全是坑
后来我开始认真研究分布式事务。翻遍了GitHub、掘金、甚至B站视频。发现很多文章讲得头头是道，但一落地就翻车。
比如“两阶段提交（2PC）”——理论上完美，但实际用起来，性能差到离谱。我们试过用Atomikos + XA协议，TPS直接从300掉到30。老板问我：“为啥爬虫变乌龟了？” 我只能苦笑：“我们在保证数据一致性，老板。” 他回：“用户不在乎你一致不一致，他们只在乎页面能不能刷出来。”
再比如“TCC（Try-Confirm-Cancel）”——听起来很优雅，但开发成本爆炸。每个业务都要写三套逻辑。我们团队就4个人，俩还在搞前端兼容IE11（别问，问就是甲方要求）。哪有精力搞这个？
最讽刺的是，这些内容恰恰是面试高频题。上周我去面一家跨境电商，HR直接问：“你们项目怎么处理分布式事务的？”
我说：“我们用最终一致性+补偿机制。”
他皱眉：“不用Seata吗？现在大厂都用Seata啊。”
我心想：Seata要改数据源、加注解、配注册中心，我们连Docker都没全上，哪敢动生产环境？
面试题和现实，隔着一条珠江的距离。
四、转机：从“完美主义”到“够用就好”
转折点发生在一个雨夜。那天我又熬到11点，老婆突然端了碗姜撞奶进来（老广的治愈神器），说：“你最近黑眼圈重得像熊猫，别把自己逼太紧。数据错一点，天塌不下来。”
这句话点醒了我。
我开始思考：我们的核心诉求到底是什么？
- 用户需要实时价格？其实延迟5分钟也能接受。
- 数据绝对一致？其实只要最终一致就行。
- 100%可靠？其实99.9%就够了，剩下的靠人工补录。
于是，我们转向了基于消息队列的最终一致性方案，具体做法：
- 爬虫只负责把原始数据发到Kafka一个topic（比如
raw_price_data） - 下游三个消费者分别处理：
- MySQL写入服务
- MongoDB写入服务
- 风控通知服务
- 每个服务自己保证幂等性（比如用商品ID+时间戳做唯一键）
- 加一个对账任务，每天凌晨跑一遍，发现不一致就告警+自动修复
代码变得超级简单：
# 爬虫端
kafka_producer.send("raw_price_data", json.dumps(item))
# MySQL消费者
def consume():
for msg in kafka_consumer:
try:
insert_into_mysql(msg) # 内部用ON DUPLICATE KEY UPDATE
except:
log_error_and_retry(msg)
没有Seata，没有TCC，没有复杂的协调器。性能回来了，bug少了，运维也松了口气。
最关键的是——我不用再半夜被电话叫醒。
五、资源有限时，务实才是王道
回头想想，为什么一开始会走弯路？
因为我们被“技术正确”绑架了。总觉得不用最新框架、不按教科书来，就是不专业。但现实是：我们不是阿里腾讯，我们没有无限资源。
- 我们团队小（4人）
- 服务器预算紧（老板说“能省则省”）
- 业务容忍一定延迟（用户不是高频交易者）
在这种情况下，轻量、可维护、易理解的方案，远比“理论上最优”重要。
顺便说一句，这套方案后来成了我跳槽的谈资。上个月拿到一个offer，月薪从15k涨到22k。HR问我：“你最大的优势是什么？”
我说：“能在资源有限的情况下，用最简单的技术解决复杂问题。”
他笑了：“这比背八股文强多了。”
六、给同行的建议：别被“最佳实践”PUA
写到这里，咖啡凉了，窗外下起了广州常见的夜雨。两个娃睡得正香，老婆在隔壁刷抖音。我突然觉得，技术这条路，其实和带娃一样——没有标准答案，只有不断试错和调整。
所以，如果你也在为分布式事务头疼，我的建议是：
- 先问业务容忍度：真的需要强一致吗？还是最终一致就行？
- 优先考虑幂等+重试+对账：这三板斧能解决80%的问题。
- 慎用重型框架：Seata很好，但你的团队能驾驭吗？运维能跟上吗？
- 把监控和告警做好：比任何“完美方案”都重要。
- 留点时间给家人：技术可以重来，孩子的成长只有一次。
结语：在代码与尿布之间，寻找平衡
分布式事务的本质，不是技术问题，而是权衡的艺术。就像我在老城区35平的出租屋里，既要给孩子腾出玩耍空间，又要给自己留个写代码的角落——妥协不是失败，而是成年人的智慧。
下次当你在深夜debug时，不妨想想：这个方案，真的值得我错过孩子的睡前故事吗？
如果是，那就继续干；如果不是，也许该换个思路了。
共勉。
—— 阿强，于广州荔湾，2024年6月的一个雨夜
评论 0