Kafka无消息丢失
Kafka的消息丢失有几种情况
- 生产者程序丢失消息
- 消费者程序丢失消息
- Kafka本省弄丢了消息
我们一一来说：
生产者程序丢失了消息
场景是你的Producer向Kafka发消息，但是发现Kafka没有保存
解决方案：
一定要使用producer.send(msg,callback)，带回调通知的发送API
在有错误的情况下，要根据情况做处理
消费者程序丢失消息
Kafka本身平时消费的时候都是默认提交offset的
所以有可能存在我们消费的时候有问题，但是又默认提交了，导致消息丢失的情况
所以我们要先消费，再提交。
当然这也会带来另外一个问题，就是可能出现重复消费，譬如先消费了，然后这个程序宕机了，虽然已经消费了，但是却没有提交。
Kafka弄丢了消息
我们知道 Kafka 为分区（Partition）引?了多副本（Replica）机制。分区（Partition）中的多个
副本之间会有?个叫做 leader的家伙，其他副本称为follower。我们发送的消息会被发送到
leader 副本，然后 follower 副本才能从 leader 副本中拉取消息进?同步。?产者和消费者只与
leader 副本交互。你可以理解为其他副本只是 leader 副本的拷?，它们的存在只是为了保证消息
存储的安全性。
试想?种情况：假如 leader 副本所在的 broker 突然挂掉，那么就要从 follower 副本重新选出
?个 leader ，但是 leader 的数据还有?些没有被 follower 副本的同步的话，就会造成消息丢失。
设置acks=all
解决办法就是我们设置 acks = all。acks 是 Kafka ?产者(Producer) 很重要的?个参数。
acks 的默认值即为1，代表我们的消息被leader副本接收之后就算被成功发送。当我们配置 acks
= all 代表则所有副本都要接收到该消息之后该消息才算真正成功被发送。
设置 replication.factor >= 3
为了保证 leader 副本能有 follower 副本能同步消息，我们?般会为 topic 设置 replication.factor
>= 3。这样就可以保证每个 分区(partition) ?少有 3 个副本。虽然造成了数据冗余，但是带来了
数据的安全性。
设置 min.insync.replicas > 1
?般情况下我们还需要设置 min.insync.replicas> 1 ，这样配置代表消息?少要被写?到 2 个副
本才算是被成功发送。min.insync.replicas 的默认值为 1 ，在实际?产中应尽量避免默认值
1。
但是，为了保证整个 Kafka 服务的?可?性，你需要确保 replication.factor >
min.insync.replicas 。为什么呢？设想?下加?两者相等的话，只要是有?个副本挂掉，整个
分区就?法正常?作了。这明显违反?可?性！?般推荐设置成 replication.factor =
min.insync.replicas + 1。
设置 unclean.leader.election.enable = false
Kafka防止消息重复消费
对于不需要幂等性的消息，这个就无所谓了，但是如果是需要幂等性的，那么就需要防止消息重复消费了。
我们假设一个场景，如果Kafka是用于解耦的，比如发邮件啥的。
那就无所谓了，就算多发一个邮件也没啥对吧，而且也一般会做验证，看redis里是否有验证码什么的，消息也一般不会发过去两次。就算发过去了，检查一下Redis有没有验证码也都可以解决。
但是如果是电商，加积分这种情况，就必须引入数据库或者其他中间件了，譬如你去给数据库做一个唯一约束，然后订单号固定的情况下，你是没办法给流水表插两条的，这样就会失败，自然没法加两次了。
另外一种是参考乐观锁的机制，譬如你发消息时账户里有50积分，然后要加五十积分，你传过去的消息如果为在有50积分的情况下加五十积分，那肯定就不会重复消费了
那么我们能解决的方法主要就是三种
- 用Redis存key，每次消费的时候看key是否消费过
- 用MySQL的唯一约束，让第二次消费的记录插入无效
- 设置前置条件，只有满足前置条件，才消费（这个还是有问题）
|