跳到主要内容

消息记录能解决哪些疑难杂症

先来介绍下当引入了”消息记录“功能后，能解决哪些问题？

有了"消息记录"，具体能解决什么问题

解决问题1：用 messageTraceId 把12跳串成完整链路​

机制​

  • 第①跳开始时生成一个唯一的 messageTraceId（比如 10001）。
  • 后续的②③④⑤⑥⑦⑧⑨⑩⑪⑫跳的所有发送记录与消费记录，都携带相同的 messageTraceId = 10001。
  • 数据库中按 messageTraceId 查询，可以一次性拿到这12跳的全部记录。

效果​

  • 宕机重启后，查询 messageTraceId = 10001 的记录，立即知道"已完成到第⑥跳，第⑦跳的消息已发送但未消费成功"，可以精准恢复或补发。
  • 运维可以按链路查看进度："视频A的升级进行到第8跳，视频B还在第3跳"。

实例​

messageTraceId: 10001
  ① 视频+日    [发送成功] [消费成功]
  ② 视频+周    [发送成功] [消费成功]
  ...
  ⑥ 视频分类+周 [发送成功] [消费成功]
  ⑦ 视频分类+月 [发送成功] [消费失败] ← 断点在这里！

解决问题2：用 messageId 实现幂等，避免重复计算​

机制​

  • 第③跳"视频+月"的消息发送前，先生成唯一的 messageId（比如 20003），并写入 MessageProducerRecord。
  • 消费端收到后，先查询 messageId = 20003 的 MessageConsumerRecord：
    • 若记录存在且状态为"消费成功"，直接 ack 跳过，不执行聚合逻辑。
    • 若不存在或状态为"失败"，才执行聚合并更新为"成功"。

效果​

  • Kafka 重复投递第③跳的消息时，消费端识别出"已处理"，不会重复累加播放量。
  • 实现效果上的 exactly-once，保障数据准确性。

实例​

第一次消费：
  messageId: 20003 → 插入消费记录，状态"成功" → 执行聚合
第二次投递（重复）：
  messageId: 20003 → 查到已成功 → 直接 ack，跳过聚合

解决问题3：用业务维度快照识别乱序与错位​

👉 点击解锁全部付费内容