Apache Kafka的队列支持：KIP-932与SoftwareMill的KMQ
内容提要
Apache Kafka社区正在努力实现队列式的消息平台，SoftwareMill提供了一种与现有的消费者组抽象一起工作的替代解决方案。Kafka的设计限制了灵活性，但支持高吞吐量。KIP-932提议使用共享组进行协作消息消费。共享组消除了消费者数量的限制，并简化了重新平衡过程。Kafka以精细的级别跟踪消息消费。共享组功能计划在Kafka 4.0版本中发布。另一种名为KMQ的替代选项更简单易实现和部署，解决了一些消费者组的缺点。KMQ实现了高性能，但没有解决头部阻塞问题和有限的并行性。
延伸解读
KIP-932 共享组：队列语义的原生支持
KIP-932 引入共享组抽象，允许非独占分区分配，从而消除消费者数量受分区数限制的问题，并简化再平衡过程。消费者可以单独确认消息，Kafka 在内部精细跟踪消费状态，包括获取、确认和超时重试。若投递尝试超过阈值，消息会被标记为拒绝，但当前尚无死信队列功能。该功能计划在 Kafka 4.0 发布，为队列式场景提供原生支持。
KMQ：现有 Kafka 上的轻量级替代方案
对于无法等待 Kafka 4.0 的用户，SoftwareMill 的 KMQ 模式利用现有消费者组实现个别消息确认。它引入 Redelivery Tracker 组件，通过专用标记主题和独立消费者组跟踪消息状态，并在处理超时后重新发布消息。若重投计数超过阈值，消息会进入配置的死信队列。KMQ 完全在消费者端实现，部署简单，兼容任何 Kafka 版本，但会引入额外延迟。
性能与局限：两种方案的权衡
根据项目团队的基准测试，KMQ 能达到与常规消费者组相似的吞吐量，同时支持个别消息确认。然而，KMQ 并未解决头部阻塞问题，消息处理的并行性仍受分区数量限制。KIP-932 的共享组通过非独占分配和更细粒度的跟踪，有望缓解这些限制，但需等待 Kafka 4.0 才能使用。选择时需权衡即时可用性与长期功能改进。
Q&A
KIP-932提议的共享组有什么优势？
共享组消除了消费者数量的限制，简化了重新平衡过程，并允许消费者独立处理和确认消息。
KMQ与共享组相比有什么不同？
KMQ是一种更简单的实现方式，主要在消费者端运行，解决了一些消费者组的缺点，但没有解决头部阻塞问题。
Kafka 4.0版本中将包含哪些新功能？
Kafka 4.0版本将包含共享组功能，允许更灵活的消息消费和更精细的消费跟踪。
KMQ如何处理消息确认？
KMQ使用重交跟踪器组件来标记消息为已交付和已确认，支持个别消息确认。
Kafka的设计限制了哪些功能？
Kafka的设计限制了灵活性，无法支持个别消息交付确认等处理用例。
共享组如何跟踪消息消费？
共享组允许Kafka在更细粒度的级别跟踪消息消费，记录每个消息的交付尝试次数。
