Kafka常见问题解决

概要:我们使用消息队列,就需要知道为什么要用消息队列,什么场景需要用消息队列,使用消息队列能带来哪些好处和消息队列会带来哪些问题?如何去避免这些问题。

一、MQ的好处

解耦:在某些场景下,A服务订单达到某个状态之后,需要发生一份消息到好几个服务,但是对于A服务来说,它并不关心其他服务如何什么时候、如何处理这个消息。那么就可以利用MQ解耦。A服务只管将消息发出去,其他服务想要用这个数据,就可以开启消费者组,这样就可以保证每个服务能消费到所有的数据了。
异步:使用异步可以提高接口响应速度,如果要跟其他系统交互的话,时间大概是几百ms,而投递到MQ时间在几ms,而且在不同场景下调节参数可以提高消息投递的速度。(ack的值)
削峰:在流量比较高的时候,为了较少对MySQL的压力,使用缓存主要是解决查询的压力,而对于写入则可以用MQ来削峰,在高峰期时候流量进入MQ,会造成暂时的积压,等流量降低之后,积压的数据很快就会被消费完。
MQ的好处这么多,但是也无可避免地会带来一些问题。主要是以下两个方面1. 系统的可用性降低,引入了中间件,如果中间件挂了,那么数据有丢失风险2. 复杂度上升,正常的系统间交互,我们通常不需要考虑重复消费问题,只要从HTTP请求来解决幂等性就可以。还有就是消息积压的解决,对于MQ的监控等问题,都要加以考虑。接下来我们就逐一看看对于常见的MQ问题。

二、消息丢失问题

Kafka消息丢失可以分为三种情况:生产者发送过程丢失,Kafka丢失和消费端丢失。

  1. 生产者丢失:Producer端的ack表示什么情况下Kafka才认为数据成功成功发送。ack=0表示生产者不需要等待broker的同步确认,就可以处理下一批数据了,那么如果由于网络原因或者leader挂了,消息丢失了,也很难发现。ack=1表示生产者需要确认leader成功写入就可以成功返回给生产者客户端,这种配置下如果leader挂了,那么消息也会丢失。另一种比较可靠的配置是ack=-1,表示消息成功写入leader和ISR副本之后就可以返回了,如果leader挂了,Kafka还可以从ISR中选举出新的leader,如果这时候ISR为空,那么根据其他参数看是否选举其他副本,这其实就是在高可用和消息不丢失之间的权衡了。另外retires重试次数设置大一些可以保证在生产过程消息不会丢失。
  2. Kafka丢失消息:这里需要关注的主要就是Kafka的删除策略,如果文件过大,或者是超过一段时间,会被Kafka删除。还有Kafka的持久化 方式,Kafka其实是充分利用了磁盘的页缓存的,那么如果写入页缓存,没写入磁盘的时候ack是否会返回?(这块需要再查一下相关书籍)。
  3. 消费者丢失消息:这个其实也比较常见,如果设置Kafka自动提交偏移量,那么可能消息偏移量提交之后,消费者挂了,消息还没处理完,那么这部分数据就丢失了。在消费者端解决的方式就是由消费端决定何时提交偏移量,设置enable.auto.commit为false

三、重复消费问题

这个方案有Kafka的内置幂等性保证和事务,但是对性能有损,虽好还是结合业务情况来保证幂等性。
比如你拿个数据要写库,你先根据主键查一下,如果这数据都有了,你就别插入了,update 一下好吧。
比如你是写 Redis,那没问题了,反正每次都是 set,天然幂等性。
比如你不是上面两个场景,那做的稍微复杂一点,你需要让生产者发送每条数据的时候,里面加一个全局唯一的 id,类似订单 id 之类的东西,然后你这里消费到了之后,先根据这个 id 去比如 Redis 里查一下,之前消费过吗?如果没有消费过,你就处理,然后这个 id 写 Redis。如果消费过了,那你就别处理了,保证别重复处理相同的消息即可。
比如基于数据库的唯一键来保证重复数据不会重复插入多条。因为有唯一键约束了,重复数据插入只会报错,不会导致数据库中出现脏数据。

四、消息积压问题

消息积压主要有以下原因:
消费者速度跟不上生产者的速度:这个时候,可以先看批次拉取的大小是否合理,以及消费者的消费逻辑是否已经使用多线程消费了。如果还是跟不上消费速度,那么可以考虑同时增加partition和消费者大小。
消费者挂了:先把消费者恢复。
瞬时流量过大:如果是这个原因的话,如果积压的不是特别多的话,等流量低的时候消费者自然会把积压的数据消费完。

五、高可用问题

Kafka架构可以保证高可用


kafka架构

六、顺序性问题

对于Kafka来说,以topic为逻辑单位存储,物理存储结构单位是partition,而topic切分成partition无法保证有序,但是partition是顺序写的,可以保证有序。如果我们需要按照某个维度保持有序的话,可以设置消息的key

推荐阅读更多精彩内容