实时看板 1.2 万 离线报表 9800 同一时段差 2200

大促当晚实时看板显示 12,040 单，次日离线报表 9,832 单，差 2,208，运营拿着两个数开会。日志里能对上时间点，这种反而好排。

实时链路按事件到达计数，离线按订单表去重，重复上报和测试单在实时侧没过滤。离线任务还排除了风控拦截单，实时没有。两条链路的过滤条件不是一套。这一点先确认清楚，后面就不用反复试。

SELECT COUNT(DISTINCT order_no) FROM ods_order WHERE dt='2026-03-01';
redis-cli PFCOUNT realtime:order:20260301

「实时离线口径」排查到最后往往是很小的一处差异，前面那些复杂猜测可以先放一放。线上出问题先对时间点，跟发布、备份、任务执行的时刻排一排，能省掉一半功夫。

日志级别临时调高可以，记得改回去，长期开着既占磁盘又掩盖真问题。

处理上按这个顺序：把过滤条件抽成同一份配置 两条链路共用；实时侧按订单号去重 窗口设 10 分钟；离线结果产出后回刷实时看板的 T+1 口径；拿当晚订单号分别跑两条链路 对比差集。

结果对不对很好判断，实时和离线都显示 9,832 单，差集里只剩风控拦截的 8 单。