跳到主要内容

直接消息

直接消息提供从Solace消息总线到消费客户端的可靠但不保证的的消息传递。它是PubSub+的默认消息传递系统。它不需要除了设置和启动事件代理之外的任何额外配置。默认情况下,直接消息始终对所有连接到事件代理的客户端可用。

直接消息特性

直接消息具有以下特性:

  • 它们按照发布者发布顺序交付给订阅客户端。
  • 它们不需要订阅客户端确认收据。
  • 它们不会在消息总线上为消费客户端进行缓冲。
  • 当客户端未连接到事件代理时,它们不会为客户保留。
  • 在某些情况下,它们可以在交付前被丢弃:
    • 客户端在消息发布时从事件代理断开连接。
    • 客户端未能以发布速度消费消息,导致出站消息缓冲区溢出。
    • 遇到拥塞或系统故障。

直接消息用例

直接消息在以下情况下很有用:

  • 需要极高消息率和极低延迟。
  • 消费客户端可以容忍网络拥塞导致的消息丢失。
  • 不需要为慢速或离线消费者保留消息以供后续传递。
  • 必须高效地向大量具有匹配订阅的客户端发布消息。

有关直接消息可用功能的更多信息,请参见以下各节:

  • 共享订阅
  • 消息省略
  • 客户端订阅管理
  • 交付给一个

共享订阅

共享订阅可以与直接消息一起使用,以在多个后端数据中心应用程序实例之间负载均衡大量客户端数据。它们在应用程序并行处理发布的消息的情况下特别有用。共享订阅不受保证消息支持。

要控制客户端是否可以创建或加入共享订阅,客户端的客户端配置文件中的allow-shared-subscriptions属性设置为所需值。有关更多信息,请参见允许共享订阅。

共享订阅的语法

共享订阅的形式为:

#share/<ShareName>/<topicFilter>

其中:

  • ShareName是与共享订阅关联的标识符。它不能包含通配符(*>)。
  • topicFilter是主题过滤器。

共享订阅默认情况下是导出的(由本地节点广告到网络中的其他节点)。要防止这种导出,请以#noexport开始共享订阅,如下所示:

#noexport/#share/<ShareName>/<topicFilter>

其中:

  • ShareName是与共享订阅关联的标识符。它不能包含通配符(*>)。
  • topicFilter是主题过滤器。

有关更多信息,请参见防止订阅导出和保留主题中的#noexport条目。

共享订阅工作原理

为了说明共享订阅的工作原理,请考虑以下示例:

  • #share/ottawa/weathersensor/yow/temperature

许多客户端订阅了#share/ottawa/weathersensor/yow/temperature。当消息发布到weathersensor/yow/temperature时,这些客户端中的一个被随机选择接收消息。对于每个到达的匹配weathersensor/yow/temperature的消息,新的随机选择确定哪个订阅客户端接收消息。有了足够多的消息,n,到订阅客户端,m,每个订阅者接收到的消息数量平均约为n/m

共享订阅标识符

在共享订阅中包含ShareName,因此可以在具有相同topicFilter的事件代理上有多个共享订阅。

例如,考虑以下仅ShareName不同的共享订阅:

  • #share/weatherapp/weathersensor/*/temperature
  • #share/temperaturelog/weathersensor/*/temperature

尽管共享订阅具有相同的topicFilter,但它们是唯一的。当消息发布到weathersensor/yow/temperature,并且许多客户端订阅了#share/weatherapp/weathersensor/*/temperature时,这些客户端中的一个被随机选择接收消息。同样,从所有订阅了#share/temperaturelog/weathersensor/*/temperature的客户端中,随机选择一个客户端接收消息。

在典型使用中,共享消息的应用程序实例就ShareName达成一致,以在共享订阅中使用。然后,匹配共享订阅的主题的消息在这些应用程序实例之间随机分配。

功能交互

保证消息

不允许在队列上使用共享订阅,无论它们是配置的还是信号的,都将被拒绝。

省略

当客户端的客户端配置文件指示正在使用省略时,添加共享订阅,将不会对匹配共享订阅的消息执行省略。

服务等级

直接消息服务等级(CoS)在共享订阅上交付时始终被视为COS1,无论消息的CoS如何。

无本地会话

共享订阅忽略会话的无本地属性。如果客户端在无本地会话上添加共享订阅,那么在同一会话上通过共享订阅发布的消息有资格交付。

API LocalDispatchOnly订阅

共享订阅不能添加为API LocalDispatchOnly订阅。如果应用程序试图创建仅限于单个会话范围的共享订阅,请在共享订阅的sharedSubID中使用一些随机生成的内容,这些内容对其他应用程序是未知的。

PubSub+缓存

不支持将共享订阅配置为针对PubSub+缓存。

动态消息路由(DMR)和多节点路由(MNR)

共享订阅主题过滤器是导出的。这会吸引匹配共享订阅的流量来自其他节点,但它没有分布式共享订阅的效果。如果远程节点有相同的共享订阅,它们被视为不同的共享订阅,每个节点的组中的一个成员将接收匹配共享订阅的发布消息的副本。

Web消息客户端

Web消息客户端不支持共享订阅。

消息省略

消息省略允许客户端应用程序接收他们订阅的主题的直接消息,以他们可以管理的速率接收,而不是排队过时的消息。在消费速度比发布速度慢的情况下,消息省略很有用,例如慢速消费者或人为交互。

使用消息省略时,必须接受一些消息丢失。例如,生产者可能每秒发布多个消息,提供当前状态数据,如天气、车辆位置或股市信息,消费者只关心当前状态。

只有直接消息可以被省略。通过共享订阅接收的消息不能被省略。

要使用消息省略:

  • 发布客户端应用程序必须将发布的消息标记为适合消息省略。

    • 尽管只有直接消息可以被省略,但发布客户端可以标记保证消息为省略合格。然而,除非消息的传递模式更改为直接,否则消息不会被省略,这可能发生在消息发布到匹配客户端主题订阅的主题时。

    • 通过MQTT客户端应用程序发布的消息被视为非省略合格。

  • 接收客户端应用程序必须被分配一个客户端配置文件,通过其客户端用户名允许它:

    • 使用消息省略

    • 在第一条消息之后,接收后续消息有延迟间隔。延迟间隔在客户端配置文件中配置,控制基于每个主题向客户端发送消息更新的速率(例如,每个主题每秒五条消息)。

    • 接收事件代理可以跟踪的每个客户端连接的主题的最大数量(每个客户端最多32,000个,根据客户端配置文件配置,每个事件代理总共200万个;默认为每个客户端256个)。一旦达到最大主题数,事件代理会使客户端的省略主题老化,以防止消费比为连接分配的更多省略资源。然后省略行为就像这是一个新的客户端连接一样继续,并且每个客户端基础上生成一次Syslog事件。

      • 事件代理动态跟踪客户端连接上的主题数量。当这个数字低于设定的最大值时,将新传入的消息应用省略。

      • 对于具有通配符订阅的订阅者,每个匹配订阅的主题都被省略,最多达到客户端配置文件指定的订阅数量。

      • Solace建议使用消息省略的消费者不要使用丢弃指示。在事件代理的出站优先级队列因接收到的消息而填满的情况下,出站队列中最旧的消息被丢弃以腾出空间给新到达的消息,队列头部的消息被标记为丢弃指示。然而,如果启用了省略,那条消息可以被省略,客户端将不会收到丢弃指示。

消息省略示例

以下图表和示例解释了消息省略的工作原理:

img

  1. 生产者以每秒一条消息的速率向主题发布消息(ms)。每条消息都被标记为省略合格。

  2. 消费者被分配一个客户端配置文件,消息省略已启用,并且省略延迟为200毫秒,这意味着它每秒接收5条消息。

  3. 当第一个消息M1到达事件代理时,它被立即发送给消费者,没有任何延迟。

  4. 当第二个消息M2在一毫秒后到达事件代理时,它被事件代理保留,并没有发送给消费者,因为在200毫秒延迟时间内,消息M1已发送给消费者相同主题。

  5. 当后续消息M3、M4、....Mn对同一主题到达事件代理时,每个新消息替换前一个消息,并持续被事件代理保留。

  6. 在消息M1发送给消费者后的200毫秒延迟后,当前保留的消息被发送给消费者。

消息省略用例

消息省略功能的应用案例包括:

省略用于拥塞管理客户端应用程序希望在能够跟上消息流时接收每条消息。如果客户端跟不上,则排队的消息被省略,只发送每个主题的最新消息。对于这种用例,延迟间隔时间为0。省略用于消息速率控制客户端应用程序希望每个主题每秒接收不超过五条消息。在这种情况下,事件代理对输出到客户端的消息进行速率控制。对于这种用例,延迟间隔时间为200毫秒(每个主题每秒五条消息)。

示例用途包括:

向人类交易员流式传输市场数据即使市场数据更新可能以非常高的速率发布,人类只能处理每秒几条更新。客户端始终希望获得最新信息,但速率低于总提要速率。消息省略可以用来将每个主题的输出流限制为每秒几条更新。控制广域网(WAN)上的订阅者更新速率有时,WAN带宽与接收器处理能力要求只提供整个提要速率的子集通过WAN提供。消息省略可以用来控制客户端的消息更新速率。

客户端订阅管理

当消费客户端在事件代理上认证时,它们可以添加和删除发布到它们连接的消息VPN的直接消息的主题订阅。这些主题订阅不是持久的 - 客户端订阅在消费者从事件代理断开连接后不会在事件代理上保留。

客户端通常执行以下步骤来管理自己的订阅:

  1. 客户端连接到事件代理并进行身份验证。此时,事件代理没有该客户端的订阅。
  2. 客户端向事件代理添加订阅。
  3. 客户端接收匹配请求订阅的消息。
  4. 当客户端从事件代理断开连接时,事件代理立即删除与该客户端相关的所有订阅。

客户端被允许订阅的主题可以通过分配给客户端用户名账户的ACL限制。有关更多信息,请参见使用ACL配置文件控制客户端访问。

代表其他客户端管理订阅

当客户端用户名配置为订阅管理器时(参见配置订阅管理器),客户端应用程序可以代表消息VPN中的其他客户端管理订阅。这有助于集中分配客户端应用程序和服务直接消息订阅。充当订阅管理器的客户端对保证消息没有控制权。

当客户端配置为订阅管理器时,它管理的订阅受到该客户端相关访问控制列表(ACL)配置的访问控制权限的限制 - 不使用目标客户端的ACL。因此,配置为订阅管理器的客户端不能添加或删除其自己的ACL规则会拒绝添加的订阅。这个限制防止客户端无意中添加或删除它无权添加或删除的订阅。

当客户端配置为订阅管理器时,消息VPN中的其他客户端通常执行以下步骤来管理它们的订阅:

  1. 客户端连接到事件代理。

  2. 客户端通知订阅管理器它已准备好接收消息。

  3. 订阅管理器对客户端进行身份验证,确定客户端所需的订阅集,并代表客户端向事件代理添加订阅。订阅管理器代表客户端添加的订阅与客户端直接为自己添加的订阅具有相同的订阅速率(每秒订阅数)。

  4. 客户端接收匹配订阅集的消息。

  5. 一旦客户端完成,它断开连接,其关联的订阅集从事件代理中删除。

一旦订阅管理器代表另一个客户端添加了订阅,它们就像任何其他订阅一样(例如,如果客户端断开连接,则订阅被删除)。断开订阅管理器连接不会影响它已经添加的订阅。

有关使用Solace API的客户端如何充当订阅管理器以代表他人添加和删除订阅的信息,请参见代表其他客户端管理主题订阅。