打通策划与建站资源的分布式事务快车道

文章配图，仅供参考

　　我原以为这事得靠Saga补偿链兜底，结果上线前夜发现根本不用。因为策划资源池和建站资源池那两个DB，居然共享同一个分库分表中间件的物理实例。不是逻辑同库，是物理上——同一块SSD，同一组IO队列，连磁盘灯闪烁节奏都一样。这个我敢打包票，那天凌晨两点我亲手拔了根SAS线验证过：一拔，两边的事务都卡在prepare阶段，红灯齐亮。

　　优胜劣汰？对。不是淘汰人，是淘汰伪共识。策划提的“首页加弹窗”需求，在建站系统里自动被拆成三个子事务：资源预占、样式校验、CDN回源刷新。其中第二个子事务失败概率最高——上周五下午三点十七分，王工手抖把一个字体权重设成900而不是800，建站侧直接拒绝commit，整个事务就卡在那儿不动了。但没人去修，也没人打告警电话。第二天早上九点，那个弹窗需求消失了，被另一个叫“首屏视频自动播放”的新需求覆盖了。不是人工下线，是调度器根据失败频次自动降权了。

　　桌上的黄焖鸡米饭凉透了，塑料盖子结了层水汽。我拿筷子戳了戳，米粒粘在一起拉丝，像分布式锁没释放干净的样子。陈总监这时候推门进来，头发湿着，边走边解西装扣子，手机贴着耳朵，讲的是“下周团建选爬山还是漂流”，完全没看我这边一眼。我本来想问他要不要看下TCC的timeout参数调太激进了，但看他袖口蹭着点泥，就没开口。

　　所以这快车道压根不是为跑得更快修的，是为让跑错方向的车自己熄火修的。建站侧现在敢拒接策划需求，不是靠审批流，是靠事务隔离级别设成了READ_UNCOMMITTED——不是误配，是故意的。因为策划写的SQL连explain都懒得跑，一查就查全表，建站系统直接判为“无效提案”，丢进discard_queue。上周四那个做A/B测试的PRD文档，被丢进去之后再没捞出来过。

　　机房空调坏了三天，风扇声音从嗡变成嘶哑的刮擦声。我们没人修，因为所有监控埋点都指向“非关键路径”。确实不是关键——关键路径是那些没被写进任何流程图的临时脚本，比如小李写的那个每天四点自动扫一遍策划Jira状态的Python脚本，发现“已验收”但建站还没部署，就往企业微信发条@全体消息：“谁家娃还在产科门口排队？”。发完他就关电脑走了，留着脚本在容器里飘着。这个我说不准是不是合法事务参与者，但它的成功率比我们的Seata集群高得多。

　　我见过最惨的是一次跨中心事务。策划在北京改了个文案字段长度，建站在深圳同步数据时遇到主键冲突，本地回滚后还顺手把策划那边的ES索引给删了——不是代码写的，是DBA半夜手动执行的shell脚本里有个$变量没引号。事情过去两周后我才听说，因为在钉钉群文件里翻到一张截图：一个叫“zhangsan-20230317-rollback.sql”的txt文件，创建时间是3月17号凌晨4:23，里面最后一行写着“-- 老张说删完别重启es”。老张后来没来上班，听说是去考教师资格证了。

　　冷眼？算不上。是看多了之后，对“一致性”这三个字产生了条件反射式的肌肉抽搐。就像现在我盯着这条log：“tx_id: 0x8a3f… timeout=18s —— commit ignored”。忽略？不，它只是没等到建站那边的ACK，但策划侧UI上那个“已提交”绿标已经亮了十八秒。你要是这时候刷新页面，会发现它又变灰了。这个过程重复了七次，第七次的时候，弹窗文案自动替换成运营塞进缓存里的备选版本，连灰标都没闪一下。

　　昨天中午食堂阿姨多给我舀了一勺土豆，她说：“看你天天啃冷饭，怕胃坏。”我点头，没说其实胃早坏了，坏在三年前一次XA分支事务里，本地日志写了，远程没收到，又没重试，只留个error码藏在WARN级别里。这事我不打算再查了。但建站侧上个月开始用RabbitMQ的死信队列收编失败事务，每天上午十点自动导出成Excel邮件发所有人，标题写着：“今日待淘汰需求（非人工筛选）”。附件里第17行，是我去年提的“支持富文本导入”的需求，状态栏标着“超限失败＞3次”，旁边备注一栏是空的。空的好。比写“业务方放弃”或“技术不可行”都干净。

　　下周我准备把事务追踪日志里的trace_id长度从32位砍到24位。不是为省存储，是发现运维说新采购的Kafka集群磁盘IOPS撑不住那么多hex字符。这事得跟小李商量下，他写的那个清理脚本可能要动。不过他最近在学Go，上周交的PR里有三处defer没配对，我光看没提——反正等它panic一次，自动进discard_queue，比我说一百遍都有力。

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!