Kafka丢数据、重复消费、顺序消费的问题

面试官：今天我想问下࿰c;你觉得Kafka会丢数据吗？

候选者：嗯࿰c;使用Kafka时࿰c;有可能会有以下场景会丢消息

候选者：比如说࿰c;我们用Producer发消息至Broker的时候࿰c;就有可能会丢消息

候选者：如果你不想丢消息࿰c;那在发送消息的时候࿰c;需要选择带有 callBACk的api进行发送

候选者：其实就意味着࿰c;如果你发送成功了࿰c;会回调告诉你已经发送成功了。如果失败了࿰c;那收到回调之后自己在业务上做重试就好了。

候选者：等到把消息发送到Broker以后࿰c;也有可能丢消息

候选者：一般我们的线上环境都是集群环境下嘛࿰c;但可能你发送的消息后broker就挂了࿰c;这时挂掉的broker还没来得及把数据同步给别的broker࿰c;@R_772_11247@自然就丢了

候选者：发送到Broker之后࿰c;也不能保证@R_772_11247@一定不丢了࿰c;毕竟Broker会把数据存储到磁盘之前࿰c;走的是操作系统缓存

候选者：也就是异步刷盘这个过程还有可能导致数据会丢

候选者：嗯࿰c;到这里其实我已经说了三个场景了࿰c;分别是：producer -> broker ࿰c;broker->broker之间同步࿰c;以及broker->磁盘

候选者：要解决上面所讲的问题也比较简单࿰c;这块也没什么好说的…

候选者：不想丢数据࿰c;那就使用带有callBACk的api࿰c;设置 acks、retries、factor等等些参数来保证Producer发送的消息不会丢就好啦。

面试官：嗯…

候选者：一般来说࿰c;还是client 消费 broker 丢消息的场景比较多

面试官：那你们在消费数据的时候是怎么保证数据的可靠性的呢？

候选者：首先࿰c;要想client端消费数据不能丢࿰c;肯定是不能使用autoCommit的࿰c;所以必须是手动提交的。

候选者：我们这边是这样实现的：

候选者：一、从Kafka拉取消息（一次批量拉取500条࿰c;这里主要看配置）时

候选者：二、为每条拉取的消息分配一个msgId（递增）

候选者：三、将msgId存入内存队列（sortSet）中

候选者：四、使用Map存储msgId与msg(有offset相关的信息）的映射关系

候选者：五、当业务处理完消息后࿰c;ack时࿰c;获取当前处理的消息msgId࿰c;然后从sortSet删除该msgId（此时代表已经处理过了）

候选者：六、接着与sortSet队列的首部第一个Id比较（其实就是最小的msgId）࿰c;如果当前msgId<=sort Set第一个ID࿰c;则提交当前offset

候选者：七、系统即便挂了࿰c;在下次重启时就会从sortSet队首的消息开始拉取࿰c;实现至少处理一次语义

候选者：八、会有少量的消息重复࿰c;但只要下游做好幂等就OK了。

面试官：嗯࿰c;你也提到了幂等࿰c;你们这业务怎么实现幂等性的呢？

候选者：嗯࿰c;还是以处理订单消息为例好了。

候选者：幂等Key我们由订单编号+订单状态所组成（一笔订单的状态只会处理一次）

候选者：在处理之前࿰c;我们首先会去查redis是否存在该Key࿰c;如果存在࿰c;则说明我们已经处理过了࿰c;直接丢掉

候选者：如果redis没处理过࿰c;则继续往下处理࿰c;最终的逻辑是将处理过的数据插入到业务DB上࿰c;再到最后把幂等Key插入到redis上

候选者：显然࿰c;单纯通过redis是无法保证幂等的（：

候选者：所以࿰c;redis其实只是一个「前置」处理࿰c;最终的幂等性是依赖数据库的唯一Key来保证的（唯一Key实际上也是订单编号+状态）

候选者：总的来说࿰c;就是通过redis做前置处理࿰c;DB唯一索引做最终保证来实现幂等性的

面试官：你们那边遇到过顺序消费的问题吗？

候选者：嗯࿰c;也是有的࿰c;我举个例子

候选者：订单的状态比如有 支付、确认收货、完成等等࿰c;而订单下还有计费、退款的消息报

候选者：理论上来说࿰c;支付的消息报肯定要比退款消息报先到嘛࿰c;但程序处理的过程中可不一定的嘛

候选者：所以在这边也是有消费顺序的问题

候选者：但在广告场景下不是「强顺序」的࿰c;只要保证最终一致性就好了。

候选者：所以我们这边处理「乱序」消息的实现是这样的：

候选者：一、宽表：将每一个订单状态࿰c;单独分出一个或多个独立的字段。消息来时只更新对应的字段就好࿰c;消息只会存在短暂的状态不一致问题࿰c;但是状态最终是一致的

候选者：二、消息补偿机制：另一个进行消费相同topic的数据࿰c;消息落盘࿰c;延迟处理。将消息与DB进行对比࿰c;如果发现数据不一致࿰c;再重新发送消息至主进程处理

候选者：还有部分场景࿰c;可能我们只需要把相同userId/orderId发送到相同的partition（因为一个partition由一个Consumer消费）࿰c;又能解决大部分消费顺序的问题了呢。

面试官：嗯…懂了

【对线面试官-移动端】系列 一周两篇持续更新中！

【对线面试官-电脑端】系列 一周两篇持续更新中！

原创不易！！求三连！！