消息重放

消息重放允许事件代理在消息首次被事件代理接收数小时（甚至数天）后，将消息重新发送给请求它们的新或现有客户端。当启用消息重放时，事件代理将持久消息存储在重放日志中。这些消息在重放日志中保留，直到其存储使用率达到其配置配额的90%，之后通过称为“修剪”的过程，最旧的消息将从重放日志中移除，以为新消息腾出空间。

消息重放可以在非分区队列或主题端点上执行。重放可以从事件代理管理界面（PubSub+ Broker Manager、Solace CLI和SEMP）或使用PubSub+消息传递API的客户端应用程序中启动。在启动重放时，您可以请求重放日志中的所有消息、指定复制组消息ID之后的所有消息，或从请求的重放开始时间开始的所有消息。事件代理将从重放日志中传递与该队列或主题端点上的任何订阅匹配的消息，从指定的开始点到重放日志的结束。重放流中的消息随后加入实时消息流，无需消费应用程序采取任何操作。

不支持分区队列的消息重放。

不支持与复制一起使用的消息重放。在活动站点写入重放日志的消息可能不会在待机站点的重放日志中写入。

有关消息重放的更多信息，请参见：

• 理解消息重放
• 消息重放操作指南
• 使用场景
• 监控消息重放
• 消息重放与PubSub+缓存比较

如果您准备使用消息重放，可以通过跳转到消息重放配置来了解如何配置和使用它。或者，您可以观看消息重放配置视频，了解如何使用PubSub+ Broker Manager快速设置消息重放。

理解消息重放

您可以配置哪些消息VPN配置了消息重放。

消息存储

以下总结描述了消息重放如何使用消息存储：

• 您可以通过配置重放日志的max-spool-usage来配置每个消息VPN的重放日志消耗的存储使用量（MB）。我们将其称为消息重放的配置配额max-spool-usage。
• 默认情况下，所有未被拒绝给发布者的保证消息都存储在重放日志中。您可以使用主题过滤器（包括通配符订阅和主题例外）来选择哪些消息被添加到重放日志中。重放日志在许多主题中保持原始发布顺序。有关更多信息，请参见指定要添加到重放日志中的消息。
• 当消息重放存储达到其配置配额的90%时，事件代理会自动从重放日志中修剪最旧的消息，以为新消息腾出空间。您可以选择手动修剪重放日志，以减少自动修剪的频率。有关更多信息，请参见修剪重放日志。
• Solace建议您监控重放日志，以确保重放日志不超过其配置配额的90%的max-spool-usage。有关更多信息，请参见监控消息重放。
• 如果重放日志达到其配置配额的100%的max-spool-usage，将发生以下情况：
  • 消息被拒绝，事件代理向发布客户端发送否定确认（NACK），这会导致发布客户端产生反向压力。
  • 为确保重放日志存储使用量不超过其配额，被拒绝的消息不会被添加到重放日志中。

重放消息

• 重放可以从特定时间开始、在特定复制组消息ID之后开始，或从消息重放日志的开始开始。
• 当重放开始时，从播放开始点开始的所有记录消息都会被处理，事件代理重放与重放端点的订阅匹配的记录消息。事件代理以最初接收的形式发送原始消息，包括原始主题、内容和消息ID，没有任何修改。事件代理不会以任何方式标记消息为重新传递。
• 消息以原始顺序重放，即使跨不同主题也是如此。
• 消息重放可以为任何消费者执行，无论他们使用什么协议或API，包括AMQP、MQTT、REST/WebHooks和PubSub+消息传递API。
• 消息仅重放到请求它们的端点。如果您从Broker Manager或Solace CLI启动消息重放，您必须指定您想要重放消息的端点。
• 如果重放启动到没有连接客户端以消费和确认消息的端点，重放会向端点发送最多1000条消息，以确保端点的未确认资源不会被完全消耗。有关更多信息，请参见资源消耗。在客户端连接并开始从端点消费消息后，日志中剩余的消息将重放到端点。
• 如果端点有连接的客户端，重放的消息数量仅受端点上的每个流的最大传递未确认消息数（max-delivered-unacked-msgs-per-flow）设置限制（最多100,000条消息）。
• 在已经处于重放状态的端点上启动重放将取消之前的重放并开始新的重放。
• 在端点处于重放状态时接收到的实时消息将像往常一样处理，包括被写入重放日志，但它们不会被发送到处于重放状态的端点。端点按顺序接收来自重放日志的消息。当重放完成后，端点开始接收实时消息。
• 复制组消息ID是Solace消息的一个属性，由将消息传递到队列和主题端点的事件代理分配，唯一标识在高可用性（HA）组和复制组中的特定队列或主题端点上的消息。

复制组消息ID仅在高可用性（HA）组或复制组内唯一标识消息。在事件网格中，当事件代理通过动态消息路由（DMR）或VPN桥接相互连接时，给定消息在网格中的每个复制组中被分配不同的复制组消息ID。在特定复制组消息ID之后重放时，如果指定的消息ID在重放日志中找不到，重放请求将失败。

消息重放操作指南

以下图示展示了事件代理上消息重放的工作原理的简化示例，以帮助您理解消息的流向。

基本消息流

此操作指南跟踪从发布者到事件代理，最终到订阅者的消息旅程，以向您展示消息如何被记录用于重放，并在稍后时间重放。

1. 发布者应用程序连接到事件代理并发布消息。

2. 事件代理执行以下操作：

   1. 为每条消息分配唯一的复制组消息ID。
   2. 将每条消息写入持久存储。
   3. 将每条消息的引用添加到适当的订阅队列中。
   4. 将每条消息的引用添加到重放日志中。

3. 订阅者执行以下操作：

   1. 从其队列中消费每条消息。
   2. 处理每条消息。
   3. 向事件代理发送每条消息的确认。

4. 在接收到确认后，事件代理从订阅者的队列中删除已确认的消息。

5. 消息保留在重放日志中，直到它成为日志中最旧的消息，并需要被修剪以腾出空间给更新的消息。

6. 一段时间后，订阅者遇到系统错误并丢失了最近的数据。为了检索已传递但丢失的消息，订阅者以以下两种方式之一请求重放：

   • 订阅应用程序直接使用PubSub+消息传递API请求消息重放。
   • 管理员使用PubSub+ Broker Manager、Solace CLI或SEMP启动消息重放。

订阅者请求以下重放选项之一：

• 如果知道数据丢失的时间，则从特定时间开始重放消息。
• 如果知道最后保留的消息ID，则从特定复制组消息ID之后开始重放消息。
• 从最旧的消息开始重放重放日志中可用的所有消息。

使用场景

消息重放可以在多种情况下恢复或重新创建应用程序数据库中的消息。

应用程序损坏恢复

考虑一个连接到一个或多个队列的应用程序，接收消息，处理它们，更新其自己的持久数据库以反映消息内容，包括从消息中检索到的复制组消息ID，并确认消息的接收。此确认将消息从队列中删除。如果应用程序发生某种形式的崩溃，导致其自己的数据库损坏，应用程序可能会以已知良好的数据库重新启动，可能是当天早些时候的数据库，但在此期间它所做的任何工作都已丢失。

在这种情况下，应用程序可能会请求从数据库中最后一条记录中存储的复制组消息ID开始向其队列重放消息，重新执行它已经完成的工作。在重放期间，新的实时消息将被添加到重放日志中。一旦所有记录的消息都被重放，应用程序自动重新加入实时数据流。

管理员也可以通过Solace CLI、Broker Manager或SEMP命令代表客户端启动队列的重放。

应用程序配置错误恢复

考虑一个应用程序，其中一组由管理员配置的主题到队列的映射用于将消息吸引到应用程序的队列。如果配置中出现错误，队列上的主题集不正确，错误可能不会立即被注意到。

在这种情况下，管理员在队列上更正主题到队列的映射，并以已知良好状态或空状态重新启动应用程序。管理员或应用程序请求向其队列重放消息，使用现在更正的主题到队列的映射重新执行其工作。在所有旧消息（包括由于不正确的主题到队列映射而错过的消息）被重放到应用程序后，它自动重新加入实时数据流。

应用程序晚加入

在此用例中，一个在数据发布时没有在事件代理上有队列或订阅的应用程序可能希望连接到事件代理，创建其队列和订阅，然后使用消息重放来消费之前发布的数据。此用例的典型应用程序包括将新的分析或交易算法上线，该算法需要一定量的历史数据来对后续实时数据做出决策。

事件溯源和按需分析

在此用例中，企业可能希望重放发送到应用程序的数据，以捕获整个消息流向应用程序的历史，以便在以后进行审查或分析。

消息重放与PubSub+缓存比较

消息重放不是PubSub+缓存的替代品。两者之间有许多不同之处，以下表格中列出了这些不同之处。选择消息重放还是PubSub+缓存取决于您的使用场景。

属性	消息重放	PubSub+缓存
使用场景	消息日志
记录发布到消息VPN的所有保证消息。
当重放日志超过其配置配额的90%时，自动从日志中修剪最旧的消息。	最后值缓存
通常只保留每个主题上发布的最后一条消息。
虽然PubSub+缓存可以配置为每个主题保留多条消息，但这是一种不太常见的用例。
消息QoS	记录保证（或持久）消息。
记录任何被提升为保证消息的消息。	旨在缓存直连（或非持久）消息。
使用直连消息与事件代理连接。如果有任何保证消息匹配PubSub+缓存订阅，这些消息在发送到PubSub+缓存时会被降级为直连。
与客户端API的交互	所有与客户端API的交互都使用保证消息传递。	所有与客户端API的交互都使用直连消息传递。
记录的主题	默认记录消息VPN中发布的所有保证消息。您还可以配置消息重放以记录匹配一组通配符订阅和过滤器的消息。	管理员配置要存储在缓存中的通配符主题。
消息传递顺序	以原始发布顺序重放消息。
主题之间的发布顺序得以保留。	缓存请求按主题逐个满足。
在主题内（如果深度大于1）顺序得以保留，但主题之间的原始发布顺序不保留。
重放请求机制	PubSub+消息传递API
管理界面	PubSub+消息传递API
部署模型	PubSub+事件代理的集成功能。	在外部Linux服务器上运行的软件应用程序。
消息存储	使用保证消息传递基础设施来持久存储消息。	将缓存的消息存储在RAM中。
冗余模型	利用事件代理的活动-备用高可用性（HA）模型。	部署多个实例以实现N+1冗余。
性能和扩展	为以保证消息传递速率记录消息而构建。
通过增加更多的PubSub+事件代理来水平扩展保证消息传递和消息重放。	为非常高的直连消息传递用例（如市场数据分发）而构建。
支持部署多个实例以水平扩展。
可用性	集成到PubSub+事件代理中；无需额外许可。	需要购买许可的可选附加产品。