我想使用 Redis 创建一个系统，将股票报价数据发布给内部网络中的订阅者。问题是发布是不够的，因为我需要找到一种方法来实现原子“获取快照然后订阅”机制。我是 Redis 的新手，所以我不确定我的解决方案是“正确的方法”。
在给定的时刻，每只股票都有一个订单簿，其中最多包含 10 个出价和 10 个要价。发布者接收交换数据，并应将其发布给订阅者。
虽然可以使用发布和订阅轻松地发布订单簿中的更改，但每个连接的订阅者还需要获取股票当前订单簿的快照，然后才能订阅订单簿中的更改。
据我了解，Redis channel 从不保存信息，因此发布者除了发布更改外，还需要在哈希键(或排序集。我不确定哪个更合适)中维护完整的订单簿。
我还了解到，Redis 客户端一旦订阅了第一个 channel ，就无法发出除订阅和取消订阅之外的任何命令。
因此，一旦订阅者应用程序启动，它首先需要获取包含完整订单簿的 key ，然后订阅该订单簿中的更改。但是，这可能会导致竞争条件。可以在客户端获得包含当前快照的 key 之后但在实际订阅更改之前更改图书顺序，从而导致它永远看不到更改。
由于不可能在单个连接中使用订阅然后使用获取，因此客户端应用程序需要两个到 Redis 服务器的连接。在这一点上，我开始思考，如果我在同一个应用程序中需要多个连接，我可能没有以正确的方式做事。无论如何，我的想法是客户端将有一个订阅连接和一个查询连接。首先，它会使用订阅连接来订阅订单簿的变化，但仍然不会进入处理事件的循环。之后，它将使用查询连接获取本书的完整快照。最后会进入处理事件的循环，但由于他实际是在抓快照前订阅的，所以保证不会漏掉抓快照后发生的任何变化。
有没有更好的方法来实现我的目标？
最佳答案
我希望你已经找到了自己的方式，如果还没有，我们将提出个人建议:
如果您在 javascript 领域，我建议您看一下 Meteor.js，它们确实以某种方式实现了您想要实现的目标，使用默认设置，您最终将写入 mongodb 以便“更新”GUI “最终用户”。
无论如何，您可能有兴趣阅读有关 meteor 的 ddp 协议(protocol)如何工作的信息:https://meteorhacks.com/introduction-to-ddp/和 https://www.meteor.com/ddp
关于redis - 在 Redis 中实现 "Snapshot and Subscribe"，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/19829557/