Параллельные устойчивые функции Azure

У меня есть новая долговечная функция, заменяющая длительную веб-задачу, она работает хорошо и быстрее, чем предыдущая, но у меня проблема с параллелизмом.

Я понимаю, что все действия относятся к центральному рабочему элементу Q, это означает, что элементы обрабатываются по порядку, проблема, с которой я столкнулся, заключается в том, что если есть 10 элементов в бэклоге от пользователя A, а пользователь B что-то отправляет, то пользователь B должен подождать пока все данные от пользователя А не закончат обработку.

С текущими веб-заданиями мы можем автоматизировать масштабирование, и новое веб-задание будет собирать данные для пользователя B и обрабатывать их параллельно с существующей обработкой.

Правильно ли я считаю, что единственный способ обойти это - опубликовать 2 копии моей функции, по одной для каждого пользователя / клиента, чтобы гарантировать, что на одного пользователя не влияет накопление данных другого пользователя?

Я попытался разбить вещи на рабочий элемент Q, чтобы ни одна задача не поместила больше, чем X элементов на Q, чтобы теоретически было некоторое совместное использование ресурса, но это просто замедляет работу, так как тогда на рабочем элементе Q их меньше, и поэтому Автоматическое масштабирование плана потребления увеличивается очень медленно из-за меньшего объема рабочего элемента Q.

ОБНОВЛЕНИЕ

Я должен был быть более ясным в отношении того, почему я вижу проблему, прибл. Процесс Durable Function выглядит следующим образом:

  • Разбить файл на страницы
  • Fan Out, указав действие на Q для каждой страницы
  • Вентилятор в
  • Разветвление: размещение другого действия на Q для каждой страницы (для запуска требуются данные из предыдущего разветвления)
  • Вентилятор в
  • Вставить информацию о страницах в БД за одну транзакцию
  • Отметить файл как обработанный в БД

Таким образом, пользователь A загружает файл 1, содержащий 1000 страниц, затем пользователь B загружает файл со 100 страницами.

Хотя я ценю, что он обрабатывает действие Q параллельно, он по-прежнему выполняет действия по порядку (я предполагаю), поэтому, если в Q для файла пользователя A при запуске файла пользователя B есть 1000 элементов, тогда начальные 100-страничные действия получают включают активность Q после 1000 и, следовательно, "блокируются" ими. Тогда к тому времени, когда будут выполнены 100 действий на начальной странице, есть большая вероятность, что следующее разветвление для 1000-страничного документа добавит больше элементов в действие Q, снова блокируя продвижение 100-страничного документа.

Моя проблема заключается в том, что пользователь A и B могут быть двумя разными клиентами, которые не ожидают, что их работа будет заблокирована обработкой другого клиента, поэтому мой комментарий о наличии дублированных экземпляров функции Durable и посредничестве сообщений между несколькими экземплярами

В этом есть немного больше смысла?


person Simon    schedule 15.06.2018    source источник


Ответы (1)


Это правда, что действия попадают в центральную очередь рабочих элементов, но они не обрабатываются по порядку. Фактически они будут обрабатываться параллельно. Единственный способ, которым все будет обработано по порядку, - это если есть только одна функция оркестратора, и она намеренно упорядочивает их (см. связывание функций).

Если работа для пользователя A и пользователя B выполняется с использованием разных экземпляров оркестровки, или если это единственный экземпляр, который использует fan-out, fan-in pattern, тогда вы получите распараллеливание, и вам не придется беспокоиться о блокировке одним пользователем Другая.

Кроме того, к вашему сведению, вы можете настроить степень параллелизма с помощью host.json. Более подробную информацию можно найти здесь: https://docs.microsoft.com/en-us/azure/azure-functions/durable/durable-functions-perf-and-scale#concurrency-throttles

ОБНОВИТЬ

Это правда, что очередь является общей, и большие задержки в одной оркестровке могут вызвать задержки в другой оркестровке. В этом случае есть два возможных решения:

  1. Добавьте больше экземпляров приложения-функции, чтобы быстрее обрабатывать невыполненные задания. Это делается автоматически в плане потребления Функций Azure и выполняется постоянно, пока задержка для этой общей очереди не станет достаточно низкой.
  2. Создайте отдельное приложение-функцию со вторым центром задач для заданий с разным приоритетом. Даже если вы используете одну и ту же учетную запись хранения, каждый центр задач будет иметь свой собственный набор очередей, поэтому большая нагрузка на одно приложение не повлияет на другое.

Я понимаю, что это не идеальные решения, потому что они не обязательно гарантируют справедливость. Если справедливость является строгим требованием, то, возможно, потребуется добавить новые функции для ее поддержки (кстати, запросы функций можно сделать в Репозиторий надежных функций на GitHub.

person Chris Gillum    schedule 01.03.2019
comment
Привет, я обновил исходный вопрос, добавив больше информации, чтобы, надеюсь, прояснить, почему я вижу этот эффект блокировки, хоть убей, я не могу придумать хитрый способ обойти эту полосу развертывания дублирующих функций - person Simon; 03.03.2019
comment
Спасибо @Simon, теперь я думаю, что понял. Я обновил свой ответ на основе ваших обновлений. - person Chris Gillum; 05.03.2019
comment
Спасибо, кстати, я думаю о том, какая функция имеет смысл для достижения этой цели. - person Simon; 28.03.2019
comment
@ChrisGillum, не могли бы вы объяснить вариант 1? Что означает создание дополнительных экземпляров приложения-функции? Кроме того, я предполагаю, что если я использую гибкий план, поведение будет таким же? - person dmbaker; 24.11.2020