У меня есть azure function, который я хочу обработать несколько сообщений в parallel, но чтобы сообщения с одинаковым Person Id выполнялись singleton.
Сценарий 1: У меня есть n количество сообщений, каждое из которых имеет одинаковый Person Id.Каждое сообщение должно быть выполнено в той последовательности, в которой оно было получено, но singleton.
Сценарий 2: У меня n количество сообщений.Некоторые из них имеют Person Id:1.Некоторые из них имеют Person Id:2.Сообщения с разными личными идентификаторами могут быть выполнены в parallel, но сообщения с одинаковыми Person Id должны выполняться в той последовательности, в которой они поступили, и singleton способом.
Как этого добиться?
Редактировать: Мое приложение работает на Consumption Plan, поэтому я не могу предсказать, как и когда мое приложение будет масштабироваться.Функция Azure изначально получает аренду для всех разделов.Похоже, что функция Azure изначально получает аренду для всех разделов, когда приложение не масштабируется.Решение, предложенное @juunas в комментариях, беспокоит меня, что мое приложение никогда не масштабируется и может закончить выполнение пакетов последовательно одним экземпляром функции Azure, потому что моя функция не будет получать миллионы точек данных последовательно.Эвристика для масштабирования под Consumption Plan не известна.
Возможно, каким-то образом объединить концентратор событий в упорядоченной гарантии с долговечными функциями параллельного шаблона?
Редактировать 2:
Рассмотрим две функции:
Appender Функция: Поддерживает упорядоченный список в cache, добавляя Person Id вместе с любым другим обязательным атрибутом.Не обязательно функция Azure. Processor Функция: Использовать долговременную функцию Singleton Pattern (также может хранить информацию о Идентификаторе человека, который обрабатывается в cache)
Поток:
Appender, после добавления, отправляет сообщение на queue с только Person Id в сообщении.Person Id будет использоваться как instance id, как упомянуто в документации . Processor, если экземпляр функции еще не существует, начнется выполнение определенного Person Id сообщений в кеше. - Если экземпляр
Processor уже существует, сообщение будет проигнорировано.
Проблема:
Сценарий, в котором Processor полностью опустошает кэшированное Person Id упорядоченное сообщение, но параллельно Appender добавляет другое сообщение до выхода Processor, поэтому новое сообщение не выполняется.Теперь кэш будет содержать 1 сообщение, необработанное, и не будет вызываться никакая функция azure для его обработки, пока Appender не добавит еще одно сообщение того же Person Id.
. Может быть, я должен использовать Durable Function Monitor Как-то по шаблону?
Редактировать 3: Другим подходом, который я рассмотрел, было использование шаблона Monitor.Вместо того чтобы игнорировать сообщение, если выполняется функция с определенным instance id, оно будет ожидать через определенные промежутки времени.Само сообщение очереди будет просто Person Id с другими его атрибутами, расположенными в упорядоченной последовательности в cache.Это гарантирует, что каждое сообщение будет выполнено в правильной последовательности (используя список, поддерживаемый в cache).Однако при использовании подхода с монитором вместе с очередью может возникнуть следующая проблема, упомянутая в примере синглтона :
В этом примере существует потенциальное состояние гонки.Если два экземпляра HttpStartSingle выполняются одновременно, оба вызова функций сообщат об успешном выполнении, но фактически будет запущен только один экземпляр оркестрации.В зависимости от ваших требований, это может иметь нежелательные побочные эффекты.По этой причине важно убедиться, что никакие два запроса не могут выполнять эту триггерную функцию одновременно.
Другой подход, который я рассмотрел, заключался в использовании шаблона монитора для выполнения только одного сообщения на функцию путем объединения Редактировать подход 2 Appender вместе с одноэлементным шаблоном, используя идентификатор экземпляра.