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

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

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

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

введите здесь описание изображения

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

введите здесь описание изображения

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

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

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

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


person Alex Gordon    schedule 09.07.2019    source источник


Ответы (2)


Для этого нет стопроцентного надежного решения, проблема отслеживается здесь.

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

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

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

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

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

person Mikhail Shilkov    schedule 09.07.2019
comment
спасибо! к сожалению, я не могу принять ваше предложение have three Functions and limit the concurrency for each of the queues separately., потому что у меня может быть 100 очередей для 100 разных направлений - person Alex Gordon; 09.07.2019
comment
ну, может быть, это было бы трудно управлять, но это могло бы работать и для 100 :) Если вы объедините все 100 в один агрегат, я не думаю, что вы сможете ограничить все из них, чтобы они соответствовали точному лимиту каждого пункта назначения. . Вместо этого вам придется установить очень консервативные значения и оставить выбросы для повторных попыток. - person Mikhail Shilkov; 09.07.2019
comment
поэтому вы предлагаете создать 100 очередей со 100 функциональными приложениями, установив для WEBSITE_MAX_DYNAMIC_APPLICATION_SCALE_OUT значение 1 для каждого отдельного функционального приложения, верно/? - person Alex Gordon; 09.07.2019
comment
Я думаю, возможно, это проблема с долговременной функцией? какие-либо другие указания по этому поводу? я очень застрял в том, что делать, я прочитал десятки ваших сообщений и сотни других и действительно не могу придумать подходящее архитектурное решение, я открыт для любых предложений, возможно, в этом случае будет полезен концентратор событий? но не уверен - person Alex Gordon; 09.07.2019
comment
100 очередей возможны, но звучат сложно. прочный может быть одним из подходов, хотя мне придется подумать о точном подходе. сколько сообщений в секунду обрабатывают эти очереди? как насчет служебной шины или концентраторов событий, которые я предложил? - person Mikhail Shilkov; 09.07.2019
comment
как служебная шина или концентраторы событий могут помочь гарантировать, что только X экземпляров будет запущено для определенного места назначения? - person Alex Gordon; 09.07.2019
comment
Вы можете изменить интеллект на стороне отправителя и распределить сообщения между сеансами. В этом случае функции не будут обрабатывать несколько сообщений одного и того же сеанса параллельно. Таким образом, максимальный параллелизм ограничен количеством сеансов. - person Mikhail Shilkov; 09.07.2019
comment
Итак, вы говорите, что отправитель будет собирать ровно столько сообщений, которые должны быть обработаны за один раз, а получатель заберет этот пакет в session, что означает 1 экземпляр за сеанс, верно? - person Alex Gordon; 09.07.2019
comment
Нет, отправителю просто нужно отправить все сообщения X в сеанс X1, X2, X3, тогда у вас не будет больше 3 обработчиков для X. Мы приближаемся к лимиту комментариев, возможно, добавить отдельный подробный вопрос для тех, - person Mikhail Shilkov; 09.07.2019
comment
спасибо! я смотрю на концентраторы событий, где у меня сначала будет функция, которая объединяет большие двоичные объекты в пакеты, затем эта функция будет иметь выходную привязку к концентраторам событий, затем это событие будет похоже на EventData[] триггер для другой функции, которая будет быть долговечным, и он повторяет и разветвляет фактическую загрузку - person Alex Gordon; 10.07.2019
comment
я все еще ничего не знаю о вашем решении для служебной шины; однако похоже, что это будет похоже на концентраторы событий - person Alex Gordon; 10.07.2019
comment
Чтобы исправить немного: вам не понадобятся 100 функциональных приложений. Вам нужно 100 функций в 1 приложении-функции, при этом для параметра WEBSITE_MAX_DYNAMIC_APPLICATION_SCALE_OUT установлено значение 1. Вероятно, немного проще управлять, чем 100 приложениями. - person Turbo; 21.07.2019

Вариант 1. Зависит от ответа SFTP на ошибку

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

Вариант 2. Распределенные блокировки

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

person Turbo    schedule 21.07.2019