事件消息概述

本节讨论了事件消息是如何通过PubSub+事件代理传输的。有关PubSub+平台中消息的更一般信息，请参见什么是消息？

主题

主题是PubSub+事件代理将事件从发布者传输到订阅者的核心。有关PubSub+主题的更一般信息，请参见理解主题。

在PubSub+中，主题遵循一个由多个级别组成的层次结构，每个级别都提供了有关事件的上下文详细信息。这个结构既描述了事件，又有效地在事件驱动系统中路由事件，并确保消费者应用程序具有选择性地只消费他们想要的事件的灵活性。

要了解构建主题架构的最佳实践，请参见主题架构最佳实践。

有关主题语法的一般信息，请参见Solace消息格式主题。

您可以在主题订阅中使用通配符来细化消息消费者接收的信息。有关更多信息，请参见主题订阅中的通配符字符。

PubSub+事件代理还有一些保留或特殊主题，用于配置一系列功能，如队列路由、消息提升和降级以及灾难恢复。有关更多信息，请参见保留主题。

直接和保证消息

PubSub+事件代理支持直接消息和保证消息。

直接消息适用于可以容忍偶尔丢失消息的高比特率或非常低延迟的消息应用程序。生产者可以将消息发布到主题，当消息被事件代理接收时，它们可以高效地交付给大量具有匹配主题订阅的客户。直接消息具有以下特点：

• 客户端直接订阅主题。
• 当客户端未连接到事件代理时，不会为客户保留消息。
• 在遇到拥塞或系统故障时，可以丢弃消息。
• 消息在交付时不进行确认。

有关更多信息，请参见直接消息。

保证消息最适合需要持久存储他们发送或打算接收的消息的应用程序。保证消息具有以下特点：

• 主题订阅与事件代理上的端点（队列或主题端点）相关联，而不是消费客户端。
• 一旦消息被事件代理确认，消息就不会丢失。
• 当消息被交付到持久端点时，它们会被保留直到被客户端消费。
• 向客户端的交付会被确认。

有关更多信息，请参见保证消息。

持久性和耐用性

尽管“持久性”和“耐用性”这两个术语是相关的，但持久性的概念适用于事件消息，而耐用性适用于端点。

持久性指的是事件消息的服务质量（QoS）。如果事件消息在到达事件代理后被放置在非易失性存储介质上，则被认为是持久的。持久消息也被称为保证消息。事件代理的数据平面会存储消息，如果消息到达时将Persistent Delivery Mode设置为Persistent，或者队列或持久主题端点订阅了主题，无论消息中的Persistent Delivery Mode标志设置如何，都会持久化消息。标记为Persistent的消息会导致在消息存储后向生产者发送确认消息。

如果事件消息以Persistent Delivery Mode设置为Direct发送，只有当消息主题被队列或持久主题端点订阅时，消息才会被放置在非易失性存储介质上。

在某些情况下，如果消息使用JMS API发布或从直接消息提升而来，消息可能具有Persistent Delivery Mode的Non-Persistent。有关更多信息，请参见主题匹配和消息传递模式。

耐用性

端点耐用性是PubSub+队列或主题端点的特性。无论消费者是否活跃，耐用端点都可操作。例如，如果事件代理失败或发生高可用性（HA）或灾难恢复（DR）故障转移，队列消息仍然可用。如果消息与耐用队列相关联，则在一般情况下被认为是持久的，因为它们无论特定客户端会话的生命周期或事件代理重启如何，都会保留在事件代理上。

临时队列不被认为是耐用的。发送到临时队列的消息会被持久化到存储上，但如果活跃的临时队列消费者解绑或断开连接，它们会被删除。因此，端点在消费者生命周期之外是不耐用的。

要了解更多关于耐用和非耐用队列的信息，请参见主题端点和队列。

消息模式

PubSub+支持一系列消息模式，以满足各种需求。常用的模式包括：

• 发布-订阅交换模式
• 请求-回复交换模式
• 竞争消费者扩展模式
• 消费者高可用性
• 分区

发布-订阅交换模式

通过发布-订阅消息传递，生产者（发布者）发送的消息可以被不同的消费者（订阅者）多次处理。基于它们定义的主题订阅，可以将发布的事件交付给多个消费者。每个消费者都收到自己的消息副本以进行处理。

请求-回复交换模式

通过请求-回复消息传递，应用程序使用单独的点对点通道实现双向通信：一个用于请求，另一个用于回复。在请求-回复模式中，应用程序既是生产者又是消费者。

竞争消费者扩展模式

竞争消费者是事件驱动架构中的一个可扩展性模式，涉及将处理事件的工作负载分配给多个相同应用程序的实例，以提高吞吐量并减少处理时间。在这种模式下，队列具有非独占访问类型，这有助于以轮询方式向所有绑定的消费者流程交付消息。当消息顺序不重要且您需要扩展消费者以跟上消息吞吐量时，通常使用此模式。

消费者高可用性

当您实现高可用性（HA）消费者扩展模式时，您有多个相同消费者应用程序的实例可用于处理事件。一个消费者实例被选为活动实例并接收所有事件，而其他实例处于待机状态。如果活动实例崩溃或下线，代理会自动选择另一个实例激活并开始向新消费者发送所有事件。只要您有一个实例连接并处理，此模式就确保事件处理继续进行。根据需要的冗余级别，此模式有时也被称为主/次或主/次/第三。

要实现此模式，队列具有独占访问类型。这种访问类型允许多个消费者连接，但事件代理只向其中之一交付事件。如果活动消费者断开连接，下一个接收事件的消费者将从等待的消费者池中随机选择。当队列中的所有消息都必须按顺序处理时，通常使用此模式。

分区

分区是事件驱动架构中的一种设计模式，它有助于在保持消息顺序的同时提高可扩展性。您有效地将事件流分割成分区，然后可以并行处理。通过分区而不是整个事件流来保持顺序。当您需要扩展消费者但同时也关心消息顺序时，通常使用此模式。

在PubSub+中，此模式使用分区队列实现。分区队列是一种非独占队列，可以同时向多个消费者交付，以实现扩展。分区队列使用分区键将入口事件分割成分区。同一分区中的所有事件始终交付给相同的消费者，从而在保持消息顺序的同时实现可扩展性。有关更多信息，请参见分区队列。