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

Question

我目前正致力于一个需要高度可扩展的社交网络应用程序。

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

例如：

• 网站上有几个区域，用户在需要保存到数据库的表单上输入信息;
• 发生数据库保存并且必须向一个或多个用户发送电子邮件通知时。

另外，对于保存方案，我想给用户提供友好的消息，让他们知道在保存过程完成后他们的数据保存在表单上，​​如果我要去pub / sub 做法。
在特定任务完成后，如何将成功/失败消息返回给用户界面？

哪些场景是pub / sub模式的理想候选者？对于基本表单数据库保存来说似乎有点过分了。

Answer 1

从您的两个场景中，后者可能是使用总线实现的候选者。规则是 - 处理越复杂/越长，同步处理时不会缩放的概率越高。有时甚至不是并发请求的数量，而是每个请求消耗的内存量。

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

这就是公共汽车发挥作用的地方。通过对它们进行排队，让你的 throtle 并发请求。您的订阅者一个接一个地接收请求并处理它们，但由于订阅者数量是固定的，您可以控制资源使用情况。

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

相反，拥有一个队列只意味着用户必须等待他们的文档稍微更长，但服务器场的响应能力已得到控制。

回答你的第二个问题：由于使用消息总线实现的处理的异步和分离特性，你通常会让UI主动询问处理是否完成。服务器不是将处理状态推送到UI，而是UI询问并询问和询问，然后突然得知处理已完成。这样可以很好地扩展，同时保持双向连接以将通知推送回客户端，在大量用户的情况下可能很昂贵。

Answer 2

我想你的问题没有明确的答案。 恕我直言，没有人可以评估设计模式的表现。也许，有人可以考虑将它与另一种设计模式进行比较，但即使这样，比较也至少是不安全的。性能与实际实现有关，实际实现可能在相同设计模式的不同实现之间变化。如果要评估软件模块的性能，则必须构建它然后对其进行概要分析。正如Steve McConell在他的legendary book中建议的那样，如果没有剖析，就不要做出关于性能的决定。

关于特定模式和您的方案，我建议避免使用它。 {<3}}通常在订阅者不希望接收所有已发布的消息时使用，而是其中一些满足某些特定条件（例如属于特定类型的消息）。因此，我不建议将它用于您的场景。

我还建议查看Publish-subscribe pattern模式。我想你可以在网上找到更多的参考资料。

希望我帮忙！