跳到主要内容

消息重放配置

消息重放允许已发布的保证消息以及被提升为保证消息的直连消息（未被拒绝给发布者）被存储在重放日志中。消息的存储在接收到后无限期进行，以防它们在以后的某个日期需要被重放。

您可以从事件代理或至少具有消费权限的客户端启动端点的重放日志回放。后者会导致将记录消息的过滤子集发送给这些客户端。

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

  • 部署注意事项
  • 术语
  • 重放请求类型
  • 可重放消息的生命周期
  • 向端点重放
  • 重放状态
  • 修剪重放日志
  • 直连消息和消息重放

有关使用Solace CLI命令配置和管理消息重放的说明，请参见：

  • 配置消息重放
  • 回放重放日志
  • 监控消息重放

有关在Broker Manager中设置和使用消息重放的说明，请参见配置消息重放。

下一步​

从这里开始，您可以根据您想了解的内容选择不同的路径：

  • 查看一些简单的示例，展示如何使用Solace CLI配置和使用消息重放，在消息重放示例部分。

  • 查看如何使用每个消息重放Solace CLI命令的详细信息，这些部分中。

    • 配置消息重放
    • 回放重放日志

  • 查看Solace消息重放与JCSMP教程，展示客户端如何启动和处理重放，以及如何从重放日志启动重放的指导。

  • 观看一个视频，展示如何使用PubSub+ Broker Manager启动消息重放。

部署注意事项​

支持的PubSub+产品锚点​

消息重放支持以下Solace PubSub+产品：

  • Solace PubSub+ 3530和3560设备
  • PubSub+软件事件代理
  • PubSub+ Cloud（受控可用性）

使用消息重放时的建议和注意事项锚点​

您应该了解以下消息重放特性：

  • 消息重放消耗事件代理处理资源，因为它需要维护重放日志，处理消息的检索和重放，并在重放日志的存储使用率达到其配置配额的90%时修剪重放日志。
  • 慢速磁盘会负面影响消息重放性能。
  • 不支持与消息重放的复制。

术语​

以下表格提供了在消息重放讨论中常用的术语定义。

术语描述
实时消息未发送给所有消费客户端的已发布消息。它存在于数据路径的某个位置；即，它是在入站时接收的，通过出站发送的，或存在于一个或多个端点中。
可重放消息在启用消息重放的消息VPN上接收的实时消息。
已记录消息在重放日志中可用于后续重放的可重放消息。
重放端点当前从重放日志接收已记录消息的端点。
已重放消息在重放日志中可用且与重放端点的订阅匹配并已添加到端点的已记录消息。
重放到端点将已记录消息添加到重放端点的过程，从而在重放端点上创建已重放消息实例。
重放日志修剪自动删除重放日志中最旧消息以腾出空间给新实时数据的过程。

重放请求类型​

可以通过使用PubSub+消息传递API绑定到保证端点的客户端应用程序，或从Broker Manager、Solace CLI或SEMP启动端点的消息重放请求。在任何情况下，消息重放支持以下类型的回放请求：

  • 从日志开始处开始重放请求者指定从重放日志中最旧的消息开始回放。重放日志中与端点的订阅匹配的所有消息都将被传递到端点。
  • 从特定日期开始重放请求者指定从何时开始回放。重放日志中等于或晚于指定日期和时间且与端点的订阅匹配的任何消息都将被传递到端点。
  • 从复制组消息ID开始重放请求者指定从特定复制组消息ID之后开始回放。重放日志中在指定复制组消息ID之后接收到且与端点的订阅匹配的任何消息都将被传递到端点。

在所有情况下，一旦重放赶上实时数据流，消息传递将切换到从端点传递实时消息。

可重放消息的生命周期​

让我们走过可重放消息的生命周期。需要注意的是，生命周期对所有类型的重放请求都是相同的，并且在以下生命周期阶段中，下划线部分对应于术语部分中的术语。

  1. 在启用消息重放的消息VPN上接收到实时消息。此消息被视为可重放消息。

  2. 消息成功存储到所有非重放目的地，添加到重放日志中，现在被视为已记录消息。

  3. 在某个时候，事件代理接收到包含已记录消息的开始时间的重放请求。一旦重放到达已记录消息，并成功执行重放到端点，它就被视为已重放消息。

    • 关于重放过程的更详细讨论在重放到端点中呈现。
    • 如何使用Solace CLI启动重放的说明在使用start-replay启动记录消息的重放中显示。

  4. 最后，已重放消息被传递给消费者并被确认，这将其从重放端点中移除；然而，它仍然在重放日志中，直到被修剪。

    • 有关自动和手动重放日志修剪的更多讨论，请参阅修剪重放日志。
    • 如何使用Solace CLI手动启动重放日志修剪的说明可以在使用trim-logged-messages从重放日志中删除消息中找到。

向端点重放​

重放已记录消息是按端点进行的，并且可以使用PubSub+ Broker Manager、Solace CLI和SEMP命令启动，或者通过使用PubSub+消息传递API绑定到端点的客户端应用程序启动。如重放请求类型中所述，重放请求可以启动所有已记录消息的回放，所有给定复制组消息ID之后的消息，或从给定日期和时间开始，条件是如果提供了开始日期和时间，它们不能是未来的日期和时间。在所有情况下，所有绑定到重放端点的客户端都被断开连接，除非是通过绑定请求请求重放的客户端。

主题匹配​

从回放开始点开始的所有已记录消息都被处理，并且事件代理尝试将其主题与重放端点的订阅匹配。当匹配时，事件代理将已记录消息重放到重放端点，并以最初接收的形式发送原始消息，没有任何修改。它发送原始主题、内容和消息ID。事件代理不会将消息标记为重新传递。

窗口机制​

在向重放端点重放消息时使用窗口机制。这意味着在事件代理等待从重放端点消费已重放消息之前，只有一部分消息被重放到端点。

在正在进行重放的端点上启动重放​

在已经进行重放的端点上启动重放将取消之前的重放并开始新的重放。

在正在进行重放的端点上接收实时消息​

作为目的地的重放端点接收到的实时消息将经过所有通常的检查，就像它没有在重放一样。一旦所有检查都通过，消息不会存储到端点，而是存储到重放日志中 - 它将在重放赶上消息时被重放。

被拒绝的消息​

被拒绝（NACK'ed）给发布者的消息不会被记录到重放日志中。

向独占队列重放​

不建议向任何独占队列重放，其活动消费者使用出站选择器过滤消息。如果使用出站选择器，并且它导致重放消息在重放端点上无限期停留，重放将无法完成。

向临时端点重放​

在事件代理版本10.0.0及以后版本中，您可以重放到临时主题端点或临时队列，前提是您适当配置了事件代理。有关更多信息，请参见在临时队列上启用重放。

重放状态​

端点显示以下重放状态之一：

状态描述
不适用从未为端点请求过消息重放。
完成最后一次请求的重放已完成且没有正在进行的重放。
初始化已请求消息重放，将在从端点移除所有实时消息后开始。
活动消息重放正在进行中。端点当前正在从重放日志接收消息。
待完成消息重放已到达重放日志的末尾，但端点上仍有未确认的重放消息。新的实时消息正在被传递到端点。然而，重放仍然可能失败，在这种情况下，端点上的未确认重放消息将被删除。
失败重放已失败，端点正在等待确认其作为失败指示发送给事件代理的解除绑定请求。

修剪重放日志​

随着重放日志的增长并达到配置的容量，较旧的已记录消息被删除以腾出空间给新的消息。这个过程称为重放日志修剪。当重放日志超过其配置配额的90%时，事件代理会自动执行修剪。

端点可以包含并成功传递已从重放日志中修剪的消息。这是因为如果至少有另一个端点包含该消息，则该消息仍被视为已存储。

您还可以选择使用trim-logged-messages命令手动修剪重放日志，作为您的修剪策略的一部分。

由于修剪是批量进行的，并且是基于因素触发的，例如重放日志的大小（配置配额），以及消息的数量和大小，因此在重放日志超过其配置配额的90%时，修剪可能不会立即发生。例如，如果重放日志的配置配额非常小（例如小于1000 MB），则90%的目标可能无法完美保持。

缓慢修剪的影响​

如果事件代理接收消息的速度快于其修剪重放日志的速度，重放日志的存储使用率可能会增加到其配置配额的90%以上。如果重放日志的存储使用率达到配置配额的100%，事件代理会对发布客户端施加反向压力，以确保重放日志的大小不超过其配置配额。

Solace建议您监控重放日志的使用情况，并选择重放日志修剪策略。例如，如果您注意到重放日志始终超过其配置配额的90%，您可能需要手动修剪重放日志，或者对存储到消息重放日志中的消息更加选择性。例如，您可以使用主题过滤器来减少写入重放日志的消息数量。有关更多信息，请参见确定日志修剪策略。

有关监控和使用主题过滤器的更多信息，请参见：

  • 监控消息重放
  • 指定要添加到重放日志中的消息

确定日志修剪策略​

当您配置消息重放时，Solace建议您决定如何处理重放日志修剪的策略。您可以选择使用自动修剪，无需额外配置，但您应该意识到修剪重放日志可能会对事件代理处理接收到的消息速率造成潜在的性能影响。

您可以在达到90%阈值之前手动修剪重放日志。这种策略可以减少自动修剪在意外时间带来的性能影响。虽然手动修剪对事件代理的性能影响相同，但您可以选择在事件代理不敏感于性能变化的时间运行它。适合手动修剪并避免自动修剪的用例包括以下特征：

  • 事件代理的流量模式遵循一个可预测的周期，在此期间有一个“安静时间”，在此期间修剪重放日志不会导致性能影响。

  • 重放日志可以足够大，以容纳您所需的最小重放日志保留期间记录的所有消息，加上一个流量周期内记录的消息。

  • 可以部署一个自动化应用程序来执行修剪，该应用程序在适当的时间表上运行。

以下示例展示了如何实施手动修剪策略。考虑一个部署，其中：

  • 系统每天向重放日志写入多达125,000 MB的消息。
  • 事件代理在夜间流量低，可以在此期间手动修剪重放日志而不影响事件代理性能。
  • 所需的日志保留期为七天，包括一个额外的流量周期日。

根据上述参数，您可以使用以下配置：

  1. 重放日志需要1,000,000 MB才能避免自动修剪。此示例计算如下：

    • 125,000 MB/天 x (7天保留期加上一个流量周期) = 125,000 MB/天 x 8天 = 1,000,000 MB。

    • 因为修剪从配置配额的90%开始，您会将max-spool-usage设置为比要保留的数据大小多25%（1,250,000 MB），如推荐的那样。因为预期的存储使用率不会超过1,000,000 MB，自动修剪直到重放日志大约有1,125,000 MB的数据时才会开始，并确保您的重放日志足够大。有关更多信息，请参见使用max-spool-usage配置重放日志大小。

      此设计使用重放日志配置配额的80%用于max-spool-usage，但因为修剪直到90%才开始，它最小化了自动修剪的发生，并为您提供了在不丢失重要数据的情况下更改系统行为的灵活性。为了确保此设计在设计参数内运行，需要进行监控，如步骤3所述。

  2. 在您的部署中，您的自动化管理应用程序在夜间运行，使用以下机制之一在您的安静期间手动修剪重放日志：

    • 运行enable admin message-spool message-vpn <vpn-name> replay-log trim-logged-messages <older-than-date>命令（参见消息重放配置）。
    • 使用SEMPv2命令，PUT /msgVpns/{msgVpnName}/replayLogs/{replayLogs/{replayLogName}/trimLoggedMsgs（参见SEMP参考以获取更多信息）。

  3. 当您监控重放日志使用情况时，确保重放日志使用率从不超出步骤1中描述的80%。如果它确实如此，您的策略设计的假设不再有效，您必须重新描述您的系统，调整重放日志的max-spool-usage配置配额，然后更新系统。

直连消息和消息重放​

消息重放旨在用于保证消息。未被提升为保证消息的直连消息不会被记录。因此，如果您的消息可能需要被重放，它们应该作为保证消息发布。

在提升直连消息时要小心，因为它会严重影响事件代理的性能，如果事件代理的保证消息预算被超过，直连消息将不会被记录。如果您有希望记录在重放日志中的直连消息，Solace建议将发布者更改为使用保证消息。有关消息提升及其相关风险的更多信息，请参见主题匹配和消息传递模式。