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

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

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

>客户端连接到邮件系统
>它订阅了邮件系统
>它获得的第一条消息是系统的完整状态
>然后,它只接收有关全局状态的变化

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

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

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

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

最佳答案 这不是消息传递域问题,而是特定用例. Pub / Sub不是为了知道有关生产者/消费者的任何状态信息而设计的,它只是代理消息.

也就是说,有一些不同的重新传递模式可以用来弥补差距(Last Image Subscription Policy等),但我会选择更简单的解决方案.此外,您可能会考虑使用像Apache Camel这样的东西坐在生产者和订阅者之间来提供这个额外的逻辑.

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

>提供REST服务,允许任何客户端拉出系统的完整状态
>为完整状态数据和增量更新数据添加递增版本号
>当客户上线时

>订阅开始获取增量更新(现在在内部排队)
>使用REST服务获取完整的系统状态
>然后,开始处理增量更新,并根据版本号忽略旧更新