Я создаю решение, которое обрабатывает изменения в записях на основе сообщений, размещенных в очереди служебной шины Azure. Очередь содержит чередующуюся последовательность сообщений для изменений в нескольких разных записях, а функция Azure активируется для каждого сообщения, чтобы обработать изменения и сохранить их во внутренней службе. Каждое сообщение в очереди изменений относится к одной записи и содержит свойство: recordId.
Проблема в том, что при вызове серверной службы с каждым сообщением возникают некоторые накладные расходы, и очень часто несколько сообщений появляются в очереди для отдельной записи в быстрой последовательности. Я хотел бы разрешить несколько изменений для «буферизации» для каждой записи, чтобы серверную службу можно было вызывать реже, но с пакетом изменений.
Я рассматриваю возможность использования функции сеансов служебной шины с функцией Azure, которая отслеживает очередь изменений перед пересылкой каждого сообщения в очередь сеансов, используя в recordIdкачестве имени сеанса. В идеале я бы хотел, чтобы сообщения буферизировались в очереди сеансов до тех пор, пока:
recordId(например, без изменений в течение 10 секунд)Возникает вопрос: как я могу инициировать обработку каждого сеанса на основе этих сценариев? Я рассматривал возможность использования запланированных сообщений для обработки первого сценария, но затем мне нужен надежный способ повторного планирования для создания скользящего тайм-аута. Точно так же, кажется, нет хорошего способа контролировать размер сеанса, кроме сохранения где-то счетчика.
Я пытаюсь решить проблему исключительно с помощью служебной шины и функций, хотя я очень открыт для любых других идей.
Решение проблемы
Существует несоответствие между тем, чего вы хотите достичь, и назначением и возможностями службы. Давайте сначала посмотрим на сеансы.
Сеансы предназначены для обработки сообщений в том порядке, в котором они были отправлены. Это способ, с помощью которого служебная шина Azure предоставляет вам очередь FIFO поверх неупорядоченной очереди, которую вы обычно получаете, и устраняет вероятность того, что конкурирующие потребители обрабатывают сообщения, вызывая неупорядоченную обработку. Сообщения сеанса «исчезают» из очереди, и после того, как последнее из них будет использовано, после настроенного тайм-аута сеанса потребитель сеанса перейдет к следующему доступному сеансу.
Запланированные сообщения — это сообщения, отправленные в будущем, чтобы отложить их обработку. Планирование выполняется для каждого сообщения и не может применяться к группе, такой как сеанс. Конечно, вы могли бы организовать планирование примерно на одно и то же время, но это было бы сложно — как узнать, когда запланировать первое сообщение, если вы еще не получили последнее.
Пакетный прием с функцией — это способ запросить пакетное количество сообщений, но это не значит, что вы получите именно это число. Говорится, что комбинация сеансов и пакетного приема может работать, если все сообщения для сеанса находятся в очереди. Хотя вы можете не обрабатывать все сообщения, связанные с данным сеансом, при выполнении одной функции, вы все равно будете обрабатывать реже и в том порядке, в котором эти сообщения были отправлены.
Подводя итог, вы можете уменьшить количество вызовов функций, установив IsBatchedи на, чтобы сообщения доставлялись пакетами для обработки в том же порядке, в котором они были отправлены.IsSessionsEnabledtrue
Комментариев нет:
Отправить комментарий