java - 为什么 MQTT 在 QoS = 1 时会变慢？

Question

我正在尝试编写一个应用程序，通过 WiFi 和 MQTT 协议(protocol)控制一群机器人。我已经执行了一些测试来衡量它是否对我的应用程序足够快。我想要一个平均不超过 25-30 毫秒的控制循环(从 PC 到机器人再返回的消息)。

我使用 Paho Java 客户端编写了一个应用程序，它在两台机器上运行。当一个人收到关于主题 1 的消息时，它会发布到主题 2。 Topic2 由第二台机器订阅，然后发布到 topic1。

    topic1            topic1
M1---------> broker ---------> M2

    topic2            topic2
M1 <-------- broker <--------- M2

当所有发布和订阅均使用 QoS 0 进行时，循环时间平均约为 12 毫秒。但是我想使用 QoS 1 来保证发送给机器人的命令总能到达目的地。当我测试循环时间时，它平均在 250 毫秒左右。

是什么导致时间增加这么多？根据我的理解，如果没有传输错误，交换的数据包数量将与 QoS1 一起翻倍(对于每条消息，代理都会向客户端发送 PUBACK，请参阅 http://www.hivemq.com/mqtt-essentials-part-6-mqtt-quality-of-service-levels/ )。

我能以某种方式减少这个时间吗？我尝试过 Mosquitto 和 Apache Apollo 代理，它们都复制了相同的结果。

编辑:

我稍微改变了一个测试程序。现在，我在同一台机器上运行了两个 mqtt 客户端实例。一个作为发布者，第二个作为订阅者。发布者以 10 毫秒的间隔发送 1000 条消息，如下所示:

Client publisher = new Client(url, clientId+"pub", cleanSession, quietMode, userName, password);
Client subscriber = new Client(url, clientId+"sub", cleanSession, quietMode, userName, password);
subscriber.subscribe(pubTopic, qos);

while (counter < 1000) {
    Thread.sleep(10,0);
    String time = new Timestamp(System.currentTimeMillis()).toString();
    publisher.publish(pubTopic, qos, time.getBytes());

    counter++;
}

当订阅者只是等待消息并测量时间时:

public void messageArrived(String topic, MqttMessage message) throws MqttException {
// Called when a message arrives from the server that matches any
    // subscription made by the client

    Timestamp tRec = new Timestamp(System.currentTimeMillis());
    String timeSent = new String(message.getPayload());
    Timestamp tSent = Timestamp.valueOf(timeSent);
    long diff = tRec.getTime() - tSent.getTime();
    sum += diff;

    counter++;

    if (counter == 1000) {
        double avg = sum / 1000.0;
        System.out.println("avg time: " + avg);
    }
}

Broker(默认配置的 mosquitto)在同一本地网络中的单独机器上运行。我取得的结果比以前更加离奇。现在，QoS 为 1 的消息到达订阅者大约需要 8-9 毫秒。对于 QoS 2，它大约是 20 毫秒。但是，QoS 为 0 时，我得到了平均值。从 100 毫秒到 250 毫秒!我猜错误出在我的测试方法中的某处，但我看不到哪里。

Answer 1

不需要保留 QoS 0 消息 - 它们可以完全保留在内存中。

为了能够确保 QoS 1(和 QoS 2)传递，消息需要以某种形式持久化。这比简单的网络传输时间增加了消息的额外处理时间。