消息队列Kafka——常见问题总结

一、消息队列优缺点：

优点：解耦、异步、削峰

缺点：

1. 系统可用性降低
2. 系统复杂性提高
3. 一致性问题

二、常见问题：

1、消息重复问题

消息端重复发送情况：

生产者（消息发送端）发送消息成功进入消息中间件，由于各种原因发送端没有收到消息中间件返回的“成功”结果，而且发送端还存在重试机制；

消息中间件重复：

消息被消费端成功消费后，消息中间件没有收到消息的处理结果；

重复消费解决方式

• MVCC：多版本并发控制，乐观锁的一种实现；生产者发送消息进行数据更新时带上数据的版本号，消费端去验证数据的版本号，版本号不一致则操作无法成功；
• 去重表：数据库表上创建唯一索引；
• 消费端保证操作的幂等性

2、消息的可靠性问题

消费端丢失数据：

消费端消费到消息，然后消费端自动向Kafka提交了Offset,但还没来及处理，消费端由于各种原因出错了；

关闭Kafka自动提交Offset,处理完消息之后，手动提交Offset，可保证数据不会丢失，但此方法会存在重复消费问题，比如刚处理完消息还没来得及提交Offset，消费者挂了；

Kafka丢失数据：

 Follower 还没有来得及同步数据，Leader 挂了，然后选举某个 Follower 成 Leader 之后，这就会丢了一些数据。

解决方法：

• 给 Topic 设置 replication.factor 参数：这个值必须大于 1，要求每个 Partition 必须有至少 2 个副本。

• 在 Kafka 服务端设置 min.insync.replicas 参数：这个值必须大于 1，这个是要求一个 Leader 至少感知到有至少一个 Follower 还跟自己保持联系，没掉队，这样才能确保 Leader 挂了还有一个 Follower 吧。

• 在 Producer 端设置 acks=all：要求每条数据，必须是写入所有 Replica 之后，才能认为是写成功了

• 在 Producer 端设置 retries=MAX：一旦写入失败，就无限重试。

生产者丢失数据：

设置 acks=all，基本就不会丢失数据

3、消息持续积压问题

• 修复 Consumer 的问题，确保其恢复消费速度，然后将现有 Consumer 都停掉。

• 新建一个 Topic，Partition 是原来的 10 倍，临时建立好原先 10 倍或者 20 倍的 queue 数量。

  然后写一个临时的分发数据的 Consumer 程序，这个程序部署上去消费积压的数据，消费之后不做耗时的处理，直接均匀轮询写入临时建立好的 10 倍数量的 queue。

• 接着临时征用 10 倍的机器来部署 Consumer，每一批 Consume