哪些用例场景最适合发布/订阅模式？

Question

我目前正在开发一个需要高度可扩展的社交网络应用程序。

我一直在阅读有关发布/订阅模式（消息总线）的内容，并且正在努力理解正确的用例场景 -什么时候这是合适的，什么时候这是过度的？

例如：

另外，对于保存场景，如果我要采用发布/订阅方法，我想向用户提供友好的消息，让他们知道在保存过程完成后他们的数据已保存在表单上。
完成特定任务后，如何将成功/失败消息返回到 UI？

哪些场景是发布/订阅模式的理想选择？对于基本表单数据库保存来说，这似乎有点过分了。

Answer 1

从您的两个场景来看，后者可能是通过总线实现的。规则是 - 处理时间越复杂/越长，同步处理时无法扩展的可能性就越高。有时甚至不是并发请求数量的问题，而是每个请求消耗的内存量的问题。

假设您的服务器有 8GB 内存，并且有 10 个并发用户，每个用户占用 50 MB RAM。您的服务器可以轻松处理此问题。然而，突然间，当更多用户到来时，处理时间不会线性扩展。这是因为并发请求将涉及虚拟内存，虚拟内存比物理内存慢得多。

这就是巴士发挥作用的地方。总线让您可以通过对并发请求进行排队来限制并发请求。您的订阅者接收请求并一一处理它们，但由于订阅者的数量是固定的，因此您可以控制资源使用情况。

发邮件，还有什么？好吧，例如，我们对涉及报告/文档生成的所有请求进行排队。我们观察到，一些特定的文档是在很短的特定时间跨度内生成的（例如：每个月末的会计报告），并且由于处理大量数据，我们的服务器通常会完全瘫痪。

相反，拥有队列仅意味着用户必须等待文档更长的时间，但服务器场的响应能力是可控的。

回答你的第二个问题：由于使用消息总线实现的处理具有异步和分离的性质，你通常让 UI 主动询问处理是否完成。不是服务器将处理状态推送到 UI，而是 UI 询问、询问、询问，然后突然得知处理已完成。这种方式可以很好地扩展，同时保持双向连接以将通知推送回客户端，如果用户数量较多，则成本可能会很高。