在多实例环境中设置TTL并在TTL激活后处理数据的机制和选项

Question

我们在 SpringBoot 应用程序中有一个场景，其中请求者应用程序发送一个请求事件（例如报价请求），该事件可以由多个响应应用程序回答。一段时间后，基于响应（报价），请求者需要确定最佳选择，然后将实际请求（例如订单）发送到特定的响应者应用程序。步骤如下：

1. 请求者应用程序发送事件以获取报价。
2. 响应的应用程序发送带有引号的响应。
3. 定期请求后，请求者需要找到最佳报价并将请求发送给特定的响应者。

我们已经将 RabbitMQ 和 Redis 用于其他任务。因此，我们计划将 RabbitMQ用于报价请求/响应事件，并考虑使用 Redis来存储报价响应，直到确定最佳报价为止。

以下是我们正在考虑的两个选项：

1。使用 Redis ：在发送报价并侦听到期事件时创建带有TTL的条目。到期后，检查答案并找到最佳答案。 问题是我们有多个实例，以及如何确保只有一个实例处理到期事件。 另外，我们的Redis有多个节点，这似乎是到期和事件的问题。

1. 使用 RabbitMQ ：另一种选择是将消息与初始报价请求一起发送给延迟交换。请求者本身会侦听该消息，并且当最终读取了来自延迟交换的消息时，便可以识别并处理最佳报价。 问题是我们可能产生了大约1万条消息，这可能会减慢处理速度。 （分组将确保仅一个实例使用该消息） 延迟交换生产实施的可靠性如何？

想检查一下关于以上两种方法的一些想法，一些利弊，以及更好的方法或替代方法吗？