大家好，我是苏三，又跟大家见面了。

前言

我之前在一家餐饮公司待过两年，每天中午和晚上用餐高峰期，系统的并发量不容小觑。为了保险起见，公司规定各部门都要在吃饭的时间轮流值班，防止出现线上问题时能够及时处理。

我当时在后厨显示系统团队，该系统属于订单的下游业务。

用户点完菜下单后，订单系统会通过发kafka消息给我们系统，系统读取消息后，做业务逻辑处理，持久化订单和菜品数据，然后展示到划菜客户端。

这样厨师就知道哪个订单要做哪些菜，有些菜做好了，就可以通过该系统出菜。系统自动通知服务员上菜，如果服务员上完菜，修改菜品上菜状态，用户就知道哪些菜已经上了，哪些还没有上。这个系统可以大大提高后厨到用户的效率。

这一切的关键是消息中间件：kafka，如果它出现问题，将会直接影响到后厨显示系统的用户功能使用。

这篇文章跟大家一起聊聊，我们当时出现过的消息积压问题，希望对你会有所帮助。

1 第一次消息积压

刚开始我们的用户量比较少，上线一段时间，mq的消息通信都没啥问题。

随着用户量逐步增多，每个商家每天都会产生大量的订单数据，每个订单都有多个菜品，这样导致我们划菜系统的划菜表的数据越来越多。

在某一天中午，收到商家投诉说用户下单之后，在平板上出现的菜品列表有延迟。

厨房几分钟之后才能看到菜品。

我们马上开始查原因。

出现这种菜品延迟的问题，必定跟kafka有关，因此，我们先查看kafka。

果然出现了消息积压。

通常情况下，出现消息积压的原因有：

1. mq消费者挂了。

2. mq生产者生产消息的速度，大于mq消费者消费消息的速度。

我查了一下监控，发现我们的mq消费者，服务在正常运行，没有异常。

剩下的原因可能是：mq消费者消费消息的速度变慢了。

接下来，我查了一下划菜表，目前不太