使用Java V2 AWS IoT Core SDK发消息丢包是否为限流问题及排查方法

是否为限流导致 #

该现象大概率和AWS IoT Core的限流规则相关，你可以先对应几个核心限流阈值做初步排查：

• AWS IoT Core针对单MQTT连接的入站消息吞吐量有默认配额：标准账户单连接每秒最多处理100条QoS 0消息、50条QoS 1消息、10条QoS 2消息，如果短时间内一次性推送500条消息，超过阈值的部分会直接被服务端丢弃
• 你的账号在对应区域的区域级发布消息TPS配额如果被其他业务占用，也会挤占测试场景的可用流量配额
• 若订阅端使用了大量通配符主题，还可能触发单订阅规则的消息投递限流

如何验证消息是否被限流 #

你可以通过以下几种方式确认：

1. 捕获SDK发布端的限流异常 #

Java V2 AWS IoT Core SDK的发布回调会返回服务端的限流错误，你可以给publish方法添加异常回调，捕获ThrottlingException类型的异常，出现该异常即可确认触发了服务端限流：

mqtt3Client.publish(publishRequest)
    .whenComplete((response, throwable) -> {
        if (throwable != null && throwable.getCause() instanceof ThrottlingException) {
            System.out.println("消息被限流：" + throwable.getMessage());
        }
    });

2. 查看CloudWatch对应指标 #

在AWS控制台CloudWatch服务中查看IoT Core的两个核心指标：

• Publish.Throttle：服务端因限流拒绝的发布请求总数
• Publish.Incoming.Success：服务端成功接收的发布请求总数
  对比你发送的500条消息，如果Publish.Incoming.Success数值在320左右，同时Publish.Throttle有对应180左右的计数，即可确认是服务端发布限流导致。

3. 降低发送速率反向验证 #

将发布速率调整到每秒30条QoS 1消息的水平，重新发送500条测试，如果此时所有消息都成功抵达，即可反向验证之前的问题是限流导致。

补充说明：如果调整速率后依然有消息丢失，需要排查客户端侧问题，比如订阅端消息处理速度跟不上导致本地缓冲区溢出丢弃消息，或者发布端连接不稳定触发断连重连导致未确认的消息丢失。

内容的提问来源于stack exchange，提问作者jacob