【八股消消乐】消息队列优化

在这里插入图片描述

😊你好，我是小航，一个正在变秃、变强的文艺倾年。
🔔本专栏《八股消消乐》旨在记录个人所背的八股文，包括Java/Go开发、Vue开发、系统架构、大模型开发、具身智能、机器学习、深度学习、力扣算法等相关知识点，期待与你一同探索、学习、进步，一起卷起来叭！

题目

💬技术栈：RocketMQ、Kafka、RabbitMQ

🔍简历内容：熟悉Kafka消息分区。为解决Kafka线上消息积压、broker性能抖动问题，针对业务内有序为topic实现了多分区。参考Redis槽与槽分配机制解决了数据不均匀问题。针对分区扩容采用了停顿方案解决消息失序问题。

🚩面试问：你觉得在多分区方案里面，如果某个分区消息积压了就启用异步消费，这种解决思路你觉得怎么样？

在这里插入图片描述

💡建议暂停思考10s，你有答案了嘛？如果你有不同题解，欢迎评论区留言、打卡。

答案

Kafka 消息分区

在 Kafka 中，消息是以分区为单位进行存储的。每个 topic 都可以被划分为一个或多个分区，每个分区都是一个 有序、不可变 的消息日志。Kafka 使用 WAL （write-ahead-log）日志来存储消息。每个分区都有一个对应的日志文件，新的消息会被追加到文件的末尾，而已经加入日志里的消息，就不会再被修改了。

在这里插入图片描述

每个消息在分区日志里都有一个唯一的偏移量（offset），用来标识消息在分区里的位置。 Kafka 保证同一分区内的消息顺序，但不保证不同分区之间的顺序。而 Kafka 本身暴露了对应的接口，也就是说你可以显式地指定消息要发送到哪个分区，也可以显式地指定消费哪个分区的数据。

有序消息

有序消息：消费者消费某个 topic 消息的顺序，和生产者生产消息的顺序一模一样。

生产者生产消息的顺序，不是指你创建出来消息那个实例的先后顺序，而是指broker收到的顺序。

跨topic的有序消息

问题：保证不同topic之间消息是有序的。比如说 msg1 先发送到了 topic_a 上， msg2 被发送到了 topic_b 上。但是在业务层面上，要求 msg1 一定要先于 msg2 消费。

解决方案：引入一个协调者，这个协调者负责把消息重组为有序消息。比如说，如果 msg2 先到了，但是 msg1 还没出来，那么这个协调者要有办法让 msg2 的消费者 B 停下来，暂时不消费 msg2。而在 msg1 来了之后，唤醒消费者 A 消费 msg1，并且在消费完 msg1 之后要再唤醒消费者 B 处理 msg2。

简历优化

前置准备：

在什么业务场景下，你需要用到有序消息？
你是如何解决有序消息这个问题的？用的是哪种方案？
如果你用的是单分区解决方案，那么有没有消息积压问题？如果有，你是怎么解决的？
如果你用的是多分区解决方案，那么有没有分区负载不均衡的问题？如果有，你是怎么解决的？

单分区

解决方案：为了保证消息有序，让特定的 topic 只有一个分区。这样所有的消息都发到同一个分区上，那么自然就是有序的。

存在的问题： 性能差、消息积压。

生产端：所有的消息都在一个分区上，也同时意味着所有的消息都发送到了同一个broker上，这个服务器很可能撑不住压力；
消费端：只有一个分区，那么就只能有一个消费者消费，很容易出现消息积压的问题。

在这里插入图片描述

全局有序：没什么优化手段，只能是换用更加强大的机器。
业务内有序：比如说在下单的场景下，会产生创建订单消息和完成支付消息。业务上只会要求同一个订单的创建订单消息应该优先于完成支付消息，但是不会要求订单 A 的创建消息需要先于订单 B 的支付消息。这种解决方案参考下面的异步消费、多分区方案。

异步消费

问题：单分区方案中，由于只有一个消费者，容易造成消息积压。

解决方案：保证同一个业务内的顺序。当消费者从队列取出来消息之后，把同一个业务的消息丢到同一个队列里。

在这里插入图片描述
消费者线程从 Kafka 里获取消息，然后转发到内存队列里面。在转发的时候，要把同一个业务的消息转发到同一个队列里面。一般来说可以根据业务特征字段计算一个哈希值，比如说直接使用业务 id 作为哈希值。利用这个哈希值除以工作线程数量，然后取余数，得到对应的内存队列。

存在的问题：可能存在消息未消费。消费线程取出来了，转发到队列之后，工作线程还没来得及处理，消费者整体就宕机了，那么这些消息就存在丢失的可能。

多分区

将上面方案的内存队列换成了多个分区。原本同一个业务的消息发送到同一个分区。

保证同一个业务的消息必然发送到同一个分区：生产者在发送消息的时候，根据业务特征，比如说业务 ID 计算出目标分区，在发送的时候显式地指定分区就可以了。

在这里插入图片描述

引发的问题：数据不均匀、增加分区可能导致消息失序。

数据不均匀

问题：数据不均匀一般是业务造成的。在我们的方案里面，分区是根据业务特征来选择的，那么自然有一些分区有很多数据，有一些分区数据很少。比如说万一我们不小心把热点用户的消息都发到了同一个分区里面，那么这个分区的 QPS 就会很高，消费者也不一定来得及消费，就可能引起消息积压。

在这里插入图片描述

解决方案：Redis 中槽和槽分配的机制，又或者说一致性哈希算法。

槽与槽分配

借鉴 Redis 的槽与槽分配方案。不过 Redis 使用了 16384 个槽，一般的业务用不上那么多槽，所以可以考虑用 1024 个槽。根据业务的特征来计算一个哈希值，再除以 1024 取余就可以得到所在的槽。再根据不同槽的数据多少，合理地把槽分配到不同的分区。最好把槽和分区的绑定关系做成动态的，也就是说我可以随时调整槽到分区的映射关系，保证所有的分区负载都是均匀的。

在这里插入图片描述

动态调整槽与分区的绑定：借助于配置中心来完成。比如说最开始你把槽 1 绑定到分区 2 上，后面在运行的时候你发现分区 2 数据太多，就把槽 1 重新绑定到了分区 3 上。

一致性哈希

使用一致性哈希算法来筛选分区。首先要根据数据分布的整体情况，把分区分布在哈希环上，确保每一个分区上的数据分布大体上是均匀的。如果一部分哈希值上数据较多，就多插入几个分区节点。然后根据业务特征计算一个哈希值，从哈希环上找到对应的分区。

在这里插入图片描述

消息失序

场景：如果中间有增加新的分区，那么就可能引起消息失序。比如说最开始 id 为 3 的订单消息 msg1 发到分区 0 上，但是这时候很不幸分区 0 上积攒了很多消息，所以 msg1 迟迟得不到消费。紧接着我们扩容，增加了一个新的分区。如果这时候来了一个消息 msg2，那么它会被转发到分区 3 上。分区 3 上面没有积攒什么数据，所以消费者 3 直接就消费了这个消息。本来 msg1 应该先于 msg2 被消费。而增加分区之后 msg2 反而被先消费了。

解决方案：对于新加入的分区，可以暂停消费一段时间。如果我们估算 msg1 会在一分钟内被消费，那么新加入的分区的消费者可以在三分钟后再开始消费。那么大概率 msg1 就会先于 msg2 消费。

不过这种等待的解决方式并不能解决根本问题，只能说是很大程度上缓解了问题。但是本身增加分区也是一个很不常见的操作，再叠加消息失序的概率也很低，所以我们也可以通过监控发现这种失序场景，然后再手工修复一下就可以了。

简历总结：

最开始我进公司的时候就遇到了一个 Kafka 的线上故障。我司有一个业务需要用到有序消息，所以最开始的设计就是对应的 topic 只有一个分区，从而保证了消息有序。

可是随着业务增长，一个分区很快就遇到了性能瓶颈。只有一个分区，也就意味着只有一个消费者，所以在业务增长之后，就开始出现了消息积压。另外一方面，这个分区所在的broker的负载也明显比其他服务器要大，偶尔也会有一些性能抖动的问题。

后来我仔细看了我们的业务，实际上，我们的业务要求的不是全局有序，而是业务内有序。

换句话来说，不一定非得用一个分区，而是可以考虑使用多个分区。所以我就给这个 topic 增加了几个分区，同时也增加了消费者。优化完之后，到目前为止，还没有出现过消息积压的问题。

当然，为了避免在单分区增加到多分区的时候，出现消息失序的问题，我用了一个很简单的方案，就是对应的消费者在启动之后，并没有立刻消费，而是停顿了三分钟，从而避免了潜在的消息失序问题。

往期精彩专栏内容，欢迎订阅：

🔗【八股消消乐】20250624：消息队列优化—延迟消息
🔗【八股消消乐】20250623：消息队列优化—系统架构设计
🔗【八股消消乐】20250622：Elasticsearch查询优化
🔗【八股消消乐】20250620：Elasticsearch优化—检索Labubu
🔗【八股消消乐】20250619：构建微服务架构体系—保证服务高可用
🔗【八股消消乐】20250615：构建微服务架构体系—链路超时控制
🔗【八股消消乐】20250614：构建微服务架构体系—实现制作库与线上库分离
🔗【八股消消乐】20250612：构建微服务架构体系—限流算法优化
🔗【八股消消乐】20250611：构建微服务架构体系—降级策略全总结
🔗【八股消消乐】20250610：构建微服务架构体系—熔断恢复抖动优化
🔗【八股消消乐】20250609：构建微服务架构体系—负载均衡算法如何优化
🔗【八股消消乐】20250608：构建微服务架构体系—服务注册与发现
🔗【八股消消乐】20250607：MySQL存储引擎InnoDB知识点汇总
🔗【八股消消乐】20250606：MySQL参数优化大汇总
🔗【八股消消乐】20250605：端午节产生的消费数据，如何分表分库？
🔗【八股消消乐】20250604：如何解决SQL线上死锁事故
🔗【八股消消乐】20250603：索引失效与优化方法总结
🔗【八股消消乐】20250512：慢SQL优化手段总结
🔗【八股消消乐】20250511：项目中如何排查内存持续上升问题
🔗【八股消消乐】20250510：项目中如何优化JVM内存分配？
🔗【八股消消乐】20250509：你在项目中如何优化垃圾回收机制？
🔗【八股消消乐】20250508：Java编译优化技术在项目中的应用
🔗【八股消消乐】20250507：你了解JVM内存模型吗？
🔗【八股消消乐】20250506：你是如何设置线程池大小？
🔗【八股消消乐】20250430：十分钟带背Duubo中大厂经典面试题
🔗【八股消消乐】20250429：你是如何在项目场景中选取最优并发容器？
🔗【八股消消乐】20250428：你是项目中如何优化多线程上下文切换？
🔗【八股消消乐】20250427：发送请求有遇到服务不可用吗？如何解决？

📌 [ 笔者 ]   文艺倾年
📃 [ 更新 ]   2025.6.25
❌ [ 勘误 ]   /* 暂无 */
📜 [ 声明 ]   由于作者水平有限，本文有错误和不准确之处在所难免，本人也很想知道这些错误，恳望读者批评指正！

在这里插入图片描述