在Kafka中，来自同一生产者的具有相同密钥的消息按顺序传递给消费者
除此之外的另一件事是，分区内的数据将按写入顺序存储，因此，从分区读取的数据将按该分区的顺序读取
因此，如果您想让消息在多个分区之间按顺序排列，那么您真的需要使用一个键对消息进行分组，以便具有相同键的消息进入同一分区，并在该分区中对消息进行排序。
简而言之，您将需要设计一个两级的解决方案，就像上面逻辑上的那样，以获得跨多个分区排序的消息。

在Kafka中，并行度等于一个主题的分区数。
例如，假设您的消息是基于用户标识进行分区的，并考虑4条具有用户标识1、2、3和4的消息。假设您有一个包含4个分区的“用户”主题。
由于分区是基于用户标识的，因此假设具有用户标识1的消息将转到分区1，具有用户标识2的消息将转到分区2，依此类推。。
另外，假设您有4个主题的使用者。由于您有4个使用者，kafka将把每个使用者分配到一个分区。因此，在这种情况下，只要推送4条消息，它们就会立即被消费者消费。
如果主题有2个使用者而不是4个，那么每个使用者将处理2个分区，消耗的吞吐量将几乎是一半。
为了完全回答您的问题，kafka只提供了分区内消息的总顺序，而不是主题中不同分区之间的顺序。
也就是说，如果分区2中的消耗非常慢，分区4中的消耗非常快，那么用户id为4的消息将在用户id为2的消息之前被消耗。Kafka就是这样设计的。

您可以考虑使用一个字段，该字段在源处创建数据集时具有时间戳/日期。
一旦数据被消耗，您就可以将数据加载到数据库中。在将数据集用于任何用例之前，需要在数据库级别对数据进行排序。嗯，这是一种尝试，帮助你从多方面思考。
假设我们有一个消息键作为时间戳，它是在创建数据时生成的，值是实际的消息字符串。
当使用者拾取消息时，消息将写入hbase，rowkey作为kafka键，value作为kafka值。
因为hbase是一个排序Map，它以时间戳作为键，将自动按顺序对数据进行排序。然后您可以为下游应用程序提供来自hbase的数据。
这样你就不会失去Kafka的平行性。您还拥有在数据库级别处理排序和对数据执行多个处理逻辑的权限。
注意：任何分布式消息代理都不能保证整体排序。如果您坚持认为您可能需要重新考虑使用另一个消息代理，或者您需要在kafka中使用单个分区，这不是一个好主意。Kafka通过增加分区或增加消费群体来实现并行性。

好吧，这是一个老线索，但仍然相关，因此决定分享我的观点。
我觉得这个问题有点混乱。
如果需要对消息进行严格排序，则在使用消息时应保持相同的严格排序。对队列中的消息进行排序是毫无意义的，但在使用它时却毫无意义。Kafka允许两全其美。它允许在一个分区内对消息从生成到使用进行排序，同时允许多个分区之间的并行性。因此，如果你需要
主题上发布的所有事件的绝对顺序，请使用单个分区。你不会有并行性，也不需要并行性（同样，并行性和严格排序不能同时进行）。
对于多个分区和使用者，使用一致的哈希来确保需要遵循相对顺序的所有消息都到达单个分区。

传统mq的工作方式是，消息一旦被处理，就会从队列中删除。消息队列允许一组订阅者从队列的末尾提取一条消息或一批消息。队列通常允许在提取消息时执行某种级别的事务，以确保在删除消息之前执行了所需的操作，但一旦处理完消息，就会将其从队列中删除。
另一方面，使用kafka，可以将消息/事件发布到主题中，并将它们持久化。当消费者收到它们时，它们不会被移除。这允许您重放消息，但更重要的是，它允许多个使用者基于相同的消息/事件处理逻辑。
您仍然可以扩展以在同一个域中获得并行处理，但更重要的是，您可以添加基于同一事件执行不同逻辑的不同类型的使用者。换句话说，使用kafka，您可以采用一种React式的pub/sub架构。裁判：https://hackernoon.com/a-super-quick-comparison-between-kafka-and-message-queues-e69742d855a8

我决定将我的评论转移到一个单独的答案，因为我认为这样做是有意义的。
虽然约翰写的东西百分之百正确，但你可以考虑重新思考你的问题。你真的需要所有的信息来保持秩序吗？或者您是否需要特定用户id（或其他）的所有消息来保持秩序？
如果是第一个分区，那么就没有什么可以做的了，应该使用1个分区并失去所有的并行能力。
但是如果是第二种情况，您可能会考虑按某个键对消息进行分区，因此该键的所有消息都将到达一个分区（如果您调整主题大小，它们实际上可能会转到另一个分区，但情况不同），从而保证该键的所有消息都是有序的。