消息记录的查看
为什么要提供“查询消息记录/异常消息记录”功能
关键原因一：链路可视化与进度追踪
- 一次完整升级要走12跳（横向放大时间维度、到“年”后纵向上卷业务维度），没有可视化列表无法回答“这条链路进行到第几跳、停在哪里、是否到顶”。
- 查询消息记录基于
message_trace_id聚合展示一条链路的所有跳次，直观呈现12跳的“时间线”。
关键原因二：幂等校验与重试影响可见
- 消费端因“至少一次”语义会重试，查询记录能看到
message_consumer_count、是否重复消费、是否已成功，便于识别毒性消息和幂等策略效果。
关键原因三：乱序与错位诊断
- 多分区并发下可能出现“高维先于低维”或“年先于日”的乱序。列表中保留每跳的“业务维度 + 时间维度快照”和时间戳，能快速定位并评估影响。
关键原因四：失败闭环与自动对账的落地入口
- 异常消息列表聚焦“发送成功但未消费成功/对账失败”的跳次，是对账任务的工作面板与人工干预入口，保障最终一致性。
关键原因五：端到端时延与SLA
- 展示
send_time/consumer_time与状态，定位“哪一跳慢、为什么慢”，支撑容量规划与性能优化。
关键原因六：多链路并行可区分
- 同时处理上百条链路时，按
message_trace_id分组的查询结果能清楚地告诉你每条链路的完成度。
关键原因七：数据溯源与审计
- 保留每跳的
message_content（参数快照）与异常，支持从“父级分类+年”反查到“视频+日”的全过程。
关键原因八：运维与业务协同
- 运营/产品可按业务维度与时间粒度检视每跳状态，技术可按异常/重试进行排障，跨角色共享单一事实源（Single Source of Truth）。
查询消息记录示例
查询消息记录执行流程（“消息记录列表”，按链路分组分页）
目标：面向“普通链路巡检与进度总览”，优先按 message_trace_id 聚合，展示每条链路的全量跳次与状态。