让 Kafka 支持队列功能：KIP-932和KMQ
Apache Kafka 社区正在积极推动一项名为 KIP-932（Kafka Improvement Proposal，KIP）的工作，目的是为这一广受欢迎的消息传递平台引入类似队列的功能。该提案引入共享群组的概念，用于实现协作式消息消费。与此同时，SoftwareMill 提供了一种替代解决方案，能够与现有的消费者群组机制无缝集成。
Apache Kafka 多年来一直是消息传递解决方案的行业标杆，这主要得益于其卓越的性能和可靠的持久消息传递能力。Kafka 的设计哲学是通过减少通信开销和数据转换来实现高吞吐量。然而，这种高性能以牺牲一定的灵活性为代价，不支持某些处理用例，例如个别消息的传递确认。
Apache Kafka 采用消费者群组来实现消息消费，将主题分区独占分配给消费者组中的消费者，并对分区偏移量进行跟踪。这种设计可能会引发队列头部阻塞问题，即单个消息处理缓慢或阻塞可能会影响甚至导致整个消费者应用程序挂起。此外，消息处理的并行度受限于分区数量，因此在创建分区之初必须仔细规划分区的数量，以确保能满足所需的吞吐量。
Apache Kafka 中的共享群组（来源：SoftwareMill 博客）
KIP-932: Queues For Kafka 提案提出了一种创新方法，通过引入共享群组的概念来实现协作式消息消费。共享群组使用了不一样的分区分配策略，其特点是分配不是独占的，打破了消费者数量受分区数量的限制。它还简化并缩短了再均衡过程，并避免了在再均衡期间发生的“停止世界”现象。
此外，共享组允许消费者独立处理并确认消息，Kafka 能够更细粒度地跟踪消息的消费情况。当消费者请求消息时，Kafka 共享分区会返回一批标记为已获取的消息。这些消息会保持这一状态，直到消费者确认或达到处理时间限制。如果处理时间限制被触发，这些消息将重新变为可用状态。
Kafka 还负责跟踪消息的传递尝试次数，并在尝试次数超过阈值时将消息标记为已拒绝。目前，死信队列（Dead Letter Queue，DLQ）功能还不能用来捕获未传递的消息，但未来可能会加入这一特性。Kafka 代理负责维护并持久化所有内部状态，并通过单独的内部主题来跟踪个体消息的传递情况。共享群组功能计划在 Kafka 4.0 中推出。
对于那些想要立即体验新功能而不愿等待 KIP-932 在 Kafka 4.0 中发布的人来说，SoftwareMill 提供了一个可行的替代方案。SoftwareMill 首席研发官 Adam Warski 介绍了该解决方案：
KMQ 是一种利用 Kafka 消费者群组功能实现个别消息确认的模式，可以与任意 Kafka 版本一起运行。你可能会发现 KMQ 与共享群组的设计有一些相似之处。KMQ 在实现和部署方面要简单得多，这也意味着它只解决了消费者组的一些局限性。KMQ 完全是一种消费者端机制，与共享群组代理端的复杂逻辑不同。
KMQ 引入了一个额外的组件，即重新传递跟踪器，负责将消息标记为已交付和确认。这一机制类似于共享群组，只是操作发生在应用程序端。跟踪器利用了一个专门的“标记”主题和一个单独的消费者群组，当消息处理超过预定时间，这些消息会被重新发布回正在跟踪的主题。如果重新传递计数器（这是个体消息内部状态的一部分）超过配置的阈值，消息将被发布到 死信队列（DLQ） 主题。
KMQ 的模式设计（来源：SoftwareMill 博客）
由于 KMQ 解决方案需要将标记发布到专门的主题，引入了一定的额外延迟，但该项目团队的性能基准测试表明，该方案能够实现与传统消费者群组相当的吞吐量。KMQ 模式的主要好处是它支持在当前可用的 Kafka 客户端版本中对每条消息进行单独确认，同时还能提供高性能的处理能力。然而，该模式并没有解决队列头部阻塞问题，并且并行度仍然受到分区数量的限制。
查看英文原文：
https://www.infoq.com/news/2024/07/apache-kafka-queues/
声明：本文由 InfoQ 翻译，未经许可禁止转载。
今日好文推荐剥离几百万行代码，复制核心算法去美国？TikTok 最新回应来了
15 年功臣、英伟达主任科学家在股价巅峰期黯然辞职：对不起自己拿的丰厚报酬
开源独角兽 GitLab 走上“卖身”路！前工程师拆台：赚钱的业务不好好运营，开发了一堆没用的功能