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

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

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

例如：

• 网站有几个区域，用户可以在其中输入需要保存到数据库的表单信息
• 当数据库保存时，必须向一个或多个用户发送电子邮件通知

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

---

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

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

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

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

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

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

---

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

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

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

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

---

希望我能帮忙

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