使用kafka和键值存储的请求-响应

Question

TLDR：有一个请求/响应模式。目前，请求是通过激活队列完成的，响应是通过memcache键值存储完成的（由前端轮询）。出于各种原因，想转移到kafka，想知道我们是否可以重新构建响应路径，以不使用memcach。

我试图理解什么是针对以下问题的最佳实践系统设计。

我们有一个前端，可以生成需要大量处理的请求。应用程序需要响应才能升级。有时，我们需要撤消/后退（这会使您回到以前的状态）。有一组后端可以执行繁重的处理步骤。

在我们当前的设置中，前端将请求推入队列（当前为activemq），后端尽可能处理队列中的项目，并将结果存储在键值存储（memcached）中，其中键是队列中消息的UUID（它本身是唯一会话id非唯一步骤id）。前端正在轮询存储以获取消息的UUID。这样做的好处是前端可能会失去连接/etc，但只要会话id被保留，我们就可以ping键值存储以获得所需的结果。我们有时还需要向后移动/撤消操作，并且可以在键值存储中返回结果（因为每个步骤都有自己的UUID，并且所有UUID都是已知的）。

然而，在未来，我们希望能够至少部分通过队列进行响应，这样我们就可以拥有一些分析工具作为请求和响应的消费者。“最小的改变”是将响应生产者推到队列中，并将memcached作为消费者之一。但也许有更好的办法。我们也在考虑从activemq切换到Kafka，因为这将给我们可重放性（但我们没有Kafka的经验）。

看看Kafka，它看起来像是要获取一条特定的消息，您需要扫描整个分区，有没有更简单的方法来检索特定的消息？我们是否为每个互动序列生成一个主题？如果我们想重播，但不知道偏移量，我们有什么办法（除了浏览很多信息）？我们的负载非常小（每天大约有1百万条消息），所以我想什么都可以，但最好的做法是什么（臭名昭著的，如果我们扩展呢）？

Answer 1

正如我理解你的用例，你没有一个有效的方法通过推送向应用程序传递响应，这就是为什么你让应用程序通过id（key）来获取响应。您可以切换出各种组件，例如：ActiveMQ为Kafka，memcache为任何其他KV存储，但最终，如果您的约束是这样的应用程序需要从服务器拉的结果，你将始终不得不消耗异步传输形式的响应，并使它们在服务器上可用。例如，如果您切换到Kafka，您可以在Kafka Streams中将您的消费者实现为[全局]KTable，并以这种方式提供响应，但这仍然只是一个带有额外步骤的KV商店。没有好的方法直接从Kafka主题获得特定的消息/偏移量，这不是它的真正用途。

在不了解更多细节的情况下，将异步传输组件（ActiveMQ、Kakfa等）与服务组件分开似乎是明智的，以便能够分别扩展或交换它们。例如，如果扩展到不再适合单个memcached实例的内存的大小，则可以直接迁移到任意数量的分布式KV存储，如Redis、Couchbase、DynamoDB等。