消息传递系统场景

Posted 2022-11-17 JavaEdge.

2.1.1 直接从Pro传递给Con

许多消息传递系统使用Pro和Con之间的直接网络通信，而不通过中间节点：

• UDP组播广泛用于金融行业，如股票市场，低时延很重要。虽UDP本身不可靠，但应用层协议可恢复丢失的数据包（Pro必须记住它发送的数据包，以便能按需重发）。
• 无代理的消息库，如 ZeroMQ 和 nanomsg 采取类似的方法，通过 TCP 或 IP 多播实现发布 / 订阅消息传递
• 若Con在网络上公开了服务，Pro可直接发送 HTTP 或 RPC 请求将消息推送给使用者，即webhooks 背后想法，一种服务的回调 URL 被注册到另一个服务中，并且每当事件发生时都会向该 URL 发出请求。

尽管这些直接消息传递系统在设计它们的环境中运行良好，但是它们通常要求应用代码意识到消息丢失的可能性。容错程度有限：即使协议检测到并重传在网络中丢失的数据包，它们通常也只是假设生产者和消费者始终在线。

如Con脱机，则可能会丢失其不可达时发送的消息。一些协议允许生产者重试失败的消息传递，但当生产者崩溃时，它可能会丢失消息缓冲区及其本应发送的消息，这种方法可能就没用。

2.1.2 消息代理

一种广泛使用的替代方法：通过消息代理（message broker，也称为消息队列message queue）发送消息，消息代理实质上是一种针对处理消息流而优化的DB。作为服务器运行，生产者和消费者作为客户端连接到服务器。生产者将消息写入代理，消费者通过从代理读来接收消息。

将数据集中在代理，这些系统更容易容忍来来去去的客户端（连接，断开连接和崩溃），而持久性问题则转移到代理。一些消息代理只将消息保存在内存，而另一些消息代理（取决配置）将其写盘，以便在代理崩溃也不丢。针对缓慢消费者，它们通常会允许无上限的排队（而非丢弃消息或背压），尽管这种选择也可能取决配置。

排队结果是，消费者通常异步：当Pro发送消息时，通常只会等待代理确认消息已被缓存，而不等待消息被Con处理。向消费者递送消息将发生在未来某未定时间点，通常在几分之一秒内，但有时当消息堆积时会显著延迟。