【Kafka】消息的顺序性、可靠性、幂等性

消息顺序性

消息追加到partition尾部，单个partition是有序的，但多个partition如何进行有序的获取一些消息？

解决方案

• 一个topic只设置一个partition（违背设计原则）
• 发送消息时，指定topic、partition、key，保证消息只发送到一个partition

消息可靠性

生产者丢失消息

原因：发送消息默认发送成功

解决方案

• 使用get获取发送消息的结果，缺点是变成了同步操作
• 添加回调函数，如果发送失败，查看原因后重试

Kafka默认进行10次重发操作，间隔时间为0

消费者丢失消息

问题：提交offset和消费消息没有原子性

解决方案

• 拉取到消息后，自动提交offset，如果消费者挂掉，那么就会少消费（消息并没有被消费，但offset提交了）
• 选择手动提交offset，但会出现消费完后，提交offset前，消费者挂掉，会出现重复消费(消息已经被消费，但offset没有提交)

Kafka丢失消息

问题：Kafka的leader挂了，但follower没有完全同步leader的消息（生产者发送了消息，但丢失了）

解决方案

• acks = all 所有副本接收到消息后，才代表生产者发送消息成功（是最安全的，但延迟高）
• min.insync.replicas > 1，至少两个副本要接收到（默认为1，生产环境中要避免默认1）
• replication.factor >= 3 副本数，注意replication.factor应该 大于min.insync.replicas，避免副本一旦出现挂掉，整个分区都无法工作的情况
  • 一般推荐设置成 replication.factor = min.insync.replicas + 1
• 配置：和leader同步程度达不到要求的副本 不能被选举，降低了消息丢失的可能性。

unclean.leader.election.enable = false

消息幂等性

问题：

1. 消费了，但没成功提交offset（根本原因）
2. 消费者处理业务时间长或网络问题，Kafka认为服务假死，触发分区rebalance

解决方案

• 消费服务方做幂等性校验，比如redis的set操作，mysql的主键天然幂等性

• enable.auto.commit = false 关闭自动提交offset，改为手动，

  • 消费后提交，但可能重复消费

  • 接收到消息后提交，但可能消息丢失，此时可以通过定时任务在业务不繁忙时做数据兜底。