我想找到一种方法，以相同的消息从服务器向多个最终用户客户端实施推送消息。
我发现的一个选择是使用message broker并使用它来实现pub/sub模式。我不确定在这种情况下应该被认为是消费者。
我认为使用消息代理时的一般体系结构是：
最终用户客户端消息代理服务器（客户端和服务器也可以在与主题消息无关的事情上互相交谈）
而且我至少认为应该发生的过程是这样：
1）最终用户客户端通过将初始消息直接发送到消息代理来注册到特定主题。
2）服务器收到有关他希望每个最终用户都能得到的主题的消息，因此它将消息添加到该主题。
3）消息代理将消息立即发送给所有最终用户其本身，而无需使用诸如SignalR，Pusher等的其他推送消息服务（不使用它们，这意味着它可能会在场景，但开发人员实际上并未编程消息的发送）。
此后，我听说使用者不应该是最终用户客户端，而是其他服务器？
我对流程的描述正确吗？还是其他？
发布/订阅模式听起来确实像您想要的。但是，有些地方需要澄清。
您需要清除的第一个概念是客户端和服务器与消息代理进行交互的概念。从消息代理everything的角度来看，它是一个客户端。通常，客户端可以生成消息和/或使用消息；而已。您的应用程序是否以整体架构中的其他身份充当客户端或服务器，这与消息代理有关，这无关紧要。
以下是使用三步过程的清晰摘要：
所有这些工作完全通过消息传递客户端实现来完成。换句话说，客户端应用程序仅需要使用消息传递客户端实现（例如AMQP客户端，STOMP客户端等）。无论是通过某种异步“侦听器”还是通过同步方法调用，代理本身都会将实际消息分发给使用者/订户，以接收消息。这被认为是基本的消息传递功能。客户端应用程序无需使用任何其他类型的库（例如SignalR或Pusher）即可从代理获取消息或将消息从代理推送至客户端。