微交互：数据库管理员眼中的网站新范式

　　去年一月份，我们给客户新上线的电商后台加了个“库存实时同步微交互”——就那个用户点一下“刷新库存”，页面右上角小图标转三圈，数字蹦一下。我配的数据库触发器，连着 Redis 缓存层和 MySQL 主从，逻辑干净得很，第八次压测都过。

文章配图，仅供参考

　　运维小王蹲在我工位边啃包子，油渍蹭到键盘缝隙里，他指着我屏幕上刚抓的 WireShark 包说：“哥，你瞅这 TCP 窗口大小，咋比上次团建吃的烤串还窄？”我没理他。我盯的是数据库那一端：主库 update 成功，binlog 里 timestamp 是对的，但从库 IO 线程状态是 “Waiting for master to send event”，而 SQL 线程停在“init”，不是“executing”，也不是“reading event”，就是卡在 init——像人站在电梯门口，门开着，脚不抬。

　　我查了从库 relay-log，缺了三段，第十六段结尾是“INSERT INTO inventory_log…”，后半截没了。重放前一段？不行，position 对不上。跳过？主从 GTID 已经错开两个位点。这时候运营部李姐过来问：“那个小圆圈转完能响个音效不？”她手机壳是樱花粉的，指甲盖上还沾着一点奶茶杯上的奶盖残渣。

　　我重启了从库 SQL 线程，它吭哧两秒，吐出一句 ERROR 1594 (HY000): Relay log read failure: Could not parse relay log event entry，然后又挂回 init。我改用 SET GLOBAL sql_slave_skip_counter=1；它跑过两行，第三行卡死，第四行……没第四行，直接断开。后来发现，问题根本不在 binlog 解析，而在主库的 semi-sync 插件——配置里超时设的是 1 秒，可那天机房电力波动，主库写入 binlog 到通知备库确认的间隙，有三次超了 1012 毫秒。插件没报错，但 quietly 转成了异步模式，且未记录日志。MySQL 官方文档里写了这事儿可能发生，括号里还补了一句“（通常不影响业务）”。

　　我盯着那句“通常不影响业务”，心里咯噔一下。什么叫通常？是七百二十一次没问题，第八次就让你在生产环境里找三个钟头，直到发现 redis 缓存键名里多了一个空格字符，而这个空格是前端用 template literal 拼接时，换行符被 trim 掉后留下的鬼影子——它让所有 key 都生成失败，导致每次读都 fallback 到从库快照。可从库数据本身已经断更了啊。我也不知道那个空格到底是前端写的、还是 webpack 插件加的、还是我同事上周改 eslint 规则时手抖多按了个 tab。

　　反正最后把半同步关了，主从强制重置，缓存键名格式校验加进 CI，凌晨四点十一分，那个小圆圈终于转完会蹦数字了。李姐发来一张截图，说“音效暂时不加了”。小王的包子渣还在 Esc 键旁边，风干成灰白色一小粒。

　　我原以为微交互只是前端的事儿，结果发现它是一根线，拽着 UI、CDN、HTTP/2 帧、Redis pipeline、MySQL binlog format、电源稳定性、甚至程序员喝咖啡的时间点——谁松了一扣，整个链子就颤。优胜劣汰？对。活下来的不是最漂亮的交互，而是那个在第八次刷新时，还能让主从 GTID 对得上、让 cache key 不带幽灵空格、让 SQL 线程不卡在 init 的系统。它不炫，但扛得住电涌、睡得着凌晨、不指望人半夜爬起来人工干预。

　　有谁碰到过 GTID 复制卡在 init 状态却查不到 relay-log 截断位置的吗？

（编辑：航空爱好网）

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