Кэш Azure — как определить, находится ли ключ в кеше?

Есть ли способ с помощью кэширования Azure определить, существует ли в кеше объект, имеющий определенный ключ, без фактического возврата самого объекта?

Я сейчас делаю что-то вроде

    public bool IsKeyInCache(string cacheKey)
    {
        DataCacheItem item = null;
        CacheRetryPolicy.ExecuteAction(() =>
        {
            item = cache.GetCacheItem(cacheKey);
        });

        return item != null;
    }

Но поскольку объект в кеше очень большой и его десериализация требует больших затрат, производительность ужасна.

Я просмотрел документацию MSDN и не вижу альтернативы, но, возможно, я что-то упускаю.

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


person Mr. T    schedule 22.11.2013    source источник
comment
Я кратко расскажу, почему это может быть не реализовано для какого-либо кеша в частности ... просто из-за состояния гонки. Между проверкой существования ключа и чтением значения ключа элемент может быть удален из кэша.   -  person ta.speot.is    schedule 23.11.2013
comment
Q: Почему бы вам просто не спросить значение? Просто любопытно - какой вариант использования для проверки того, находится ли ключ в кеше?   -  person paulsm4    schedule 24.11.2013


Ответы (1)


Я считаю, что API, который вы ищете, это DataCache.Get(key):

Но я по-прежнему считаю, что лучше всего НЕ «микроуправлять» кешем, а просто сделать запрос и позволить Azure принять решение.

ПО МОЕМУ МНЕНИЮ...

person paulsm4    schedule 24.11.2013
comment
DataCache.Get() возвращает элемент, если он находится в кеше. Все, что я хочу, это ответ да/нет относительно того, находится ли указанный ключ в кеше. - person Mr. T; 25.11.2013
comment
И если его нет в кеше, он возвращает NULL. DataCache.Get(key), честно говоря, ваш лучший выбор, даже для логического значения да/нет. ПО МОЕМУ МНЕНИЮ... - person paulsm4; 25.11.2013
comment
Это мой лучший выбор, потому что, по-видимому, это мой единственный выбор. Предположим, я кэшировал очень большой объект. Зачем платить за передачу его из кеша (который может находиться в другом члене кластера) и по сети в мой экземпляр роли, когда все, что я хочу знать, это существует ли этот ключ? - person Mr. T; 26.11.2013