我们一直在使用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
答案 0 :(得分:0)
持久性数据库中的条目将基于主题的订阅者数量,因为需要为可能处于脱机状态或尚未确认收到消息的每个订阅者跟踪/排队消息。
考虑到您正在讨论的消息速率(特别是如果您正在排队并希望QOS1 / 2级别传送),您可能希望查看处理带外持久性的代理(使用外部数据库后端进行多线程处理的代理)。您描述的情况将意味着需要在重新连接时传递360万条消息以及尝试跟上1k / s消息(这可能意味着在备份时更多排队)
如果您不想将代理更改为多线程,那么您还没有提到存储持久性数据库的文件系统是什么类型?您是否尝试过使用RAM磁盘来改善访问时间,因为它们都在内存中?