Это сложная проблема, связанная с темами MQTT.
У меня есть несколько клиентов MQTT (сенсорных узлов), которые публикуют полученные данные как «_data», мощность сигнала как «_rssi» и время сбора данных «_toc» в своих трех темах.
/node/node_id/data/
/node/node_id/rssi/
/node/node_id/toc/
где "node_id" - идентификатор (целое/число) клиента (узла) (уникальный для узла). Соответствующие полезные данные: _data (данные с плавающей запятой), _rssi (с плавающей запятой) и _toc (дата-время Unix). . Ясно, что все три точки данных связаны друг с другом.
Этот дизайн помогает поддерживать контроль доступа к различным подписчикам в зависимости от тем, на которые им разрешено подписываться.
Тем не менее, есть одна замечательная вещь, связанная с использованием 3 разных тем для каждого узла/клиента: если соединение между клиентом MQTT и сервером прерывается (теряется) сразу после публикации полезных данных «data» и перед публикацией «rssi» и «timestamp». " полезной нагрузки, то это несоответствие между тремя точками данных, сообщение из темы "данные" будет отражать новое значение, в то время как две другие темы будут содержать старые значения ~ потеря целостности.
Я мог бы использовать однострочную тему, например
/узел/идентификатор_узла/данные/_данные/rssi/_rssi/toc/_toc
Or
/узел/идентификатор_узла/(_данные,_rssi,_toc)
И замените _data, _rssi и _toc соответствующими значениями, проанализируйте их и разделите значения. Последний стиль темы, в частности, уменьшает количество раз, когда клиент будет публиковать, экономя на стоимости данных и ошибках целостности. Он также короткий по длине. Но, конечно, это беспорядочно, очень нестандартно по своей природе, и ошибки могут легко возникнуть.
Может ли кто-нибудь предложить промежуточный способ всегда иметь целостность данных и минимизировать количество публикаций, которые должен выполнять клиент, а также поддерживать чистую структуру сообщений. Я определенно предпочел бы целостность данных, но также хотел бы разделить права доступа между подписчиками.