kafka重复消费问题

一、kafka自带的消费机制

　　kafka有个offset的概念，当每个消息被写进去后，都有一个offset，代表他的序号，然后consumer消费该数据之后，隔一段时间，会把自己消费过的消息的offset提交一下，代表我已经消费过了。下次我要是重启，就会继续从上次消费到的offset来继续消费。

　　但是当我们直接kill进程了，再重启。这会导致consumer有些消息处理了，但是没来得及提交offset。等重启之后，少数消息就会再次消费一次。

　　其他MQ也会有这种重复消费的问题，那么针对这种问题，我们需要从业务角度，考虑它的幂等性。

kafka重复消费的根本原因就是“数据消费了，但是offset没更新”！而我们要探究一般什么情况下会导致offset没更新？

max.poll.interval.ms

两次poll操作允许的最大时间间隔。单位毫秒。默认值300000（5分钟）。

两次poll超过此时间间隔，Kafka服务端会进行rebalance操作，导致客户端连接失效，无法提交offset信息，从而引发重复消费。

拿到消息就提交offset

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

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

检测方法：使用重放机制，查看问题所在。

2.重复消费最常见的原因：re-balance问题,通常会遇到消费的数据，处理很耗时，导致超过了Kafka的session timeout时间（0.10.x版本默认是30秒），那么就会re-balance重平衡，此时有一定几率offset没提交，会导致重平衡后重复消费。 

消息重复消费和消息丢包的解决方法

保证不丢失消息：生产者（ack=all 代表至少成功发送一次)     重试机制

消费者 （offset手动提交，业务逻辑成功处理后，提交offset） 

保证不重复消费：落表（主键或者唯一索引的方式，避免重复数据） 

业务逻辑处理（选择唯一主键存储到Redis或者mongdb中，先查询是否存在，若存在则不处理；若不存在，先插入Redis或Mongdb,再进行业务逻辑处理）

二、通过保证消息队列消费的幂等性来保证

　　举个例子，当消费一条消息时就往数据库插入一条数据。如何保证重复消费也插入一条数据呢？

　　那么我们就需要从幂等性角度考虑了。幂等性，我通俗点说，就一个数据，或者一个请求，无论来多次，对应的数据都不会改变的，不能出错。

怎么保证消息队列消费的幂等性？

我们需要结合业务来思考，比如下面的例子：

　　1.比如某个数据要写库，你先根据主键查一下，如果数据有了，就别插入了，update一下好吧

　　2.比如你是写redis，那没问题了，反正每次都是set，天然幂等性

　　3.对于消息，我们可以建个表（专门存储消息消费记录）

　　　　生产者，发送消息前判断库中是否有记录（有记录说明已发送），没有记录，先入库，状态为待消费，然后发送消息并把主键id带上。

　　　　消费者，接收消息，通过主键ID查询记录表，判断消息状态是否已消费。若没消费过，则处理消息，处理完后，更新消息记录的状态为已消费。