kafka 丢失和重复消费数据

Kafka 作为当下流行的高并发消息中间件，大量用于数据采集，实时处理等场景，我们在享受他的高并发，高可靠时，还是不得不面对可能存在的问题，最常见的就是丢包，重发问题。

1、丢包问题：消息推送服务，每天早上，手机上各终端都会给用户推送消息，这时候流量剧增，可能会出现 kafka 发送数据过快，导致服务器网卡爆满，或者磁盘处于繁忙状态，可能会出现丢包现象。

解决方案：首先对 kafka 进行限速， 其次启用重试机制，重试间隔时间设置长一些，最后 Kafka 设置 acks=all，即需要相应的所有处于 ISR 的分区都确认收到该消息后，才算发送成功。检测方法：使用重放机制，查看问题所在。kafka 配置如下：

props.put(“compression.type”, “gzip”);props.put(“linger.ms”, “50”);props.put(“acks”, “all”);props.put("retries ", 30);props.put("reconnect.backoff.ms ", 20000);props.put(“retry.backoff.ms”, 20000);

2、重发问题：当消费者重新分配 partition 的时候，可能出现从头开始消费的情况，导致重发问题。当消费者消费的速度很慢的时候，可能在一个 session 周期内还未完成，导致心跳机制检测报告出问题。

底层根本原因：已经消费了数据，但是 offset 没提交。配置问题：设置了 offset 自动提交解决办法：至少发一次+去重操作（幂等性）

问题场景：

设置 offset 为自动提交，正在消费数据，kill 消费者线程；设置 offset 为自动提交，关闭 kafka 时，如果在 close 之前，调用 consumer.unsubscribe() 则有可能部分 offset 没提交，下次重启会重复消费；消费 kafka 与业务逻辑在一个线程中处理，可能出现消费程序业务处理逻辑阻塞超时，导致一个周期内，offset 还未提交；继而重复消费，但是业务逻辑可能采用发送 kafka 或者其他无法回滚的方式；重复消费最常见的原因：re-balance 问题,通常会遇到消费的数据，处理很耗时，导致超过了 Kafka 的 session timeout 时间（0.10.x 版本默认是 30 秒），那么就会 re-balance 重平衡，此时有一定几率 offset 没提交，会导致重平衡后重复消费。

3、去重问题：消息可以使用唯一 id 标识保证不丢失消息：生产者（ack=all 代表至少成功发送一次)消费者 （offset 手动提交，业务逻辑成功处理后，提交 offset）保证不重复消费：落表（主键或者唯一索引的方式，避免重复数据）业务逻辑处理（选择唯一主键存储到 Redis 或者 mongdb 中，先查询是否存在，若存在则不处理；若不存在，先插入 Redis 或 Mongdb,再进行业务逻辑处理）。

以上就是大数据中的 kafka 丢失和重复消费数据的详细内容，更多请关注大数据培训课程其它技术内容。