消息队列-消息队列保证消息可靠性的一些建议

如何检测到消息丢失？

美团消息队列文章中提到了对消息队列的监控手段，我理解消息丢失，根据不同节点来查看监控：

• 生产者生产丢失：监控中生产者生产量异常
• 消费者消费丢失：查看消费者消息延迟监控、消费者 offset 偏移

消息队列高手课中提到的检测方法是：消息队列中的有序性。具体来说，生产消息时附带一个递增 id，消费方消费时检查这个 id。这个方法的困难还是很多的，日常工作中感觉不太可用

• 需要保证消息在 topic 中严格有序（kafka 只能保证在 分区 是有序的）
• 多个不同的 producer 也需要保证消息的有序性
• consumer 检测消息的有序性（consumer 和分区一一对应可能相对方便）

kafka 如何保证「消息可靠」

什么是 kafka 认为的「消息可靠」？

kafka 保证对「已提交」的消息进行有限度的可靠性。

• 已提交：消息已经在 1-n 个 broker 上写到 日志 中
• 有限度：n 个 broker 不能同时全部挂掉，不然神仙难救。

防止消息丢失的方法

1. 生产者消息丢失
   1. 场景
      1. kafka 中提供的 api send 方法是异步发送，此时 send 给你的返回值并不代表 mq 真正成功发送。上述的场景，严格来说并不是 kafka 要提供的消息可靠范围内
      2. producer 设置的 acks 数量过少，且 broker 发生异常导致消息消失，这个对应的就是 kafka 消息可靠的有限性。
   2. 使用建议
      1. 使用 send 方法时已经要使用带有回调参数的 producer.send(msg, callback)
      2. 参数
      1. acks = all : 代表当「所有 broker 」接收到消息后，才会给 producer 发送确认
      2. retries 设置较大：代表 producer 的自动重试次数
2. 存储可靠
   1. 配置多个 broker，减少 broker 异常导致消息丢失的可能性
   2. 具体参数
      1. unclean.leader.election.enable = false 不允许消息不全的 broker 副本竞选 leader
      2. replication.factor >= 3：消息的副本数量
      3. min.insync.replicas > 1：消息至少写入多少副本后才算「已提交」
      4. replication.factor > min.insync.replicas： 如果相等，一个副本挂机，这个分区无法工作，生产者的生产永远不可以成功
3. 消费者消息丢失
   1. 场景
      1. 消息消费之前进行了确认，这种严格来说也不属于消息可靠的范围
      2. 这种场景的另一种极端，消费者使用多线程进行消息消费，有一个线程失败，这个消息消费就失败了
   2. 使用建议
      1. 消息消费之后再进行 mq 确认 && 程序确认
      2. enalbe.auto.commit = false：不要自动确认，防止「单 concumer 多线程场景下消息消费失败」造成的消息丢失

如何保证消息可靠传输？

总结一下，消息传输中简单说有三个阶段：生产阶段、存储阶段、消费阶段。

生产阶段保证可靠传输

• 代码中确保可靠传输的方式
  • 使用 mq api 时，注意对响应进行处理（同步发送直接检查响应值，异步使用回调方法）
• 配置
  • kafka 中对 prodecer ack 数量的配置 && 重试次数等

存储阶段可靠传输，mq 提供的手段是对消息进行持久化

• 响应配置
  • 副本数量配置
  • 不允许日志不全的落后 broker 竞争 leader

消费阶段和生产阶段相同，需要注意的地方就是确认机制

• 配置中关闭 自动确认
• 程序中，代码完成消费逻辑后，发送确认

参考文章

1. 美团消息队列
2. kafka 核心技术与实践（极客时间）