卡夫卡向上分割的传入消息划分为分区，根据由生产者指定的分区。从分区的消息，然后获得消费者的不同消费群体的消费。
这种架构使我谨慎使用卡夫卡作为工作/任务队列的，因为我有在生产的时候，指定分区哪些消费者可以因为一个分区中的一个消费群体只发送给一个消费者在它的工作间接限制。我宁愿不提前指定分区，让消费者无论是可采取的任务可以这样做。有没有一种方法，以结构卡夫卡架构，任务可以由下一个可用的消费拉动分区/生产商，而不必在工作中产生通过选择一个分区拆分提前的时间了工作？
仅使用一个分区这个话题会把所有的任务在同一个队列，但随后消费者的数量是有限的，以1元的消费群体，所以每个消费者将不得不在不同的组。然后，所有的任务得到分散到各个消费群体，虽然，这是不是我要找的那种工作队列。
就是Apache卡夫卡适合用作任务队列？
使用卡夫卡的任务队列是一个坏主意。使用RabbitMQ的，相反，它做得非常好，更优雅。
虽然你可以使用卡夫卡的任务队列 - 你会得到一些问题：卡夫卡是不允许食用受到很多消费者的一个分区（设计），因此，如果例如单个分区被充斥着许多任务和消费者谁拥有分区是忙碌的，该分区中的任务将获得“饥饿”。这也意味着，如果任务需要以特定的顺序被消耗（以卡夫卡完全实现，你必须在主题任务的用电秩序不会是相同的，其任务是制作这可能会导致严重的问题的顺序只有一个消费者和一个分区 - 这意味着仅由一个节点串行消费如果有多个消费者和多个分区任务的消费不会在话题层面得到保证的顺序）。
事实上 - 卡夫卡的话题是不是在计算机科学的方式队列。队列意味着先进先出 - 这是不是你在获得卡夫卡在主题级别。
另一个问题是，它是很难动态地改变分区的数量。添加或删除新工人应该是动态的。如果你想确保新员工将获得Kakfa任务，你将不得不设置分区数量最大可能的工人。这是不优雅不够。
因此，底线 - 使用RabbitMQ的或其他队列来代替。
说了这么多的 - Samza（通过LinkedIn）作为某种基于流任务队列的使用卡夫卡：Samza
编辑：规模方面的考虑：我忘了提，Kakfa是一个大数据/大缩放工具。如果您的工作速度是巨大的，然后卡夫卡可能是，尽管我前面写的东西对你很好的选择，因为处理庞大的规模是非常具有挑战性和卡夫卡是这样做非常好。如果我们谈论的是更小尺度（比如说，高达几dosens /每秒数百职位）然后再次卡夫卡相比的RabbitMQ一个糟糕的选择。
我会说，这取决于规模。多少任务，你在单位时间内预期？
你形容为你的最终目标是什么，基本上卡夫卡是如何工作的默认。当你生产的消息，默认的（最广泛使用）选择是使用随机分区，将选择分区的循环方式，保持均匀使用的分区（因此有可能避免指定分区）。
分区的主要目的是并行消息的处理，所以你应该以这样的方式使用它。
该分区用于将保证某些消息能以相同的顺序食用，因为它们产生的其他常用的“东西”（那么你指定以这样的方式，所有这些消息在同一个分区结束了分区键，使用userId如关键将确保所有用户都以这样的方式进行处理）。
有这个话题绕了工作或任务队列的任务的执行顺序循环中大量的讨论。我想提出的概念，执行的顺序不应该是一个工作队列的一个特征。
工作队列是朝着不同的任务完成申请工作线程的数量可控的控制资源使用的一种手段。在队列中强制执行的任务的处理顺序意味着你也执行在这实际上意味着，在队列中的任务总是会被依次处理，只有前面的任务结束后，被处理的下一个任务队列任务的完成顺序。这实际上意味着你有一个单线程任务队列。
如果执行的顺序是在你的一些重要的任务，那么这些任务应该在序列中添加下一个任务的完成后的工作队列。如果不是这样，你支持的处理时，实际处理上的一个工人连续作业的列表连续的作业类型。
绝不应该在工作队列竟下令所有的工作 - 下一个可用的处理器应该始终把下一个任务没有关于之前已经或任务完成之后发生了什么。
我也看卡夫卡作为一个工作队列的基础，但我研究它的越少，它看起来像期望的平台。
我看到它主要被用作同步不同的资源，而不是这么多的执行不同的任务要求的一种手段的一种手段。
我认为是一个工作队列重要的另一个领域是任务的优先级的支持。例如，如果我在队列20级的任务，新的任务具有更高的优先级到达时，我想这个任务跳转到该行的开始到下一个可使用的工人被拾起。卡夫卡就不允许这样做。
有在试图用卡夫卡的消息队列两个主要障碍：
的RabbitMQ当然是一种选择，但它也给不同（更低）的性能和复制保证。总之，RabbitMQ的文档指出，券商is not partition tolerant。另请参见我们的数据复制，mqperf消息队列的比较。