我们目前正在为注册的客户端应用程序开发公共数据订阅Web服务,目前这些客户端通过访问令牌使用我们的api数据.

因此,对于数据订阅端点,我们一直在考虑不同的方法,我们当前的方法基于简单的HTTP Posts,每隔几秒钟就会为客户订阅特定对象中的特定更改(仅当明显发生更改时).

EX：用户创建一个新文档,订阅该特定用户订阅的所有应用程序(UserUploadDoc)将通过POST通知.这很容易实现.

但后来我们开始调查消息传递服务,而ZeroMQ似乎非常有能力.

我可以很容易地想象一个简单的消息服务工作方式与医院PA类似,我们只是广播一些东西,有人听它得到它,

就像护士Sally在幼儿园打电话一样,护士Sally可以来到幼儿园,只有她会收到完整的信息.

请确认我对此方法完全错误,并且应该坚持使用HTTP Posts的痛苦！

解决方法:

消息队列对于这种情况来说是个好主意,因为它可以增加有保证的传递以及出现问题时的审计跟踪.例如,您有可能找出特定客户端是否无法在特定时间获取消息,或者回放消息队列并重播它以测试客户端.它确实增加了额外的开销,正如其他帖子所指出的那样,所以这实际上取决于在特定情况下这种权衡是否值得的成本效益分析.

一般来说,如果由于任何原因导致消息失败将导致严重问题(在医院,我怀疑它会),那么你应该有一个消息代理.如果您没有通过POST使用push,那么可能由客户端决定是否继续轮询服务器的REST接口,直到它获得更新,因此这无关紧要,因为用户会看到“无法更新”消息并可能采取措施.只要你很高兴ZeroMQ能够轻松/便宜地维护,我会说它去吧.