Поиск причины дублирования в сохранении mqtt - PullRequest
0 голосов
/ 30 мая 2018

Мы использовали издателя-подписчика с QOS 1 для проверки персистентности.У нас много дублирования в опубликованных сообщениях в файле mosquitto.db (5-7 раз).Мы не можем понять причину такого огромного дублирования.Любые входные данные по этому поводу были бы заметны.

Причина, по которой нас беспокоит дублирование, заключается в том, что брокер не может справиться с огромными нагрузками и отключается, передавая его повторно подключенному абоненту.

Скажем, у меня есть P1, который проталкивает около 1 000 сообщений в секунду брокеру, и S1 подписывается на них.Мы отключаем S1 на некоторое время, скажем, 1 час, и снова подключаемся с тем же идентификатором клиента.

Теперь, в идеале, мы должны иметь около 1k * 60 * 60 сообщений в моем файле базы данных.Однако мы выяснили, что оно имеет более чем 5-7 раз больше числа.Как только я начинаю подписку, количество ч / б огромно, и, следовательно, сервер закрывает моего брокера.

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

1 Ответ

0 голосов
/ 30 мая 2018

Записи в персистентной базе данных будут основаны на количестве подписчиков на тему, поскольку сообщения необходимо отслеживать / ставить в очередь для каждого подписчика, который может быть отключен или еще не подтвердил получение сообщения.

Учитывая скорость сообщений, о которой вы говорите (особенно если вы в очереди и хотите доставку на уровне QOS1 / 2), вам может понадобиться посмотреть на брокера, который обрабатывает персистентность вне диапазона (что-то многопоточное с внешним бэкэндом БД),Ситуация, которую вы описываете, будет означать 3,6 миллиона сообщений, которые необходимо доставить при повторном подключении, а также попытаться не отставать от сообщения 1k / s (что может означать увеличение очередей при резервном копировании)

Если выне можете / не хотите изменить посредника на что-то многопоточное, вы не упомянули, на какой файловой системе вы храните постоянную базу данных?Вы пробовали смотреть на использование RAM-диска, чтобы улучшить время доступа, как это было бы в памяти?

...