我想以发布订阅的方式在应用程序之间传递数据。数据产生的速度可能比消耗的速度快得多，而且消息会丢失，这不是问题。想象一个快速传感器和一个慢速传感器数据处理器。为此，我使用 redis pub/sub 并编写了一个类作为订阅者，接收每条消息并将其放入缓冲区。当“真实”函数请求消息时，缓冲区会在新消息进入或无效时被覆盖。因此，当我问这个类时，我立即得到了响应（提示我的函数比传入的数据慢）或者我必须等待（提示我的函数比数据快）。
这对于数据快速传入的情况非常有效。但对于其中涉及在相对较少的数据，让我们说每五秒钟，但这不是工作：想象我的消费者被轻微推出后生产者，第一消息丢失和我的消费者需要等待将近五秒钟，直到它可以开始工作.
我想我必须用Redis工具来解决这个问题。而不是pub/sub，我可以简单地使用get/set方法，从而将缓存功能直接放入 Redis 中。但是，我的消费者将不得不轮询数据库，而不是我目前拥有的事件魔法。密钥可能看起来像“key:timestamp”，我的消费者现在必须get key:*永久比较时间戳，我认为这会导致大量负载。自然没有睡眠的可能性，因为虽然我不关心丢失的消息（我无能为力），但我确实关心延迟。
是否有人将 Redis 用于类似的事情，并且可以给我一些有关如何巧妙使用 Redis 工具和数据结构的提示？
编辑
理想情况下，我的程序流程如下所示：
key从 Redis 中检索key。通过写这篇文章，一个想法出现了：发布者不仅发布message主题key，而且还发布set key message. 这样，应用程序最初可以get，然后subscribe。
好主意还是不是真的？
密钥空间通知正是我在这里所需要的。Redis 作为信息的主要来源，我的客户端订阅了keyspace 通知，它通知订阅者有关影响特定键的事件。现在，在我的客户端的异步部分，我订阅了有关我感兴趣的密钥的通知。这些通知设置了一个key_has_updates标志。当我需要该值时，我get会从 Redis 中提取该值并取消设置该标志。使用未设置的标志，我知道服务器上没有该键的新值。如果没有键空间通知，这将是我需要轮询服务器的部分。优点是我可以使用各种数据结构，不仅是pub/sub机制，而且一个错过第一个事件的慢连接器总是能够get初始值，它pub/sib会丢失。
当我需要该值时，我从 Redis 获取该值并将标志设置为 false。