#azure #caching #azure-service-fabric #azure-redis-cache
#azure #кэширование #azure-service-fabric #azure-redis-cache
Вопрос:
Я работаю над проектом, в котором я буду вызывать методы Service Fabric и возвращать данные конечному пользователю. Данные изменяются очень редко или почти постоянно, поэтому я хочу сохранить кэш и вернуть его, если данные не были изменены.
Структура проекта такова: WepApi (Служба без состояния) -> Репозиторий -> SatefulService
Каков наилучший способ реализовать это в Azure Service Fabric? Я думаю о двух вариантах:
- Кэш Redis a. Создание проекта кэша Redis, в котором будут предоставлены две конечные точки для хранения и получения данных кэша. На этот проект будут ссылаться на уровне репозитория. б. Создание службы кэша Redis ( service fabric) и вызов из репозитория.
- служба с отслеживанием состояния a. Создать отдельный словарь в существующей службе с отслеживанием состояния и использовать его для получения и хранения данных.
И у меня также возникают вопросы ниже.
Подход № 1:
- Мы должны зависеть от сторонней системы (кэш Redis), и мы можем не получить точных результатов, если сервер недоступен.
Подход № 2:
- Мы могли бы получить проблемы с производительностью, если данные кэша увеличивается с течением времени.
Какие-либо наилучшие подходы к внедрению кэша в service fabric?
Спасибо,
Комментарии:
1. Мы могли бы столкнуться с проблемой производительности, если данные кэша увеличиваются с течением времени. -> почему? в чем причина этого предположения? Единственный недостаток, который я вижу, заключается в том, что из коробки нет удаления кэша
2. О каких данных мы говорим? Какой объем / размер?
3. Я мог бы получить список записей, и количество было бы не более 10000 записей. Каждая запись может иметь 10-20 свойств
4. Я выполняю запрос linq для двух коллекций и сохраняю его в Redis или collection. Данные, которые я храню, могут быть одной записью или несколькими записями.
5. Вы думали о . кэш чистой памяти? learn.microsoft.com/en-us/aspnet/core/performance/caching /…
Ответ №1:
Надежные коллекции были разработаны для повышения производительности, поскольку они выполняются в процессе, а данные хранятся в памяти, если имеется достаточно доступной памяти (что в вашем случае должно быть в порядке, для десяти тысяч записей). Единственное замедление по сравнению с обычным словарем в памяти заключается в том, что надежный словарь должен поддерживать согласованность транзакций во время чтения, но я полагаю, вам все равно нужна эта согласованность?
Комментарии:
1. Проблема, с которой я столкнулся с надежными коллекциями, заключается в том, что нет способа выполнять массовые операции с ними. Итак, если у вас есть более 100 тысяч записей, которые вы хотите быстро вводить и выводить, удачи, вы в значительной степени облажались. Я нахожусь в процессе реализации этого сложного способа, рассматривая возможность установки memcache на своих виртуальных машинах кластера, чтобы иметь что-то, что может обрабатывать массовые данные, но при этом быть локальным для моего кода обработки для быстрого извлечения и сохранения массовых обработанных данных.