第一晚，周衡让同步任务完整跑了三轮，一行代码也没动。
汇邻的系统每三十秒查询一次全部门店、全部商品，再把数据库结果和仓库库存逐条比对。为了防止两次同步互相覆盖，开发者在任务最外层加了一把锁。从读取、比较、写回到调用仓配接口，整段流程都被锁住。
八家门店的时候，一轮不到二十秒。现在门店变成三十二家，商品数翻了三倍，正常一轮已经要七八分钟。只要仓配接口偶尔超时，重试也会占着锁，后面的任务便一层层堵在门外。
第二晚，周衡把一份脱敏数据扩到高峰规模，在测试环境复现问题。
任务队列从零涨到二十用了十一分钟，又过了十六分钟，等待任务逼近五十。看板本身并不慢，它只是一直在读没来得及更新的数据。
第三晚，他故意让仓配接口延迟五秒。同步任务连续重试三次，持锁时间立刻超过半小时。
小孙在视频另一头看着监控曲线，半天没说话。
“以前也有人看过，”他说，“都说数据库要分库，服务器要扩容。”
“那些以后可能需要，但不是现在最先要做的。”周衡把三组对照数据发过去，“先把每次搬整座仓库，改成只搬刚变化的箱子。再把必须按顺序做的事和可以排队做的事分开。”
“把锁删了？”
“直接删会出现两个人同时改一份库存。页面是快了，账会乱。”
周衡没有给汇邻另造一套庞大的中间平台。他们只有一个兼职维护系统的小孙，再先进的架构，没人维护也只是新的风险。
现有数据库本来就记录了库存变更时间和操作流水，只是同步程序从来没用过。周衡决定在原系统上做三处修改。
每轮只同步变化过的库存，失败的任务单独排队重试，同一笔变化只生效一次。方案图只有几个框，小孙在旁边补上了自己负责的配置位置。
蒋明川第一次听完时有些失望：“我还以为要上什么消息中间件。别的公司给我讲方案，图里画了十几个框。”
“十几个框也要有人管。”周衡说，“你们现在要的是三十二家店能稳定跑，不是拿架构图融资。等单量再涨一个数量级，再评估要不要换专业队列。”
蒋明川看向小孙。
小孙点头：“至少我看得懂，也接得住。”
第一个周末，周衡完成增量同步和任务拆分。小孙负责整理测试用例，两个人从周六早上九点一直测到晚上十点。
最初的结果很好。十万条库存数据中，真正变化的只有两千多条，一轮同步从七分半降到十几秒。
可第二轮压力测试一开，库存数字出现了三次回跳。
小孙盯着页面，脸色发白：“是不是增量方案不行？”
“先别下结论。”
周衡调出三条回跳记录。它们来自同一家门店，同一件商品在一分钟内发生了收货、取消和人工修正。三个任务虽然都进入了队列，却由不同线程完成，较早发生的那条最后才写入，覆盖了新数据。
锁不能从大门上拆掉以后就彻底不要，而是应该放到真正冲突的那一小格上。
周衡把并发粒度收紧到“门店加商品”，同一项库存按业务序号写入，旧序号不能覆盖新序号。其他门店、其他商品照常并行，不需要一起等待。
再测一轮，回跳消失。
周日，两家门店先行试跑。旧记录里有一批没有标准更新时间，周衡补了一次基线校准，验证完才让小孙继续。
他白天照常在海拓工作，晚上回来处理汇邻项目。耳机一戴，合租房的吵闹声便远了些。新电脑的购物页一直留在浏览器最后一个标签，他写累了就点过去看两眼。
每改好一个问题，那台电脑就离他近一点。
第二天，两家店正式切换。
随后是八家、十六家、三十二家。
门店增加时，蒋明川几乎每隔一小时就问一次数据。周衡把实时结果发过去，对方后来干脆让店长自己看新货入库，电话渐渐少了。上线第三天下午，仓配接口连续抖动十二分钟，失败补偿表里积了三百多条记录。队列没有把请求一起砸过去，而是按节奏重新发送。接口恢复后，积压在六分钟内清空，没有一条库存变化丢失。
这一次，蒋明川没再打电话催。