【问题标题】:Pub/sub while maintaining an access to the full state of the system发布/订阅,同时保持对系统完整状态的访问
【发布时间】:2012-05-04 02:56:36
【问题描述】:

我有一个维护应用程序全局状态的服务器。

客户端可以连接到服务器并获取有关全局状态变化的消息(发布/订阅机制以便服务器广播信息)。

但是,在启动时,客户端根本没有关于全局状态的信息,他们需要它。我想要的是对于订阅系统的任何新客户端,第一条通知消息是应用程序的完整状态。然后他们只收到有关此状态的更改:

  1. 客户端连接到消息系统
  2. 它订阅消息系统
  3. 它收到的第一条消息是系统的完整状态
  4. 那么,它只接收有关全局状态的更改

这个想法类似于多人游戏,新玩家必须首先获得游戏的完整状态,然后只发送游戏中的变化。

像 ActiveMQ 或 Stomp 这样的消息传递系统可以满足我的需求,因为它们是多语言的,并且可以与多个传输层一起使用。但是没有发送完整状态的概念(或以连贯的方式累积最后的变化)。

当然,我可以轻松地以静态方式提供此状态(首先我获得完整状态,然后订阅发布/订阅系统),但是我必须注意同时可能发生的变化(我是在处理完整状态时丢失一些更改?在我刚刚检索到的全局状态中是否已经考虑了此更改?...)。但是我失去了 Stomp 和 ActiveMQ 已经提供的多语言/多传输方面。

是否有一些现有的库/工具可以做到这一点? ActiveMQ 的某种扩展?类似于 Stomp 的东西?还是需要手工制作?

【问题讨论】:

    标签: client-server activemq messaging publish-subscribe stomp


    【解决方案1】:

    这不是消息传递域问题,而是特定用例。 Pub/Sub 并非旨在了解有关生产者/消费者的任何状态信息,它只是代理消息。

    也就是说,有一些不同的重新交付模式可用于缩小差距(Last Image Subscription Policy 等),但我会选择更简单的解决方案。此外,您可能会考虑使用 Apache Camel 之类的东西在生产者和订阅者之间提供这种额外的逻辑..

    正如您所说,棘手的部分是使增量更新与检索到的完整系统映像保持同步。最重要的是,这就是我要做的......

    • 提供 REST 服务以允许任何客户端提取系统的完整状态
    • 为完整状态数据和增量更新数据添加递增的版本号
    • 客户端上线时
      • 订阅以开始获取增量更新(暂时在内部排队)
      • 使用 REST 服务获取完整的系统状态
      • 然后,开始处理增量更新并根据版本号忽略旧的更新

    【讨论】:

    • 是的,这也是我默认的做法。为了以防万一,我还要等几天才能得到其他答案。
    • 酷...我很好奇是否有人也知道更清洁的方法...好问题
    猜你喜欢
    • 2019-09-26
    • 1970-01-01
    • 1970-01-01
    • 2015-10-20
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2018-07-29
    • 1970-01-01
    相关资源
    最近更新 更多