直接与最终用户客户端一起使用消息代理 [英] Using a message broker with end user clients directly
问题描述
我想找到一种方法，以从服务器向同一终端的多个最终用户客户端实施推送消息。
I want to find a way to implement push messages from a server to multiple end user clients with the same message.
我发现的一种选择是使用消息代理并使用它来实现 pub / sub 模式。在这种情况下，我不确定应该被认为是消费者。
One of the options I found was to use a message broker and use it to implement the pub/sub pattern. What I'm not sure about is what supposed to be considered a consumer in such a scenario.
我认为使用消息代理时的一般体系结构是：
What I thought that the general architecture is when using a message broker is:
最终用户客户端< ---->消息代理< --->服务器（客户端和服务器也可以在与主题消息无关的事情上互相交谈）
End user clients <----> Message broker <---> Server (The clients and server can also speak to one another on things that are not related to topic messages)
我至少认为应该发生的过程是这样的：
And the process I at least thought that is supposed to happen is this:
1）最终用户客户端通过直接向消息发送初始消息来注册到特定主题
1) The end user client registers to a specific topic by sending an initial message directly to the message broker.
2）服务器收到有关他希望每个最终用户都能得到的主题的消息，因此它向该主题添加了一条消息。
2) The server got a message about a topic which he wants every end user will get, so it adds a message to the topic.
3）消息代理立即将消息自动发送给所有最终用户 ，而无需使用SignalR，Pusher等其他推送消息服务。它们的用法意味着它可能在后台使用它，但开发人员实际上并未对消息的发送进行编程）。
3) The message broker instantly sends the message to all the end users by itself without the usage of other push message services like SignalR, Pusher etc. (without the usage of them meaning that it might use it behind the scene, but the developer doesn't actually program the sending of the messages).
之后，我听说用户不应该是最终用户客户端，而是其他服务器？
After that I heard that the consumer is not supposed to be end user clients, but other servers?
我对流程的描述正确吗？还是其他东西？
Is my description of the process correct? Or is it something else?
推荐答案
发布/订阅模式听起来确实像您想要的。但是，有些地方需要澄清。
The pub/sub pattern does sound like what you want. However, there are some points which need clarification.
您需要清除的第一个概念是客户端和服务器与消息代理进行交互的概念。从消息代理一切的角度来看，它是一个客户端。通常，客户端可以生成消息和/或使用消息；而已。您的应用程序是否以整体架构中的其他身份充当客户端或服务器，这与消息代理有关，这无关紧要。
The first concept you need to clear up is that of a client and a server interacting with the message broker. From the perspective of the message broker everything that connects to it is a client. In general, the clients can produce messages and/or consume messages; that's it. Whether or not your applications are acting as clients or servers in some other capacity in your overall architecture is irrelevant as it relates to the message broker.
此处是使用您的三步过程：
Here is a clarified summary using your 3-step process:
- 一个或多个客户针对他们关心的主题创建了一个消费者（有时称为订户）。
- 一个或多个客户端针对该主题生成消息，例如，将某些事件通知消费者/订户。
- 经纪人调度消息每个注册用户/订户。
所有这些工作都是通过消息传递客户端实现专门完成的。换句话说，客户端应用程序仅需要使用消息传递客户端实现（例如AMQP客户端，STOMP客户端等）。无论是通过某种异步侦听器还是通过同步方法调用，代理本身都会将实际消息分发给使用者/订户，以接收消息。这被认为是基本的消息传递功能。客户端应用程序无需使用任何其他类型的库（例如SignalR或Pusher）即可从代理获取消息或将消息从代理推送至客户端。
All this work is done exclusively via the messaging client implementation. In other words, the client applications only need to use the messaging client implementation (e.g. AMQP client, STOMP client, etc.). The broker itself will dispatch the actual message to the consumers/subscribers whether that be through some kind of asynchronous "listener" or a synchronous method invocation to receive the message. This is considered basic messaging functionality. There is no need for the client application to use any kind of additional library (e.g. SignalR or Pusher) to fetch the message from the broker or to push the message from the broker to the client.
这篇关于直接与最终用户客户端一起使用消息代理的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
