客户服务体系结构：保持客户端与内存数据同步sctructure

Question

我有一项服务可实时更新redis（快速内存数据存储）中的一组服务。 我也有一个rails连接到这个redis实例的应用程序。任务是将设定内容显示给所有客户端。请注意，根据某些客户的设置，该集合中的某些元素不应被发送给他们。

我不想在每次更新时发送整个设置内容。应该只能发送差异，我选择使用哪种方法。

实施轨道 - >客户端连接：

• 反应 - 反应听起来是一个不错的选择保持实时状态。如果我让道具实时更新，那么html将会保持最新免费。
• actioncable - 在最新的rails中有一个组件将websockets集成到rails app中。

服务 - > Redis的设置 - >轨：

• 我可以用的pub/sub Redis的功能，并写入到Redis的服务中设定发送被改变的元素/更新/在集合中删除，然后使用集合本身仅向新客户端发送数据，而现有客户端将通过pub/sub保持同步。因此，更新客户端，下面的执行：
  1. 服务是关于集中
  2. 服务更新元素添加元素的集redis的
  3. 服务发送的元素到发布/订阅队列
  4. Rails应用程序，所预订的发布/订阅队列，接收元素
  5. Rails应用程序过滤器的客户端，看看哪些应该得到更新的列表（通常情况下，这是大多数）
  6. rails应用程序广播新项目和cli经济需求使其

最重要的是，我还必须执行更改/删除的情况。 看来这种方法太复杂和低级。事情很容易失去同步，并且它们在内存中被重复数次。

• 代替的pub/sub我可以让Rails应用程序读取redis的重复设定内容和计算，如果任何改变发生。它应该是便宜的，因为redis将该集存储在内存中。如果Rails应用程序检测到更改，它会将其广播到客户端。但是，根据超时检查内存是否有变化，感觉不对。

附加信息：不会有太多的客户，也许一千。该套件将每秒更新一次，有时更多，有时更少。

什么是最好的方法来保持客户端与redis中的状态保持同步？反应用法是否合理？是否有一些本地反应实现这种“差异”模式？

Answer 1

我有一个使用React和ActionCables的应用程序。

两者在一起工作得很好。了解ActionCables的局限性（它具有比其他类似工具更低的用户限制基准）是非常重要的，但是如果您不希望成千上万的用户同时使用它，那么它工作得很好。

无论您是否使用React，我认为Flux模式在管理套接字连接状态方面有很长的路要走。 Vanilla Flux和Redux都是很棒的同伴，并且非常善于倾听来自服务器的变化，然后将这些信息传播到应用程序的相关领域。它们恰好是用于React的最重要的，但实际上你可以在任何前端框架中使用它们。