• QoS策略


    • History

      • Keep last: only store up to N samples, configurable via the queue depth option.

      • Keep all: store all samples, subject to the configured resource limits of the underlying middleware.

    • Depth

      • Queue size: only honored if the “history” policy was set to “keep last”.

    • Reliability

      • Best effort: attempt to deliver samples, but may lose them if the network is not robust.

      • Reliable: guarantee that samples are delivered, may retry multiple times.

    • Durability

      • Transient local: the publisher becomes responsible for persisting samples for “late-joining” subscriptions.

      • Volatile: no attempt is made to persist samples.

    • Deadline

      • Duration: the expected maximum amount of time between subsequent messages being published to a topic

    • Lifespan

      • Duration: the maximum amount of time between the publishing and the reception of a message without the message being considered stale or expired (expired messages are silently dropped and are effectively never received).

    • Liveliness

      • Automatic: the system will consider all of the node’s publishers to be alive for another “lease duration” when any one of its publishers has published a message.

      • Manual by topic: the system will consider the publisher to be alive for another “lease duration” if it manually asserts that it is still alive (via a call to the publisher API).

    • Lease Duration

      • Duration: the maximum period of time a publisher has to indicate that it is alive before the system considers it to have lost liveliness (losing liveliness could be an indication of a failure).

    The following tables show the compatibility of the different policy settings and the result:

    Compatibility of reliability QoS policies:

    Publisher

    Subscription

    Compatible

    Best effort

    Best effort

    Yes

    Best effort

    Reliable

    No

    Reliable

    Best effort

    Yes

    Reliable

    Reliable

    Yes

    Compatibility of durability QoS policies:

    Publisher

    Subscription

    Compatible

    Volatile

    Volatile

    Yes

    Volatile

    Transient local

    No

    Transient local

    Volatile

    Yes

    Transient local

    Transient local

    Yes

    Compatibility of deadline QoS policies:

    Assume x and y are arbitrary valid duration values.

    Publisher

    Subscription

    Compatible

    Default

    Default

    Yes

    Default

    x

    No

    x

    Default

    Yes

    x

    x

    Yes

    x

    y (where y > x)

    Yes

    x

    y (where y < x)

    No

    Compatibility of liveliness QoS policies:

    Publisher

    Subscription

    Compatible

    Automatic

    Automatic

    Yes

    Automatic

    Manual by topic

    No

    Manual by topic

    Automatic

    Yes

    Manual by topic

    Manual by topic

    Yes

    Compatibility of lease duration QoS policies:

    Assume x and y are arbitrary valid duration values.

    Publisher

    Subscription

    Compatible

    Default

    Default

    Yes

    Default

    x

    No

    x

    Default

    Yes

    x

    x

    Yes

    x

    y (where y > x)

    Yes

    x

    y (where y < x)

    No

     
       为了建立连接,所有影响兼容性的策略都必须是兼容的。例如,即使请求和提供的QoS配置文件对具有兼容的可靠性QoS策略,但它们具有不兼容的持久性QoS策略,仍然不会建立连接。当没有建立连接时,将不会在发布者和订阅之间传递消息。

  • 相关阅读:
    [极致用户体验] 如何实现响应式canvas?保持canvas比例?教你让canvas自适应屏幕宽度!
    Spring中如何在一个Bean中注入一个内部Bean呢?
    Python字符串及正则表达式
    【CSS3】
    一组完整的读Json配置信息的辅助函数
    ERP软件定价策略与模型设计
    通过T-DIAG指令对S7通信或TCP通信进行连接状态诊断的具体方法示例
    搭建爬虫代理服务器:使用云服务器
    wsl2环境的搭建
    springboot解决multi-statement not allow(已部署生产)
  • 原文地址:https://blog.csdn.net/qq_37174816/article/details/126524000