Java猿社区—消费方—手动提交位移
参考：《深入理解Kafka：核心设计与实践原理》
自动提交位移可能带来重复消费和消息丢失问题
在 Kafka 中默认的消费位移的提交方式是自动提交，这个由消费者客户端参数enable.auto.commit 配置，默认值为 true。当然这个默认的自动提交不是每消费一条消息
就提交一次，而是定期提交，这个定期的周期时间由客户端参数 auto.commit.interval.ms配置，默认值为 5 秒，此参数生效的前提是 enable.auto.commit 参数为 true。
在默认的方式下，消费者每隔 5 秒会将拉取到的每个分区中最大的消息位移进行提交 。 自动位移提交的动作是在 poll（）方法的逻辑里完成的，在每次真正向服务端发起拉取请求之前会检
查是否可以进行位移提交，如果可以，那么就会提交上一次轮询的位移。
自动提交带来重复消费和消息丢失的问题：
重复消费： 假设刚刚提交完一次消费位移，然后拉取一批消息进行消费，在下一次自动提交消费位移之前，消费者崩溃了，那么又得从上一次位移提交的地方重新开始消费，这样便发生了重复消费的现
象（对于再均衡的情况同样适用）。我们可以通过减小位移提交的时间间隔来减小重复消息的窗口大小，但这样并不能避免重复消费的发送，而且也会使位移提交更加频繁。
消息丢失： 消费方拉取的消息在逻辑处理线程还未处理结束，此时到达了自动提交窗口期，自动提交线程将拉取到的每个分区的最大消息位移进行提交，如果此时消费服务挂掉，消息并未处理结束，就会发生消息丢失。
改自动提交为手动提交位移
公司在线客服的消息服务之前采用的自动提交方式提交位移，现改为手动提交位移，主要是为了防止出现消息丢失现象。
重复消费消息：比如如果出现网络抖动，位移提交失败，或出现服务挂掉，位移还未来得及提交，待服务恢复，会将此前已部分消费过的消息重复处理一遍，不过此时需要在业务上需要做到幂等。
在线客服消息落库幂等：在线客服消息服务主要是消息落库逻辑，根据生成的唯一分布式消息id（给消息id建立唯一索引），通过insert ignore在新增数据时做到幂等（分库分表，通过shardingsphere按照群组id和发送日期进行路由库和表，在一定的时间窗口内，可以保障路由到同一库同一张表中，此时mysql可以保障local唯一索引的效果）。