时间戳

首页 > 解决方案 > 查找mqtt持久化中重复的原因

mqtt - 查找mqtt持久化中重复的原因

问题描述

我们一直在使用具有 QOS 1 的发布者-订阅者来检查持久性。mosquitto.db 文件中发布的消息有很多重复（5-7 次）。我们无法理解如此巨大重复的原因。任何相同的输入都是可观的。

我们对重复感到困扰的原因是代理无法处理巨大的负载并在将其推送给重新连接的订户时关闭。

假设我让 P1 向代理推送大约 1k 消息/秒，而 S1 订阅这些消息。我们将 S1 关闭了一段时间，比如说 1 小时，然后使用相同的客户端 ID 再次重新连接。

现在，理想情况下，我的 db 文件中应该有大约 1k*60*60 条消息。但是，我们发现它的数量超过了 5-7 倍。一旦我开始订阅，r/w 就会很大，因此服务器会关闭我的代理。

QOS 2 是我们最坏的情况选择，因此将感谢其他替代方案。

以下是配置：

# Place your local configuration in /etc/mosquitto/conf.d/
#
# A full description of the configuration file is at
# /usr/share/doc/mosquitto/examples/mosquitto.conf.example

pid_file /var/run/mosquitto.pid
max_inflight_messages 1

persistence true
persistence_file mosquitto.db
persistence_location /var/lib/mosquitto/

log_dest file /var/log/mosquitto/mosquitto.log

include_dir /etc/mosquitto/conf.d

password_file /etc/mosquitto/passwd
allow_anonymous false
max_queued_messages 1000000

autosave_interval 30
# autosave_on_changes false

标签： mqttmosquitto

解决方案

持久性数据库中的条目将基于主题的订阅者数量，因为需要为每个可能离线或尚未确认收到消息的订阅者跟踪/排队消息。

鉴于您正在谈论的消息速率（特别是如果您正在排队并且想要 QOS1/2 级别的交付），您可能想要查看一个处理带外持久性的代理（带有外部数据库后端的多线程）。您描述的情况意味着需要在重新连接时传递 360 万条消息，并试图跟上 1k/s 消息（这可能意味着在备份时需要更多排队）

如果您不能/不想将代理更改为多线程，那么您还没有提到您将持久性数据库存储在哪种文件系统上？您是否尝试过使用 RAM 磁盘来改善访问时间，因为它都在内存中？

推荐阅读