Kafka 为什么会丢消息？（案例）

引入 MQ 消息中间件最直接的目的：系统解耦以及流量控制（削峰填谷）

• 系统解耦： 上下游系统之间的通信相互依赖，利用 MQ 消息队列可以隔离上下游环境变化带来的不稳定因素。
• 流量控制： 超高并发场景中，引入 MQ 可以实现流量 “削峰填谷” 的作用以及服务异步处理，不至于打崩服务。

引入 MQ 同样带来其他问题：数据一致性。

在分布式系统中，如果两个节点之间存在数据同步，就会带来数据一致性的问题。 消息生产端发送消息到 MQ 再到消息消费端需要保证消息不丢失。

所以在使用 MQ 消息队列时，需要考虑这 3 个问题：

• 如何知道有消息丢失？
• 哪些环节可能丢消息？
• 如何确保消息不丢失？

（1）如何知道有消息丢失？

如何感知消息是否丢失了？可总结如下：

1. 他人反馈： 运营、PM 反馈消息丢失。
2. 监控报警： 监控指定指标，即时报警人工调整。Kafka 集群异常、Broker 宕机、Broker 磁盘挂载问题、消费者异常导致消息积压等都会给用户直接感觉是消息丢失了。

案例：舆情分析中数据采集同步

• PM 可自己下发采集调度指令，去采集特定数据。
• PM 可通过 ES 近实时查询对应数据，若没相应数据可再次下发指令。

当感知消息丢失了，那就需要一种机制来检查消息是否丢失。

检索消息

运维工具有：

1. 查看 Kafka 消费位置：

# 查看某个topic的message数量
$ ./kafka-run-class.sh kafka.tools.GetOffsetShell --broker-list localhost:9092 --topic test_topic

# 查看consumer Group列表
$ ./kafka-consumer-groups.sh  --list  --bootstrap-server 192.168.88.108:9092

# 查看 offset 消费情况
$ ./kafka-consumer-groups.sh --bootstrap-server localhost:9092 --group console-consumer-1152 --describe
GROUP                 TOPIC           PARTITION  CURRENT-OFFSET  LOG-END-OFFSET  LAG             CONSUMER-ID                                                           HOST            CLIENT-ID
console-consumer-1152 test_topic      0          -               4               -               consumer-console-consumer-1152-1-2703ea2b-b62d-4cfd-8950-34e8c321b942 /127.0.0.1      consumer-console-consumer-11