《KIP-932：Queues for Kafka》于7天前发布。

Kafka的队列Queues 是目前讨论的最热门的新功能！

传统的队列系统是这样一种系统：

• - 多个消费者从同一队列读取（pub-sub）
• - 一个特定的消费者从一个特定的生产者读取（点对点）

Kafka从未支持过这样的传统排队。

它的优势之一恰恰是生产者和消费者之间的脱钩。 一个糟糕的消费者对生产者的影响几乎为零。（除非它导致Kafka从磁盘读取并耗尽IO）

这种方法的一个痛点是消费者组与主题中的分区数量相关联。
如果您有一个包含10个分区的主题，则不能扩展到超过10个消费者。

所以，人们通常过度分割。 但对于统一的工作负载来说，这是非常不直观的。

如果您的所有消息都是没有逻辑分组的独立工作项，则由一个应用程序池使用的单个队列是直观的解决方案。

因此，KIP-932提出了一种具有以下优点的解决方案：

• - 许多消费者从同一分区读取的能力
• - 个别记录确认
• - 仍然保持生产者和消费者脱钩
• - 最大值（No maximum queue depth）
• - 消息仍然保留-因此您可以重播

限制:

• 顺序不保证。分区内可能出现无序传递。
• 至少一次传递，无法做到精确一次
• 最大处理增量。一个消费者不能比最慢的那个消费者提前读取超过N条信息。

它是如何做到的？

共享的消费者群体。

每个broker将成为它所领导的数据分区的共享组协调人，并管理读取的共享。

它将为每一对分区和组保持一个开始<->结束偏移的滑动窗口。
可供消费的记录将只是那些在该偏移量范围内的记录，本质上是在最慢和最快的消费者之间增加一个最大的滞后lag 。

来自同一共享组的消费者可以通过有时间限制的获取锁，专门保留分区中的一些记录（偏移范围），从同一分区中读取。

然后，消费者可以接受/释放/拒绝该信息：

•  ack - 确认处理成功并移动共享组的偏移量进度
•  释放--处理不成功--重试。释放记录，以便再次交付。
•  reject - 处理不成功 - 终止。将该记录列入黑名单，使其不能用于另一次交付。

 为了避免毒丸信息--每条信息都有一个递送计数。当它超过最大重试限制时，该消息被拒绝。

总结
一句话，这是一个由任意数量的消费者进行无序消费的可用性功能。