Как кэшировать данные между Azure экземплярами оркестровки устойчивой функции?

Question

В документации указано, что Azure код оркестровки Durable Function должен быть определен c по количеству повторов. В моем случае у меня есть данные в Azure Table Storage, которые мне нужно получить в рабочем процессе. Рабочий процесс является рекурсивным, и данные в Azure Table Storage могут изменяться во время выполнения, и вполне нормально иметь устаревшее состояние в течение ~ 1 минуты. В обычном коде я бы полагался на кеш памяти для повышения производительности. Но в оркестровке, предположим, его нельзя использовать напрямую, потому что это делает рабочий процесс недетерминированным c.

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

Итак, у меня есть вопрос, есть ли какой-либо шаблон, который можно использовать для кэширования данных между экземплярами оркестрации в памяти, без включения этого logi c в действие?

Answer 1

Вы можете хранить данные между оркестровками с помощью функций сущностей.

https://docs.microsoft.com/en-us/azure/azure-functions/durable/durable-functions-entities

И иметь возможность выполнять 64 операции в секунду.

https://docs.microsoft.com/en-us/azure/azure-functions/durable/durable-functions-perf-and-scale#performance -цели

Answer 2

Что я могу вам предложить: используйте распределенный кеш, в частности Redis Cache для Azure.

Я нарисовал для вас изображение:

Получите данные из Azure Table Storage в вашей оркестровке, выполните там свою операцию и сохраните их в кеш Redis. Затем передайте идентификатор необходимых данных каждому действию. Затем вы можете получить данные из кеша Redis внутри каждого действия.

Это решение с кешем, как вы просили. Однако учтите, что если вам нужен высокопроизводительный запрос данных, Azure Table Storage - не лучшее решение для работы. Я предлагаю вам использовать Azure SQL или CosmosDB. Но если вы ищете дешевый вариант, это нормально. Но в этом случае кеш Redis вам не подойдет, потому что это тоже не дешевое решение. Если этот кеш Redis вам не подходит, я предлагаю вам пересмотреть свой алгоритм.

Удачи!