消息传递模式

PubSub+ 事件代理支持以下消息传递模式：

最多一次传递：PubSub+ 事件代理提供两种选择：直接（Direct）和非持久化（Non-Persistent）消息传递。非持久化消息传递模式用于满足 JMS 规范要求。对于 Solace 消息传递 API，非持久化消息与持久化消息具有相同的功能。
至少一次传递：PubSub+ 事件代理通过持久化（保证）消息传递（通常称为保证消息传递）来实现此功能。
事务性传递：PubSub+ 事件代理支持基于会话和 XA 事务。

直接消息传递

直接消息传递适用于能够容忍偶尔消息丢失的高速应用程序。生产者可以将消息发布到主题，当事件代理接收到这些消息时，会将它们传递给具有匹配主题订阅的消费者。直接消息不会在事件代理上为消费客户端进行缓冲（换句话说，它们不会被持久化），并且在接收时也不会被确认。

持久化或保证消息传递是以下两者的结合：发送持久化消息并进行适当的发布确认处理，以及至少一次传递。同样重要的是，保证消息永远不会丢失。保证消息传递有两个方面：发布保证消息和接收保证消息。

发布保证消息：当使用持久化消息传递向事件代理发送消息时，客户端可以向队列或主题发布消息。当消息被事件代理接收时，它们会在被确认回生产者之前保存在事件代理的消息缓冲区中——即它们被持久化。确认是向发布者表明事件代理已接受消息且不会丢失。
接收保证消息：消息会被传递给绑定到已接收保证消息的端点的消费者。这些消息会在事件代理上持久化，直到它们过期或消费客户端确认消息，表示已被消费。

非持久化消息传递模式用于满足 JMS 规范要求。它也用于消息提升和降级，这在“消息提升和降级”部分有解释。只有 JMS 客户端应用程序在发布时才应直接使用此模式。

在前面关于直接和持久化（保证）消息传递的讨论中，生产者和消费者都使用相同的消息传递模式。然而，生产者和消费者也可以使用不同的消息传递模式，从而形成直接和持久化消息传递的混合，这是通过消息提升和降级来实现的。

消息提升和降级可能会给您的部署带来一些潜在的缺点。在决定实现此功能之前，请仔细考虑以下限制：

消息提升不能保证无损失。直接消息发布者发送消息的速度可能比保证消息传递路径处理消息的速度快，并且它没有与保证发布者相同的背压机制。在这种情况下，事件代理会积极丢弃提升路径上的消息以保护保证消息传递路径。
消息提升可能会导致资源问题。因为直接消息发布者发送消息的速度可能比保证消息客户端消费消息的速度快，所以事件代理上为队列分配的磁盘空间可能会很快被消耗。
高频率的消息提升可能会影响保证消息传递的延迟。
消息降级可能会导致重复消息。如果发布应用程序没有收到事件代理的确认，消息将被重新传输。事件代理为保证消息订阅者内置了防止这种重传的机制，但直接消息订阅者会收到额外的副本。
消息提升：消息提升是指生产者发送直接消息，而消费者从保证消息端点接收这些消息的情况。在这种情况下，消费者将接收非持久化消息。

这是在有实时发布者发送事件且该发布者绝不能受到背压的应用程序中的典型场景。然而，同时，有些消费者希望以最容错、持久的方式接收数据。在这种场景下，消费者可以使用带有映射主题的队列端点接收事件。如果消费者应用程序离线，消息将在队列端点累积。如果消费者应用程序离线或速度较慢，它不会错过消息。

消息降级：消息降级是指生产者发送持久化消息，而有些消费者希望接收这些消息但可以容忍消息丢失的情况。这些消费者可以添加与这些消息匹配的主题订阅，并以直接消息的形式实时接收它们。这些消费者不会对发布者应用程序产生背压，如果它们离线，这些消费者只会错过消息。总体而言，生产者应用程序正在发送关键任务数据，但此数据的一些消费者并非关键任务，并且绝不应允许它们影响发布者。

从消费者的角度来看，确保完全保证消息传递的唯一方法是从具有持久化传递模式的端点接收消息。这意味着消息是持久化发送的，并在保证消息端点上接收。所有其他组合都是最多一次消息传递的示例，消费者将以直接或非持久化消息的形式接收它们。

下表概述了 PubSub+ 事件代理中的消息提升和降级情况。

不同的协议和 API 使用不同的术语来描述传递模式。下表总结了事件代理支持的各种协议中的术语。

消息 QoS	Solace API	JMS	MQTT	AMQP	Solace REST
最多一次传递	直接（默认）	非持久化	QoS 0（默认）	仅发布者直接（不支持直接订阅者）	直接
至少一次传递	持久化	持久化	QoS 1	持久化	持久化（默认）
事务性	基于会话	会话 + XA	无	无	无