Потеря данных кэша Azure Redis?

У меня есть приложение Node.js, которое получает данные через соединение Websocket и отправляет каждое сообщение в кеш Azure Redis. Он сохраняет постоянный массив сообщений в переменной для последующего использования и через регулярные промежутки времени синхронизирует этот массив из кэша. Немного запутанно, но позже я хочу отделить половину приложения, которое записывает в кеш, от половины, которое читает из него.

Примерно в 02:00 по Гринвичу, основываясь на статистике портала Azure, я, похоже, начал получать «промахи кеша» при этой синхронизации, которые длятся пару часов, прежде чем я снова начал получать «попадания кеша» где-то около 05:00.

Промахи кеша соответствуют внезапному увеличению загрузки ЦП, которое достигает пика примерно в 05:00. И когда я говорю о пиках, я имею в виду, что он достигает 81% по сравнению с предыдущим максимумом около 6%.

Итак, где-то около 05:00 процессор достигает пика, а затем возвращается к нормальному состоянию, «промахи кэша» исчезают, но, глядя на использование кэш-памяти, я падаю с примерно 37,4 МБ до примерно 3,85 МБ (что, я подозреваю, "пустое" состояние), и список, используемый этим приложением, был пуст.

Единственными функциями, которые приложение выполняет с кешем, являются LPUSH и LRANGE, нет ничего, что имело бы какие-либо возможности для удаления данных, и, если кому-то интересно, когда ЦП увеличил использование памяти, нет ничего, чтобы предположить, что мошенник добавление данных возникло.

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

Все это мой способ спросить:

  1. Кто-нибудь знает, что здесь могло произойти?

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

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

Спасибо заранее..


person James Webley    schedule 28.08.2014    source источник


Ответы (3)


Вот мои мысли:

Кэш Azure Redis хранит информацию в памяти. По умолчанию он не сохраняет «резервную копию» на диск, значит, у вас была информация в памяти, по какой-то причине сервер перезагрузился, и вы потеряли свои данные.

PS: см. этот отзыв, пока нет возможности сохранять информацию на диске с помощью кэша azure-redis http://feedback.azure.com/forums/169382-cache/suggestions/6022838-redis-cache-должен-также-поддерживать-постоянство

person Thiago Custodio    schedule 28.08.2014
comment
Кстати: в памяти все зависит от того, выбрали ли вы базовый или стандартный план. - person Tim Lovell-Smith; 18.09.2014

  1. Убедитесь, что вы не используете базовый план. Базовый план не предполагает SLA и, по моему опыту, довольно часто терял данные.
  2. Стандартный план предоставляет SLA и использует 2 экземпляра Redis Cache. Он достаточно стабилен и не потерял наши данные, хотя такой случай все же возможен.
  3. Теперь, если вы собираетесь использовать Azure Redis в качестве базы данных, а не в качестве кэша, вам необходимо использовать функцию сохранения данных, которая уже доступна на уровне Premium для кэша Azure Redis: https://azure.microsoft..com/en-us/documentation/articles/cache-premium-tier-intro (см. Сохранение данных Redis)
person Vladimir Dorokhov    schedule 19.02.2016

Джеймс, использование экземпляра Standards должно значительно улучшить доступность.

На базовом уровне любое обновление Azure Fabric для главного узла (или сбой оборудования) приведет к потере всех данных.

Кэш Azure Redis пока не поддерживает сохраняемость (запись на диск или большой двоичный объект) даже на уровне "Стандартный". Но уровень Standard дает вам реплицированный подчиненный узел, который может взять на себя управление, если ваш главный узел выйдет из строя.

person Saurabh    schedule 02.09.2014