Debezium 心跳机制：如何解决低频表数据延迟难题？

Debezium 心跳机制：如何解决低频表数据延迟难题？

一次“订单状态卡住3小时”的深夜救火

去年双11大促刚过，客服电话被打爆：

“用户付款成功了，但订单一直显示‘待支付’！”
“退款申请提交了，状态三天没变！”

我们紧急排查，发现订单状态变更事件在 Kafka 里“消失”了——不是没产生，而是延迟了整整3小时才出现。

更诡异的是，高频下单表（orders）一切正常，唯独低频更新的order_status_log表出了问题。

DBA 拍胸脯：“MySQL binlog 实时写入，绝对没丢！”
Kafka 运维也摇头：“topic 积压为零，消费正常。”

那问题出在哪？

直到我翻到 Debezium 的一行日志：

No change records found, sleeping for 1000ms...

那一刻，我恍然大悟：不是数据丢了，是 Debezium “睡着了”。

今天，我就揭秘这个被无数团队忽视的“低频表陷阱”，以及如何用心跳机制 + WAL 强刷让数据秒级同步。