Debezium 心跳机制:如何解决低频表数据延迟难题?
一次“订单状态卡住3小时”的深夜救火
去年双11大促刚过,客服电话被打爆:
“用户付款成功了,但订单一直显示‘待支付’!”
“退款申请提交了,状态三天没变!”
我们紧急排查,发现订单状态变更事件在 Kafka 里“消失”了——不是没产生,而是延迟了整整3小时才出现。
更诡异的是,高频下单表(orders)一切正常,唯独低频更新的order_status_log表出了问题。
DBA 拍胸脯:“MySQL binlog 实时写入,绝对没丢!”
Kafka 运维也摇头:“topic 积压为零,消费正常。”
那问题出在哪?
直到我翻到 Debezium 的一行日志:
No change records found, sleeping for 1000ms...
那一刻,我恍然大悟:不是数据丢了,是 Debezium “睡着了”。
今天,我就揭秘这个被无数团队忽视的“低频表陷阱”,以及如何用心跳机制 + WAL 强刷让数据秒级同步。