2015-07-13 6 views
2

EDIT2: Уточнение: код УЖЕ обновил кеш при пропущенной логике. То, что я пытаюсь сделать, - уменьшить количество пропущенных кеш-запросов.Обновление кэш-памяти Redis

Я использую Redis в качестве кеша для API. Идея состоит в том, что когда API получает вызов, он сначала проверяет кеш, и если данные не находятся в кеше, API будет извлекать его и кэшировать его впоследствии в следующий раз.

На данный момент конфигурация выглядит следующим образом:

maxmemory 50mb 
maxmemory-policy allkeys-lru 

То есть, использовать в большинстве 50Мб памяти, продолжайте пробовать ключи там и когда память заполнена начала, удалив наименее недавно использованные ключи (LRU) ,

Теперь я хочу ввести вторую категорию ключей. Для этой второй категории я собираюсь установить определенное время истечения срока действия. Теперь я хотел бы создать такой механизм, чтобы, когда эти ключи истекают, этот механизм запускает и обновляет их (и устанавливает новый срок действия).

Как это сделать?

EDIT: Некоторые успехи. Оказывается, у Redis есть система обмена сообщениями/суб-сообщениями, которая, в частности, может отправлять сообщения на событие. Один из них истекающих ключей, которые могут быть включены в качестве такового:

notify-keyspace-events Ex 

Я нашел этот код может описывает блокирующий python process subscribing to Redis' messaging system. Он легко может быть изменен для обнаружения ключей, истекающих и выполняющих вызов API, когда истекает срок действия ключа, а затем API обновит ключ.

def work(self, item): 
    requests.get('http://apiurl/?q={param}'.format(param=item['data'])) 

Так что это делает именно то, о чем я просил.

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

Итак, что лучше?

+0

Уведомления о ключах, такие как Redis PubSub, не гарантируются, например, если ваш рабочий отключен, вам не будут доставлены сообщения. Я по-прежнему рекомендую включить в свой код логику обновления в пропуске. –

+0

Как я уже сказал, в моем коде уже есть логика refresh-catche-on-miss, и я пытаюсь это сделать, избегая промахов. Кроме того, это кеш: если уведомление потеряно, ну, мы не обновим этот ключ, и он будет обновлен, когда он будет пропущен. Но, надеюсь, мы можем избежать этого. – oneloop

ответ

0

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

+0

Это не решает мою проблему, так как пропавших кеш-хитов именно то, чего я пытаюсь избежать. – oneloop

+0

У вас всегда будут недостатки в кеше, если только ваш кеш не будет достаточно большим, чтобы удерживать весь бит. –

0

http://redis.io/topics/notifications

уведомление позволяет клиентам пространства ключей подписаться Pub/Sub каналов для того, чтобы получать события, влияющие на данные Redis, установленные в некотором роде. Примеры событий, которые можно получить следующие:

Все ключи истекающий в базе данных 0 (например)

...

EXPIRE генерирует истекают событие когда истекает срок действия ключа, или с истекшим событием каждый раз, когда истекает срок действия ключа с удалением ключа (дополнительную информацию см. в документации EXPIRE).

+0

Я только что редактировал свой вопрос, чтобы включить то, что вы только что сказали (пожалуйста, проверьте). Чувствуется немного из-под контроля, хотя. – oneloop

+0

Потому что это синхронно? – Niloct

+0

Пара проблем с моей головы. A) если TTL одинаково для каждой клавиши, а количество ключевых раз, время, необходимое для выполнения вызова для ключевого ключа, длиннее, чем TTL, этот процесс никогда не закончится, и на самом деле очередь будет просто наращиваться. B) что, если слишком много ключей истечет одновременно? Снова очередь складывается. – oneloop

Смежные вопросы