哪些用例场景最适合发布/订阅模式？ [关闭]答案

【问题标题】：Which use case scenarios are the most appropriate for the publish/subscribe pattern? [closed]哪些用例场景最适合发布/订阅模式？ [关闭]
【发布时间】：2013-12-08 12:20:50
【问题描述】：

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

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

例如：

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

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

哪些场景是发布/订阅模式的理想候选者？保存基本表单数据库似乎有点过头了。

【问题讨论】：

试试Programmers 我认为这将是更多的话题。
视情况而定。您的电子邮件通知示例就是一个很好的例子。如果您只是发送电子邮件，不妨将其添加到流程中。但是，假设您想提供不同的通知方式，例如向手机推送消息或通知页面上的用户（如果他当前已登录）。在这些情况下，您可以使用 pub/sub 来实现这些并将它们添加到系统中而无需触摸现有功能。总体而言，它只是在您需要它的领域为您提供了更多的灵活性。如果您不需要灵活性，那就是开销和矫枉过正。
我认为基本的保存操作会是矫枉过正是否正确。

标签： c# design-patterns scalability social-networking publish-subscribe

【解决方案1】：

从您的两种情况来看，后者可能是用总线实现的候选者。规则是 - 处理时间越复杂/时间越长，同步处理时它不会扩展的可能性就越大。有时甚至不是并发请求的数量，而是每个请求消耗的内存量。

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

这就是公共汽车发挥作用的地方。 Bus 让您通过排队来限制并发请求。您的订阅者接受请求并一一处理，但由于订阅者的数量是固定的，因此您可以控制资源的使用。

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

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

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

【讨论】：

【解决方案2】：

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

关于特定模式和您的场景，我建议避免使用它。 Publish-subscribe pattern 通常用于订阅者不想接收所有发布的消息，而是希望其中一些满足某些特定标准（例如，属于特定类型的消息）。因此，我不建议将它用于您的场景。

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

希望我能帮上忙！

【讨论】：