原创：Jesse Anderson

翻译：Sijie Guo

应用 Kafka 或 Pulsar 的一个常见用例是创立工作队列。这两种技术为实现此用例提供了不同的实现。我将探讨在 Kafka 和 Pulsar 中实现工作队列的办法以及它们的绝对劣势。

什么是工作队列

工作队列（Work Queue）通过应用消息中间件零碎公布音讯来增加工作工作。一个工作音讯通常将由一个过程（最好是一组过程）生产，而后对其进行某种解决。

工作队列在音讯解决工夫上通常与其余解决形式略有不同。大多数惯例数据处理（如 ETL 或简略解决）在毫秒到秒级之间实现。然而工作队列用例下的音讯解决工夫通常绝对更长，从几秒到几分钟，甚至几个小时。

工作队列也被称为分布式工作队列（distributed work queue）。因为单台机器或者单个过程不足以满足相应的解决需要。咱们必须通过在许多不同的过程和计算机之间散发工作工作来满足相应的解决需要。因为引入了分布式的技术，所以工作解决零碎的复杂性也减少了 10-15 倍。

工作队列的示例

为了帮忙您了解工作队列，让我举几个我在事实世界中看到的简略示例。所有示例的共同点是：工作的解决须要更长的工夫，同时必须尽快取得后果。

视频转码

在视频网站，用户须要上传视频。此视频将保留到对象存储中。实现视频上传后，Web 服务将公布一条对于该视频的音讯，蕴含要转码的视频的存储地址。这条音讯将由一组消费者生产，这些消费者将对此视频进行转码，以便以网络敌对的格局应用。转码可能须要几分钟到几小时能力实现。一旦视频转码实现，解决转码的消费者将公布一条新的音讯告知此视频曾经能够应用。

语音辨认与场景剖析

通常主动客服零碎须要解决来自于呼叫核心的电话呼叫数据。当一个电话呼叫实现后，有多个步骤会产生。首先，语音辨认的程序须要解决呼叫的语音对话，将音频转化为文本。接下来，应用各种 NLP 和场景剖析工具将对文本进行剖析。整个处理过程须要 1 -60 分钟。当整条电话呼叫数据被解决后，零碎还须要公布一条音讯来告知该呼叫数据已被解决实现。

工作队列的挑战

工作队列的最基本的挑战是如何散发和平衡工作工作。你须要确保一个长时间运行的过程不会导致队列中的其余工作工作大量累积；其余的工作过程可能继续的拿到工作工作进行解决。同时，你还须要可能随着流量的变动主动地扩大工作解决能力。

工作队列的最大挑战在于如何处理错误：

• 你如何晓得一个工作过程是否挂掉或者何时挂掉？
• 你如何从新开始解决？
• 你如何检测一个工作过程是否挂掉？

这些问题的答案都是针对特定技术的。当你的利用场景中须要应用工作队列的时候，这些答案对你抉择何种技术至关重要。

为什么不批量解决

一个常见问题是为什么要应用实时零碎而不是批处理零碎？批处理零碎具备固有的启动工夫。对于 30 秒的解决工夫，你可能须要破费 5 -10 秒期待分布式系统调配和启动资源。实时工作队列的要害之一是失去处理结果的速度。批处理零碎解决此类数据的效率太低。

应用 Kafka 实现工作队列

既然您曾经理解了工作队列以及与它们相应的挑战，那么接下来，咱们来讨论一下如何应用 Apache Kafka 创立工作队列。

High Watermark 和工作队列

在理解如何应用 Kafka 创立工作队列之前，你须要理解 Kafka 消费者如何标记他们曾经生产了音讯。Kafka 消费者通过提交偏移量来执行此工作。Kafka 消费者能够应用 commitSync 或 commitAsync 来提交生产偏移量。

Kafka 消费者应用 High Watermark 来代表偏移量。这也就意味着消费者只能说“我曾经解决到这个偏移量”，而不是“我曾经解决过这个音讯”。这是 Kafka 跟其余消息中间件的一个重要区别。Kafka 没有 内置 的形式来确认单条音讯。

这种以 High Watermark 记录消费者偏移量的形式意味着应用程序无奈单条地记录和发现错误。例如，如果消费者正在解决来自同一分区的两条工作工作而其中一件失败，那么 Kafka 不足 内置 的形式来通知应用程序这一条音讯失败了但另外一件音讯胜利了。Kafka 的客户端能够告知应用程序曾经确认解决到了这一个偏移量，然而没法告知哪条音讯胜利和哪条音讯失败。

要绕过这个限度，你须要让每个消费者将每个分区视为它本人的工作“线程”。每个分区将被限度为一次解决一件事。当消费者实现这项工作时，它将调用 commitSync 标记解决实现。

因为您要在分区中放弃长时间运行，因而您必须创立更多分区来无效地解决数据。尽管您可能曾经开始应用 20-30 个分区，但您最终须要 100 个分区。这个分区数量是受限于 Kafka 的生产形式，因为整个消费者群须要足够的分区来无效地调配负载。

可能显而易见，您须要依据您要解决的工作量来调配失当的分区数量来相应地扩大您的生产组。

治理本人的提交

你会留神到我屡次应用“内置”这个词。这是因为还有另一种抉择，它不是 Kafka 内置的。你必须编写本人的代码来实现单条确认。

如您所见，Kafka 消费者的问题是受限于 High Watermark 的生产形式。您能够通过编程的形式来本人解决消费者的偏移量。最简略的办法是应用数据库：你必须敞开 Kafka 的主动偏移提交；而后你能够在数据库而不是 Kafka 中记录你解决过音讯的偏移量。

当消费者重新启动时，消费者须要晓得它相应的分区调配，而后进行数据库查找以查找最初一个偏移量及其状态。如果最初一个偏移量出错，则消费者将重新处理该音讯。

尽管这会减少更多的开销，但这是我向应用 Kafka 的团队举荐的一种办法。

应用 Pulsar 实现工作队列

既然您曾经理解了如何应用 Kafka 创立工作队列，那么让咱们来看看如何应用 Apache Pulsar 来实现，并进行比照。

选择性确认

咱们在上一节理解过 Kafka 的 High Watermark。Pulsar 在反对这种类型的确认的同时，还反对另外一种类型的确认，叫做 选择性确认。选择性确认容许消费者仅确认单条音讯。您能够拜访 Pulsar 的官网文档中对于 Ack 的局部，理解更多无关选择性确认的细节。

当谈到工作队列时，选择性确认让工作队列变得简略。在一个工作队列中，咱们能够通过应用选择性 acknowledge 仅仅确认咱们曾经确认解决过的音讯。

如果要获取那些解决失败了的音讯，你能够通过调用 redeliverUnacknowledgedMessages 办法来获取。这将使 Pulsar 从新投递那些未经确认的音讯。你也能够通过设置另外一个参数 ackTimeout，让 Pulsar 主动从新传递那些超时未确认的音讯。

Pulsar 在解决分布式工作队列上还有另外一个劣势。在一个领有很多散布的分布式工作队列中，一些分区依然有可能成为热点，或者接管大量的工作音讯。Pulsar 通过应用共享订阅更好地解决了这个问题。共享订阅容许跨消费者进行循环散发。这样能够比 Kafka 更平均地调配工作。

在 Pulsar 中，你会将工作音讯公布到工作队列中。此音讯将一个共享订阅中的许多不同消费者过程中进行生产，而后消费者开始理论的数据处理。一旦实现该解决，消费者将选择性地确认该音讯。接着，它会产生一条新的音讯，阐明改音讯曾经实现解决。

留神： Pulsar 在开始设计之初就把工作队列的利用场景思考在内，并针对它进行优化，因为 Yahoo 在外部有大量的工作队列利用场景。这也是咱们看到 Pulsar 和 Kafka 之间有如此微小差别的重要起因。

创立分布式工作队列

抉择不同的消息中间件零碎将的确扭转你实现分布式工作队列的形式。尽管你能够抉择任何一种解决方案创立分布式工作队列，然而 Kafka 和 Pulsar 有不同的创立办法。应用 Pulsar 创立分布式工作队列要容易得多。

如果你有工作队列的应用场景，请多多比照确保应用最合适的技术来实现。

点击 链接，查看英文原文