Обеспечение масштабирования не более N экземпляров для определенной очереди.

Question

Моя функция отправляет полезную нагрузку на разные серверы sftp. Эти серверы ограничены в количестве подключений, которые они могут принять.

Мне нужно решение для регулирования наших соединений с этими серверами.

Функция вызывается очередями хранилища, и первый черновик проекта:

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

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

1. Мне нужна функция, чтобы масштабирование не превышало N экземпляров для всех сообщений из очереди X, поскольку сервер sftp X не будет принимать больше N подключений.
2. Кроме того, мне нужно, чтобы функция масштабировалась не более чем до M экземпляров для всех сообщений из очереди Y, поскольку сервер sftp Y не будет принимать более M подключений.

Для приведенного выше сценария общее количество экземпляров будет составлять M + N.

Как настроить наш дизайн, чтобы соответствовать этим требованиям?

Answer 1

Вариант 1: Зависит от ответа об ошибке sftp

Возвращает ли сервер sftp ответ 429 (слишком много запросов)?Или что-то подобное?Получив такой ответ, вы можете просто выйти из функции, не удаляя сообщение из очереди.Через 30 секунд сообщение снова станет видимым и вызовет функцию.30 секунд - это значение по умолчанию visibilitytimeout и настраиваемое при в расчете на мсг.

Опция 2: распределенные блокировки

Я не знаю по началу своей головы решения распределенной блокировки со счетчиками.Альтернативой может быть реализация решения по блокировке самостоятельно с использованием базы данных SQL и атомарных транзакций.Функция при обработке сообщения из очереди X заглядывает в БД, чтобы узнать, меньше ли счетчик блокировки для X, чем N, и увеличивает его на 1, если это так, а затем обрабатывает сообщение.В этом случае вам нужно будет убедиться, что блокировки снимаются даже в случае сбоя вашей функции.То есть реализовать блокировки с истечением срока аренды.

Answer 2

Нет 100% пуленепробиваемого решения, проблема отслеживается здесь .

Наилучшим способом может быть установка WEBSITE_MAX_DYNAMIC_APPLICATION_SCALE_OUT на 1 в настройках приложения-приложения-функции, которое запускается совокупной очередью. Затем вы должны получить только один параллельный экземпляр приложения-функции, поэтому настройка batchSize будет полезна для ограничения скорости.

В этом случае вам не нужно ограничивать процессоры очереди X / Y / Z, пусть сообщения поступают в агрегат.

Теперь я не понял, касаются ли только сообщения из очереди X SFPT X, или это многие ко многим. Если это один на один, имеет смысл избавиться от совокупной очереди, иметь три функции и ограничить параллелизм для каждой из очередей в отдельности.

В любом случае, настройки лимита соответствуют указанным выше.

Если это не отвечает вашим требованиям, вы можете переключиться на другую службу обмена сообщениями. Например, отправьте все сообщения одного типа в отдельный сеанс служебной шины или отдельный раздел концентратора событий, что, естественно, ограничит параллелизм на уровне посредника.