发布/订阅/请求交换大型，复杂和机密数据？

Question

我正在开展一个网站需要与其他系统交换复杂和机密（以及加密）数据的项目。数据包括个人信息，技术图纸，公共文件等。

我们宁愿避免依赖系统的请求 - 回复模式（并且有很多），因为这会产生大量的空流量。

另一方面，我不确定纯粹的发布者/订阅者模式是否合适 - 主要是因为要交换的数据的复杂和庞大的性质。

出于这个原因，我们讨论了“发布/订阅/请求”解决方案的可能性。发布/订阅部分将向依赖系统发布消息，即可以提取某些内容。然后，通过旧式请求 - 回复操作来获取实际内容。

这听起来怎么样？

此致 的Morten

Answer 1

如果系统始终在线，则听起来良好。

您可能希望查看PubSubHubbub，因为： 1.不解决已经解决的问题2.它是可扩展的，代表了一个很好的关注点分离。

涉及3方：

1. 出版商（发布内容）
2. 订阅者（对某些出版物感兴趣）
3. 枢纽（调解和摆脱'民意调查'）

它的工作方式如下：

1. 订阅者使用Hub注册他们对URL的兴趣并提供回调URL。
2. 发布商，在发布内容时通知中心。
3. 集线器获取“delta”并将其推送给感兴趣的订阅者。

协议本身是Atom的扩展，但它似乎符合您的要求，例如新的Atom'内容'可以是包含新发布文档的URL的项目（可以单独下载）。

新/修改过的文件=＆gt; Feed中新增/修改的项目，包含要获取的网址=＆gt; Hub =＆gt;订阅者=＆gt;从Publisher

中提取文档

Answer 2

我对此没有很好的体验，但是消息队列应该可以帮助您完成所需的工作。我正在使用这样的系统，同时从后端管理向多个前端客户端发布数据。

如果客户端处于关闭状态，则不会消耗数据，并且服务器不会收到对所接收数据的确认。一旦客户端重新联机，他就会消耗数据，并且在队列清除后仍然会收听更多消息。并且发布者收到了消费数据的确认。通过这种方式，我们可以识别并通知接收端有问题的人作为奖励。你可以这样做吗？

Answer 3

如果从属系统始终在线，则此方法有效 - 您无法向在晚上/周末关闭的PC发送消息。

因此，如果客户端是全天候运行的服务器，则可行。否则，尝试这种方法：

1. 让客户注册
2. 当新文档进入时，在数据库中添加“客户端X需要查看此内容”的条目
3. 当客户端连接时，将所有条目发送给他们。
4. 当客户端成功下载文档时，请删除“客户端X需要查看此内容”条目。这使得工作台变小了。

这有几个好处：

1. 客户不需要全天候运行
2. 只有在客户端看到文档后才会删除该标志（因此不会丢失任何更新）。
3. 您有一个地方可以看到哪个客户从不提取文件。一个简单的select client, count(*) group by client having count(*) > 10会告诉您有关问题的信息。
4. 大多数客户都会及时获取数据，因此工作表将保持较小。这意味着当你必须收集“现在的”数据时，开销很小。

编辑离线订阅者的问题是他们不知道他们遗漏了什么。因此发送方需要跟踪失败的推/拉请求。这意味着您必须实现我建议的伪代码，以确保可以恢复断开的连接。