事件流图
PubSub+根据事件从生产者到消费者移动时所需的服务质量（QoS）（由生产者定义），将传入事件分为两个不同的流。这些非持久事件流和持久事件流使用不同的路径处理事件。以下部分展示了事件的处理过程。
非持久事件流
非持久事件是短暂的。这些事件为消费者提供了一种QoS，其中消息丢失是可以接受的，并使用一种设计模式，即消费者仅从连接开始时接收消息。这允许极高的吞吐量和超低延迟，作为与持久性权衡的结果。这种QoS也常用于市场数据等应用程序中的请求-回复或发布-订阅的消息交换模式。
消息到达锚
当事件消息到 达代理，并且Delivery Mode设置为Direct时，消息会被放置在非持久事件流的尾部。
消费消息锚
非持久消费者根据订阅主题吸引消息，从非持久事件流中接收消息。当新的事件消息到达代理时，如果它们与客户端的订阅请求相符，它们会被放置在消费者的出口队列中。
消息优先级锚
每个Direct消息都被分配了优先级。消费者的出口队列确保更高优先级的Direct消息在较低优先级之前处理。相同优先级的消息按照它们到达代理的顺序处理。
非持久事件处理锚
在下图中，您可以跟踪非持久事件是如何被PubSub+事件代理处理的。
这个过程的详细步骤（对应图中的数字）如下：
- 消息生产者将事件消息发送到事件代理，事件流消费并持久化消息。更多信息，请参见发布保证消息。
- 消息到达非持久事件流会导致数据平面确定哪些非持久消费者对消息感兴趣。
- 消息的引用被移动到所有订阅主题与消息主题匹配的消费者适当的消费者出口队列中。根据消息的优先级，消息随后在TCP中排队等待发送给适当的消费者。更多信息，请参见客户端出口队列结构概览。
- 一旦所有对同一主题消息感兴趣的消费者，以及它们的出口队列调度器将消息移动到TCP输出队列，消息就从非持久事件流中删除。更多信息，请参见直接消息。
要了解更多涉及的组件信息，请参阅以下内容：
- 非持久生产者：关于发布直接消息的进一步讨论。
- 主题：了解主题在生产者到消费者的消息流中扮演的角色。
- 客户端出口队列：描述出口队列如何管理不同优先级的消息。
- 非持久消费者：了解更多关于使用消息传递API接收和管理直接消息的信息。
针对传入TCP事件的数据平面任务
所有消息通过自定义入口TCP缓冲区进入Solace PubSub+代理。新的TCP事件消息的到来导致数据平面将TCP数据移动到非持久事件流以进行进一步处理。但需要注意的是，只有在消息通过入口ACL处理后，它们才会被移动到事件流中。
非持久事件流中的消息是短暂的，消息丢弃是可以接受的。包括标记为Persistent Delivery Mode设置为Persistent或Direct的消息在内的所有消息，在通过TCP/IP到达时首先被放入非持久事件流。数据平面会立即将标记为Direct的消息移动到有匹配主题订阅的消费者的出口队列。
标记为Persistent的消息会立即被放入持久事件流。如果持久模式消息在被处理进持久事件流之前被丢弃，生产者API确保重新传输给代理，并且持久事件流将自动丢弃重新传输的重复项。
数据平面对通过TCP到达的消息执行的操作锚
一旦消息通过入口ACL检查，它们就被放入非持久事件流，并由数据平面进一步处理，如下：
- 升级
一些消息可能到达时Persistent Delivery Mode设置为Direct，但队列可能有针对这些消息的主题订阅。从队列订阅的主题消息被提升为Persistent，并移动到持久事件流，但不会向生产者发送ACK。
有关升级的更多信息，请参阅消息升级和降级。
- 降级
一些消息可能到达非持久事件队列，其Persistent Delivery Mode设置为Persistent。然而，可能有主题订阅者希望在消息被移动到持久事件流的同时接收相同的消息。这条消息被降级为Direct，直接发送到消费者出口队列，为不需要保证交付的消费者提供超低延迟和高吞吐量处理。
有关降级的更多信息，也请参阅消息升级和降级。
- 优先级
根据生产者的指示，消息被放入三个消费者出口队列优先级流中的一个。
有关更多信息，请参阅客户端出口队列结构概览。
- 共享订阅
消息可以以轮询方式分发给一组主题消费者，以提供类似于非独占队列处理的负载均衡。
更多信息，请参阅共享订阅。
- 持久消息移动到持久事件流
所有从TCP网络的消息都被直接放入非持久事件流。如果消息的Persistent Delivery Mode设置为Persistent，消息将被移动并持久化到持久事件流。
- 日志记录
基于从阈值设置到没有订阅者到达的消息等多种条件，实时记录事件消息。这是消息活动日志，而不是完整消息的追踪。
有关为各种API配置日志记录的信息，可在配置日志记录中找到。
- 订阅绑定
当消费者表示他们希望针对Direct模式交付（包括降级消息）接收特定主题消息时，被吸引的主题消息现在在消费者的出口队列中被引用，以处理到TCP出站缓冲区。
- 消费者出口队列
计划用于特定消费者TCP交付的非持久事件队列中的消息引用。只有当消费者的安全ACL配置文件允许交付时，引用才会被添加到出口队列。
有关更多信息，请参阅客户端出口队列结构概览。
数据平面任务锚
下图展示了数据平面执行的任务：
以下讨论和链接提供了图中所示组件的信息。
- 消费者出口队列：了解有关代理上每个客户端优先级队列的更多信息，以及您可以使用的配置它们的命令。
- 出口主题ACL：了解有关出口主题ACL的更多信息。
- 入口主题ACL：您可以使用ACL控制客户端被允许发布和订阅其消息VPN中的主题。
- 升级：消息升级是生产者发送直接消息的情况，消费者从保证消息终点接收这些消息。
- 降级：消息降级是生产者发送持久消息的情况，并且有消费者希望接收这些消息，但可以容忍丢失消息。
- 优先级：当您启用终点尊重消息优先级时，来自生产者的消息的优先级字段将被尊重所有保证和提升的直接消息。
- 共享订阅：共享订 阅可用于在多个后端数据中心应用程序实例之间跨负载均衡大量客户端数据。
- 持久消息移动到持久事件流：所有从TCP网络的消息都被直接放入非持久事件流。根据消息中设置的持久交付模式，消息被移动并持久化到持久事件流。
- 日志记录：了解如何使用消息传递API进行日志记录。
- 订阅绑定：通常，当队列被设置为消息的目标时，消息会被发布到队列。然而，您也可以向队列添加主题订阅，以便它接收任何发布到匹配主题目标的消息。
非持久临时队列
有些消息交换模式（MEP）不需要持久队列在持久消费者生命周期之外存在。这些队列称为临时队列；这种类型的队列仅在创建它的消费者处于活动状态时才处于活动状态。
临时队列经常用于使用请求/回复MEP的生产者，其中回复消息仅在生产者存在时相关。
在下图中，您可以跟踪消息在非持久临时队列上是如何被处理的：
这个过程的详细步骤（对应图中的数字）如下：
-
如果持久消费者1停止或断开与事件代理的Solace会话，它会导致相关的出口队列解散。由于队列2是一个持久队列，队列2端点将继续存在。
-
如果持久消费者2停止或断开与事件代理的Solace会话，它会导致相关的出口队列解散。
-
没有消费者与临时队列1相关联，因此它也被解散，所有对持久事件流的引用都被解散。
以下链接提供了上图中所示组件的信息。
- 临时队列：了解有关临时队列和主题端点的更多信息。
- 持久队列：了解有关持久队列和顶部端点的更多信息。
- 客户端出口队列：获得客户端出口队列的概览。
- 持久消费者：了解如何使用API接收和管理保证消息。
持久事件流
如果事件消息在到达代理后被放置在非易失性存储介质上，则被认为是持久的。持久消息适用于事件消息必须满足以下条件的应用程序设计模式：
- 按接收顺序处理。
- 即使消费者离线，也可供消费者使用。
- 能够在事件代理丢失的情况下生存。
使用持久事件
持久事件通常用于不容忍丢失和重复的MEP，例如金融交易应用程序。
处理持久和非持久事件的不同流
持久事件需要比非持久事件更多的处理。PubSub+事件代理为这两种消息类型使用不同的路径，以确保各自的处理过程不会相互干扰。
持久事件是如何被处理的？
持久事件消息在三个主要阶段中被处理，这些阶段在后续部分详细讨论：
- 生产者端处理持久事件
- 数据平面任务持久事件流
- 消费者端处理持久事件
生产者端处理持久事件
事件生产者可以通过将消息的Persistent Delivery Mode设置为Persistent来发送保证QoS的事件消息。这个标志指示代理在将消息存储在持久存储中（包括HA和/或DR复制）时，向生产者发送确认。
持久事件处理
在下图中，您可以跟踪持久事件是如何被PubSub+事件代理处理的。
这个过程的详细步骤（对应图中的数字）如下：
- 生产者向事件代理发送事件消息，事件流消费并持久化消息。更多信息，请参见发布保证消息。
- 在事件流上放置新消息会触发代理对变化做出反应。数据平面被提醒以确定是否需要将消息路由到另一个代理或VPN（通过DMR、MNR或VPN桥）。所有队列和DTE端点状态引擎都会更新，如果它们对新到达的消息主题有注册兴趣。更多信息，请参见保证消息操作。
- 一旦消息被物理持久化，生产者就会收到确认。这与第2步并行发生。更多信息，请参见保证消息操作。
要了解更多关于配置持久队列的信息，请参见配置队列。
数据平面任务持久事件流
数据平面对队列端点进行操作。对于持久事件消息传递，队列端点维护针对直接针对特定队列的所有消息的状态，或者作为队列主题订阅的一部分。与队列端点相关的三个主要功能类别：
- 当事件流中的新消息与队列配置的订阅匹配时，更新状态引擎。
- 将消息发送给客户端，作为浏览或处理消费者。
- 内部处理状态引擎的更新，以提供内部流处理、事务管理、冗余、复制、队列到队列状态引擎更新和管理/管理状态引擎属性。
更新队列端点的状态引擎
新事件消息到达持久事件流会导致队列端点的状态引擎更新，为新到达的消息添加指针。
然而，即使队列端点在持久事件流中注册了对主题的兴趣，也不能保证状态引擎会用新消息的指针更新队列端点。所有消息仍然必须满足所需的访问控制，然后队列端点才会引用新消息。
消费消息
如果消费者将流绑定到队列端点以接收保证传递QoS的消息，这并不能确保消费者实际上会接收队列端点状态引擎中引用的所有消息。
保证传递QoS的消费者仍然必须在队列级别被授权，然后他们才能消费或生产将在队列端点更新的保证消息。
保证消费者还可以定义一个选择器，其中只有队列消息 的一个子集实际上会被发送给消费者。有关选择器的更多信息，请参阅使用选择器页面。
数据平面执行的操作
新到达的持久消息不仅仅更新队列端点记录列表。数据平面还触发以下代理功能的检查和相关处理操作：
- 消息重放 消息重放是Solace PubSub+的一个功能，允许代理在首次接收到消息后几小时甚至几天，向新旧客户端重新发送消息。
更多信息，请参阅消息重放和下面的重放消息部分。
- 死信队列 处理队列端点的消息，消息可能因为TTL（生存时间）设置或有毒消息重新传输设置而被移除。消息从队列端点引用中移除，并自动添加到与原始队列端点关联的死信队列。
您可以在配置死信队列中找到更多详细信息。
- HA冗余 消息可能需要在被认为是在主HA代理中持久化之前复制到HA成员。
更多信息，请参阅事件代理冗余以实现高可用性。
- DR复制 消息可能需要在被认为是在主HA集群中持久化之前复制到DR代理集群。
更多详细信息，请参阅数据中心复制以实现灾难恢复。
- 队列到队列多阶段提交复制
如果多个队列设置为
reject-msg-to-sender-on-discard，那么在任何一个具有拒绝丢弃设置的队列中无法滚动相同的消息，那么该消息将为所有合作队列回滚，并向生产者发送负确认。
您可以在拒绝消息给发送者丢弃中找到更多信息。
- 会话和XA事务 从队列生产或消费的消息可以被包裹在会话或XA事务语义中。
更多信息，请参 阅会话和使用XA事务。
数据平面任务
下图展示了数据平面执行的各种任务：
图中显示的组件如下：
- 流ACL：ACL用于控制哪些客户端可以连接到哪些消息VPN，以及客户端被允许在它们的消息VPN中发布和订阅哪些主题。
- 选择器：选择器使客户端能够指定他们感兴趣的接收消息，由消息的头字段和属性值决定。
- 队列：队列所有者对队列拥有完全无限的权限。也就是说，所有者可以消费、删除或修改队列中的主题。
- 队列权限：队列所有者对队列拥有完全无限的权限。也就是说，所有者可以消费、删除或修改队列中的主题。
- 队列消费者：
MessageConsumer对象可以用来从队列接收消息或针对特定主题。 - 队列浏览器：使用Java和.NET API的客户端应用程序可以使用浏览器接口查看队列中保证消息的顺序，从最旧到最新，而无需消费它们。
- 消息重放：获取有关消息重放的概览信息。
- 死信队列：处理队列端点的消息，消息可能因为TTL（生存时间）设置或“有毒消息”重新传输设置而被移除。消息从队列端点引用中移除，并自动添加到与原始队列端点关联的死信队列。
- HA冗余：消息可能需要在被认为是在主HA代理中持久化之前复制到HA伴侣。
- DR复制：消息可能需要在被认为是在主HA集群中持久化之前复制到灾难恢复PubSub+代理集群。
- 队列到队列多阶段提交复制：当向代理发布保证消息时，消息可能因为消息池已满、消息大小超出最大限制、端点关闭等原因而被丢弃。
- 会话事务：本节描 述了如何使用事务会话发布和/或接收一系列保证消息，这些消息在单个原子单位中被称为本地事务。本地事务仅依赖单个资源（代理）为消息客户端提供服务。
- XA事务：本节主要针对应用程序架构师和中级到高级程序员，他们打算构建自己的XA解决方案，而不是使用现有的Solace JEE连接器架构（JCA）资源适配器。
- 订阅绑定：通常，当队列被设置为消息的目标时，消息会被发布到队列。然而，您也可以向队列添加主题订阅，以便它接收任何发布到匹配主题目标的消息。
消费者端处理持久事件
持久消费者通过创建针对队列端点的流来处理持久事件流中的消息。数据平面将消息移动到消费者出口队列。
在下图中，您可以跟踪消息到消费者处理的过程。
这个过程的详细步骤（对应图中的数字）如下：
- 两个持久消费者都接收尚未处理的下一个主题3消息。更多信息，请参见接收保证消息。
- 两个持久消费者确认他们已完成处理消息。更多信息，请参见客户端接收消息确认。
- 代理意识到没有其他持久消费者针对相同的主题消息，因此消息从持久事件流中删除。更多信息，请参见客户端接收消息确认。
要了解更多涉及的组件信息，请参阅以下内容：
- 队列：获取有关配置持久队列的信息。
- 持久消费者：了解如何使用API接收和管理保证消息。
独占和非独占持久队列
持久队列可以为消费者提供两种类型的访问权限：独占或非独占。两者都吸引持久消息，即使没有活动消费者绑定到队列。
有关如何设置持久队列的访问类型，您可以参考配置队列页面上的配置访问类型，但接下来提供了两种访问类型的简要总结。
非独占队列锚
非独占队列为持久消费者提供负载均衡和容错能力，并允许多个消费者绑定到同一队列端点。
消息以轮询方式分发给消费者，以提供负载均衡。如果消费者失败，其未处理的消息将转发给活动消费者，以确保消费者的容错能力。
如果新消费者绑定到队列，负载将自动在新加入的消费者和非独占队列之间分配。
独占队列锚
独占队列为持久消费者提供容错能力。多个消费者可以绑定到队列，但只有第一个绑定的消费者会接收任何消息。如果处理消费者失败，下一个绑定的消费者将接收第一个消费者未处理的任何消息，并成为活动处理消费者。
独占和非独占持久队列处理流程锚
下图提供了独占和非独占队列的概览信息。
这个过程的详细步骤（对应图中的字母）如下：
- 非独占队列为持久消费者提供负载均衡和容错能力。非独占队列允许多个消费者绑定到同一队列端点。消息以轮询方式分发给消费者，以允许负载均衡的消费者。如果消费者失败，其未处理的消息将转发给活动消费者，以确保消费者的容错能力。
- 独占队列为持久消费者提供容错能力。多个消费者可以绑定到队列，但只有第一个绑定的消费者会接收任何消息。如果处理消费者失败，下一个绑定的消费者将接收第一个消费者未处理的任何消息，并成为活动处理消费者。
要了解更多关于上图所示组件的信息，请参阅队列访问类型。
重放消息锚
PubSub+支持四种不同的重放策略。您决定使用哪一个取决于您的要求和用例。
- 消息重放 消息重放是PubSub+的一个功能，允许事件代理在首次接收到消息后几小时甚至几天，向新旧客户端重新发送消息。 启用重放后，事件代理将持久消息存储在重放日志中。
有关更多信息，请参阅消息重放。
- 自动会话重新交付 当PubSub+检测到会话断开-重新连接事件时，队列端点将自动重放所有消息给消费者，这些消息正在传输中或正在被消费者处理，但尚未确认。所有在会话上重放的消息都有一个标志，表明它们是由于消费者会话重启而重放的。
有关配置持久队列的最大重新交付尝试次数的信息，可以在配置最大重新交付尝试中找到。
- 队列浏 览器 PubSub+支持一个特殊的消费者，称为队列浏览器，它通过重放队列中的消息来消费消息，但队列端点不期望确认，也不将消息标记为已消费。
有关更多信息，请参阅浏览保证消息。
- PubSub+缓存 PubSub+缓存是一个外部的内存数据网格，用于非持久消息的高速和低延迟存储。重放是基于主题的，基于消息深度或时间。
有关更多信息，请参阅PubSub+缓存。
消息重放处理流程
下图展示了上述重放策略在PubSub+事件消息处理中的适用位置。
以下讨论和链接提供了图中所示组件的信息。
- PubSub+缓存：用于非持久消息的高速和低延迟存储的外部内存数据网格，用于重放。重放是基于主题的，基于消息深度或时间。
- 消息重放：允许事件代理在首次接收到消息后几小时甚至几天，向新旧客户端重新发送消息的PubSub+功能。
- 重放日志：了解如何配置消息重放。
- 自动会话重新交付：当PubSub+检测到会话断开连接-重新连接事件时，队列端点将自动重放所有消息给消费者，这些消息正在传输中或正在被消费者处理，但尚未确认。所有在会话上重放的消息都有一个标志，表明它们是由于消费者会话重启而重放的。
- 队列浏览器：PubSub+支持一个特殊的消费者，称为队列浏览器，它通过重放队列中的消息来消费消息，但队列端点不期望确认，也不将消息标记为已消费。