dashboard里查看，被丢弃的消息特别多

EMQX
1

版本：4.4.1
OS：Ubuntu 18.04
场景：生产者400+台客户端连接了emqx，每个客户端每隔20s发一次自定义的心跳消息，除此之外还有其他数据消息；消费者使用单个golang客户端去消费，消费者收到消息后，存入长度为10000的channel中，再用60个goroutine来异步地取消息。
问题：dashboard里查看，被丢弃的消息特别多，该修改什么配置来避免消息丢失呢？使用客户端的主动心跳是不被推荐的吗？

image
image1366×840 89.6 KB

2

dropped 指标是 dropped.* 的总和。

你这里面 dropped 大部分是因为 dropped.no_subscribers （37534），意思是没有订阅者所以记录为丢弃，这部分你可以不必关心。

另外有 162 个是因为 dropped.await_pubrel_timeout，意思是等待客户端发送 QoS2 的 PUBREL 消息超时了，一般是客户端的问题，需要你仔细调查一下。emqx 的默认超时时间是：zone.external.await_rel_timeout = 300s

3

好的谢谢。我看publish.dropped的数量也比较大，这个是因为什么原因呢？

4

是因为 emqx 为某些客户端维护的 session 里面，PUBREL 的等待队列满了，后续这个客户端继续发送 QoS2 消息的话，就会被直接丢弃。

每一个客户端在 emqx 里都有一个 session，在 QoS2 场景下 session 需要维护 broker - client 之间整个交互流程的状态。收到 QoS2 PUBLISH 之后，消息的 packetId 会被存储到 session PUBREL 等待队列里，并回复 PUBREC，一直等到客户端发送 PUBREL 之后才会删除该 packetId。如果该队列满了，客户端再发送新的 QoS2 PUBLISH 就会被丢弃，并记录 ‘packets.publish.dropped’。

5

好的非常感谢。
麻烦再问下，增大PUBREL队列的话需要改什么配置项呢？一般推荐相关配置增大到多少合适呢？以及客户端主动发心跳的话，qos2等级合适吗？
是 zone.external.max_mqueue_len 和 zone.external.max_inflight吗？

6

zone.external.max_awaiting_rel = 100 默认的 100 已经足够了，即使再增加也只是推迟问题的发生，不能解决问题。你还是需要调查客户端的问题，你可能需要抓包来调查客户端和 emqx 之间的消息交互过程。

7

好的谢谢