我已经阅读了几十篇关于Kafka消息排序的文章，但仍然没有看到一个开箱即用的解决方案来满足我的常见需求-a用顺序递增的ID发布消息，并以相同的顺序使用它们。
Kafka在一个分区内保持消息顺序。但是，什么企业级解决方案会对关键数据使用单个分区（单点数据丢失故障、没有并行性时吞吐量降低等）呢？因此，挑战在于如何在多分区主题中按顺序使用消息。
在进行区块链分析时，我们从区块链节点上获取按顺序递增的数据块，然后将它们发布到我们的Kafka主题中。Key =块编号，Value =块数据，块编号从0开始，永远递增1。
我们的分析代码需要按顺序使用这些消息（区块1、区块2、区块3等），如果在区块2中创建了一个智能合约，然后在区块3中发生了一个交易，那么如果我们在区块2之前处理区块3，我们的分析代码就会失败（例如，“找不到合约错误”）。
关于我们的用例的更多信息。
1.区块数据永远不会被清除，它将增长到几TB，包含数百万条信息，虽然大多数消费者不会直接使用它，但它仍然是区块链的外链副本，可以满足我们软件的未来需求。
1.我们有一个SQL数据库表，其中存储了关于我们分析了多少区块链的状态信息（例如，最高区块号是25，555，555）。
为了保证排序，大多数文章推荐Kafka Streams和KTable。如果我们使用内存中的KTable，那么我们将面临重大挑战（无法在内存中存储TB的数据，启动时重建KTable将花费数天，等等）。
如果我们使用持久化的KTable，那么我们的磁盘使用量就会膨胀（在源主题和KTable之间复制了几TB的数据）。
我们可以创建一个次要的“可操作的”单分区主题（数据保留时间相对较短），将数据按顺序流传输到该主题，然后让我们的消费者从该主题中提取数据，但这与开箱即用完全相反，我们希望避免为数百个区块链和消息传递需求这样做，因为这将导致管理崩溃。
这似乎是自Kafka诞生以来数千家公司的技术需求（就像消息队列几十年来所做的那样）。难道没有现成的解决方案让KafkaListener根据数字Key（在多分区主题中）按顺序接收消息吗？