#azure #session #azure-functions #azureservicebus #azure-iot-hub
#azure #сеанс #azure-функции #azureservicebus #azure-iot-hub
Вопрос:
Мы разрабатываем приложение на основе среды выполнения Azure Edge. Наше приложение отправляет сообщения вверх по потоку в облако, в IoT hub, который, в свою очередь, имеет определенные маршруты, которые отправляются в разные очереди служебной шины. Вот простое изображение:
В одной из этих очередей мы заботимся о сеансах, что означает, что нам нужно массово получать и обрабатывать каждое событие по порядку в нашей функции. Проблема, которую мы заметили, заключается в том, что когда наше приложение создает события в быстрой последовательности, это происходит:
- Поступает первое событие
- Модель, извлеченная из базы данных, которая соответствует данным события
- Модель обновлена
- Модель помещается в исходящую привязку Cosmos
- Перед запуском привязки cosmos out приходит следующее событие, сохраняя функцию включенной
- Модель, извлеченная из базы данных, которая соответствует данным о событиях до сохранения данных предыдущих событий, что означает, что мы действуем с уже устаревшими данными
Я изучил сеансы очереди служебной шины, которые, похоже, решают эту проблему, но сеансы несовместимы с IoT Hub. Мы также не создаем сообщение, помещенное в очередь, мы создаем сообщение IoT Hub, а концентратор, в свою очередь, создает сообщение служебной шины, поэтому обработка сеанса находится вне нашего контроля.
Как я мог бы обработать этот шаблон без функции сеанса очереди служебной шины?
Комментарии:
1. Приходят ли события, которые вы пытаетесь упорядочить, с одного и того же устройства? таким образом, вы ожидаете, что сообщения, поступающие с одного и того же устройства, обрабатываются последовательно или все события со всех устройств должны обрабатываться последовательно?
2. Все сообщения поступают с одного устройства, и у нас есть четкое начало и конец последовательности. Сообщения, которые нам нужно обрабатывать последовательно, будут поступать в одну и ту же очередь служебной шины. Мы временно решили эту проблему, отказавшись от использования привязки out функции и вместо этого внедрив Cosmos Node SDK для записи и блокировки во время записи до завершения работы функции.
3. Это именно то, что я хотел предложить в качестве варианта A. Возможно, вариант B может заключаться в том, что вместо функций и очередей служебной шины вы направляете сообщение в центр событий. Количество разделов должно соответствовать количеству разделов с IoT Hub. Существует функция хеширования, которая гарантирует доставку в один и тот же раздел всегда с одного и того же идентификатора устройства. Теперь, если вы реализуете обработку сообщений «вручную» из EH и вручную поддерживаете смещения и порядковые номера, вы можете в значительной степени контролировать, когда будет обработана следующая последовательность сообщений, и, следовательно, поддерживать согласованность.