我希望使用 Redis 创建一个系统，将股票报价数据发布给内部网络中的订阅者。问题是发布是不够的，因为我需要找到一种方法来实现原子的“获取快照然后订阅”机制。我对 Redis 很陌生，所以我不确定我的解决方案是“正确的方式”。
在给定的时刻，每只股票都有一本订单簿，其中最多包含 10 个出价和 10 个要价。发布者接收交换的数据，并将它们发布给订阅者。
虽然使用发布和订阅可以轻松发布订单簿中的更改，但连接的每个订阅者还需要获取当前股票订单簿的快照，然后才能订阅订单簿中的更改。
据我了解，Redis 通道从不保存信息，因此发布者除了发布更改外，还需要在哈希键（或排序集。我不确定哪个更合适）中维护完整的订单簿。
我也明白 Redis 客户端一旦订阅了第一个频道，就不能发出任何命令，除了订阅和取消订阅。
因此，一旦订阅者应用程序启动，它首先需要获取包含完整订单簿的密钥，然后订阅该订单簿中的更改。但是，这可能会导致竞争条件。在客户端获得包含当前快照的密钥之后但在它实际订阅更改之前，可以对书籍顺序进行更改，从而导致它永远不会看到的更改。
由于无法在单个连接中使用 subscribe 然后使用 get，因此客户端应用程序需要两个到 Redis 服务器的连接。在这一点上，我开始认为如果我在同一个应用程序中需要多个连接，我可能没有以正确的方式做事。无论如何，我的想法是客户端将有一个订阅连接和一个查询连接。首先，它会使用订阅连接订阅订单簿的变化，但仍然不会进入处理事件的循环。之后，它将使用查询连接来获取图书的完整快照。最后，它会进入处理事件的循环，但由于他实际上是在拍摄快照之前订阅的，因此可以保证它不会错过拍摄快照后发生的任何更改。
有没有更好的方法来实现我的目标？