我是MQTT的新手，我刚刚了解了消息发布时决定的QOS级别的含义：
我注意到订户方也可以设置＆＃34; 他们将收到的最大QOS级别＆＃34;。 引自here：
例如，如果在QoS 2上发布消息并且客户端订阅了QoS 0，则该消息将以QoS 0传递到该客户端。
这是否意味着尽管发布者将其与QOS 2一起发送，但该消息可能无法到达客户端（QOS 0）？
这可能是缺乏经验的开发人员中的一个大问题 - 例如，npm mqtt package中订阅功能的默认QOS为0！ （在我看来，默认值应该是最大值2，即＆＃34;让出版商决定QOS＆＃34;）。
答案 0 :(得分：6)
您是正确的，无法保证在QoS 2上发布的消息将到达使用QoS 0的订户。如果该订户接收消息很重要，则应使用QoS 1或2。这是任何给定应用程序的决定。
我会将您的QoS 0定义重写为“最多一次”，即消息将被接收或不会，不会有重复的可能性。
关于默认QoS - 我认为大多数客户端使用QoS 0作为默认值。我没有看到将QoS 1或2设置为默认值会帮助缺乏经验的开发人员，他们仍然需要了解他们为什么以及他们正在做什么，并考虑其对应用程序的影响。
答案 1 :(得分：1)
“这是否意味着尽管发布者使用QOS 2发送消息，消息仍可能未到达客户端（QOS 0）？”
是的，这是真的。发布者将要在QOS 2上发布，以确保记录仅到达状态层一次（无重复）。一层重试+用来确保这一点。经纪人还有其他工作，可以为订阅客户提供该主题，以确保按要求的QOS级别传递消息。
例如，消息在QOS 1上发布，而同一主题的订户在QOS 2上订阅，那么处理将消息传递给所述订户的代理将必须确保没有重复发送到客户端。
在您的示例中，发布者正在QOS 2上发布，因此状态层插入了一次记录，并且在QOS 0处有一个针对同一主题的订阅者。订阅者可能永远不会收到此消息。例如，在发送消息期间发生网络故障，记录从未到达。由于QOS 0中没有确认机制，因此代理永远不会尝试重新交付。
答案 2 :(得分：1)
发布者确实没有直接了解哪些客户订阅了该消息。发布商的QOS级别决定了确保经纪人收到发布的服务质量。代理收到发布后， it 便有责任以相应订户选择的QOS将消息重新发送给每个订户。订阅者可以在QOS 2处从代理接收消息，即使发布者以QOS 0或1将消息发送给代理。
我发现this article对理解这个概念很有帮助。
答案 3 :(得分：-1)
我还没有阅读MQTT协议规范， 只需说说我对mosquitto 1.5.3的测试即可。
使用默认配置。
mosquitto -v
1541075091: mosquitto version 1.5.3 starting
1541075091: Using default config.
AAA sub topic 'aaa'
BBB sub topic '+'
DDD pub topic 'aaa'
1541075322: New connection from 10.1.1.159 on port 1883.
1541075322: New client connected from 10.1.1.159 as DDD (c1, k60).
1541075322: No will message specified.
1541075322: Sending CONNACK to DDD (0, 0)
1541075322: Received PUBLISH from DDD (d0, q1, r1, m1, 'aaa', ... (8 bytes))
1541075322: Sending PUBACK to DDD (Mid: 1)
1541075322: Sending PUBLISH to AAA (d0, q0, r0, m0, 'aaa', ... (8 bytes))
1541075322: Sending PUBLISH to BBB (d0, q0, r0, m0, 'aaa', ... (8 bytes))
1541075322: Received DISCONNECT from DDD
1541075322: Client DDD disconnected.
在PUBACK消息之前将服务器PUBLISH移至DDD。
pub qos=1仅确保经纪人收到消息，
sub qos也：
[ pub ] ---pub_qos---> [ broker ] ---sub_qos--> [ sub ]
// MQTT客户端和代理网络拓扑是星形网络。
//如果有时间，我会阅读协议规范