Ruby工程师亲授：策划与建站资源双向秒同步

　　接口超时告警那一刻，我正蹲在茶水间扒拉最后一块冷掉的青团——去年五一期间的事儿，就那个青团馅儿还发硬，咬一口嘎吱响。监控大盘上那条绿色的线一直在抖，不是跳，是抖，像手抖着点鼠标左键那种抖。老张冲进来甩了句“缓存全崩了”，转身又撞开运维那扇门，鞋带松着，一路没系。

文章配图，仅供参考

　　我原以为是Redis挂了，切进去看日志，刷得太快看不清，就见满屏红字里夹着一行“cache miss > 92%”，底下立刻被新日志盖掉。再切数据库慢查询，第一条就是`SELECT FROM resources WHERE status IN (...) AND updated_at > ?`——这个`IN`里塞了四百多个ID，查的是策划资源表，字段还是`resource_type`和`publish_status`两个联合索引，可去年加过一次`is_deleted`字段，索引没重建，但没人记得这茬。我盯着那条SQL看了三秒，突然想起来，小王上个月提PR说要改这个条件，结果被产品拦住了：“等建站那边对齐”，对齐完就没下文了。他工位隔断上贴的便签卷了边，写了“待同步字段清单”，字迹都洇开了。

　　Ruby工程师亲授：策划与建站资源双向秒同步——这名字是产品写的，印在周会PPT第一页，字体贼大。我真没笑出声，但我端起咖啡杯那一下，杯子底磕在杯托上，当啷一声。谁在工位上打电话谈房租，声音忽大忽小：“押一付三…你真搬？那我找人看房…”电话声、机箱嗡嗡响、还有楼下快递车倒车提示音混在一起。其实根本不用“秒同步”，只要别卡住发布流程就行。可一旦策划把资源设成“上线中”，建站系统必须立刻看到；反过来建站删了个banner图，策划后台得同步把关联资源状态标灰——不是靠定时任务，不是靠MQ重试，是靠一个`after_commit`回调里调的HTTP请求。对，裸调HTTP，连重试逻辑都是后来加的注释：“先跑通再说”。

　　优胜劣汰站得住的地方，不是技术多优雅，是你敢不敢让两个系统互相咬住对方的脖子。上次那个雪崩，就是建站发版后删了`resource_url`字段，没通知策划侧，策划还往里写空字符串；然后策划批量更新状态，触发一堆`save!`，每存一条都去校验那个已经不存在的字段，爆`NoMethodError`；异常吞了，日志只打一句“资源同步失败”，堆栈缩在第三行，前面两行是Nginx转发耗时。我们盯了一下午，最后发现是祖传代码里有个`rescue StandardError`，兜得太宽。李姐当场删了那三行，回滚前还补了条日志：“此处不救，请炸。”

　　咖啡机坏了三天，一直出温水，今天终于修好，第一杯烫得我缩手。其实去年五一那会儿，最致命的不是接口超时，是`/api/v1/resources/sync`这个接口的幂等键写错了——用了`created_at`+`user_id`，可两个策划同事同一秒点了发布，生成的键撞了，结果同一个资源同步了两次，建站收到重复指令，直接把Banner图轮播顺序搞反了。这事没人报bug，因为前端自己写了个本地diff来遮掩。我说怎么用户反馈“刚改完马上又变回去”，翻了三天日志才捞到那两条时间戳只差8ms的请求。而我现在，连那个幂等键现在有没有修都不确定——上个月灰度发版的时候，好像有人说要动，又说“等下个迭代”。

　　外卖筷子掉在地上，我弯腰捡，听见隔壁组说“K8s滚动升级失败”，没人抬头。我自己不敢动的那块，是`ResourceSyncJob`类里那段用`sleep(0.5)`控制重试间隔的代码。删？怕它疯转压垮DB；不删？每次凌晨三点告警，都从这段睡出来的。上周我还给它裹了层`RedisLock`，结果锁key写成常量，整个集群抢一个锁，比原来还卡。我试过换`while true do`加`break unless need_retry?`，但`need_retry?`方法调了三次外部API，超时配置是2s，它永远不break。所以现在……算了，先让它睡着吧。

　　所以说到底，“双向秒同步”这事儿，根本不是靠技术实现的，是靠谁在关键时候敢删那一行`rescue`、谁愿意在青团还没咽下去就去盯日志、谁在告警响起时先把咖啡杯放下。优胜劣汰？淘汰的不是技术，是那些等“完全对齐”才动手的人。小王昨天问我：“同步字段要不要加校验？”我没答。你知道吗，他工位那张便签，我路过时看见又被他拿红笔划掉了三条——不是删了，是改成手写小字：“等策划确认”，“等建站排期”，“问PM下周能推吗”。我端起那杯终于够烫的咖啡，吹了两下，还是太烫，先放着。

（编辑：站长网）

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