795 профессионалов IT в этом Telegram чате. “ы с нами?

ћерион Ќетворкс

5 минут чтени€

ƒруг, начнем с цитаты:

Redis Ц это высокопроизводительна€ Ѕƒ с открытым исходным кодом (лицензи€ BSD), котора€ хранит данные в пам€ти, доступ к которым осуществл€етс€ по ключу доступа. “ак же –едис это кэш и брокер сообщений.

Ќадо признатьс€, определение не дает точного понимани€, что же такое Redis. ≈сли это так круто, то зачем вообще нужны другие Ѕƒ? Ќа самом деле, Redis правильнее всего использовать в определенных кейсах, само собой, зна€ про подводные камни Ц именно об этом и поговорим.


Redis как база данных

√оворим про случай, когда Redis выступает в роли базы данных:

Redis как база данных

ѕару слов про ограничени€ такой модели:

  • –азмер Ѕƒ ограничен доступной пам€тью
    • Ўардинг (техника масштабировани€) ведет к увеличению задержки
  • Ёто NoSQL - никакого €зыка SQL
    • LUA скриптинг в качестве альтернативы
  • Ёто нерел€ционна€ —”Ѕƒ!
  • Ќет сегментации на пользователей или группы пользователей. ќтсутствует контроль доступа
    • ƒоступ по общему паролю. „то скажут ваши безопасники?

“еперь про преимущества модели:

  • —корость
    • ’ранение данных в пам€ти делает быстрее работу с ними
  • —крипты на LUA
    • ¬ыполнение пр€мо в пам€ти, оп€ть же, ускор€ет работу
  • ”добные форматы запросов/данных
    • Geospatial Ц геоданные (высота, ширина, долгота и так далее)
    • Hyperloglog Ц статистическе алгоритмы
    • Hash Ц если коротко, то хэш в Redis делают между строковыми пол€ми и их значени€ми
  • јлгоритмы устаревани€ данных

ѕримеры использовани€

ѕредставь, у нас есть приложение, где пользовател€м необходимо авторизоватьс€, чтобы выполн€ть какие Ц либо действи€ внутри приложени€.  аждый раз, когда мы обновл€ем авторизационные данные клиента, мы хотим их получать дл€ последующего контрол€.

ћы могли бы отправл€ть лист авторизационных параметров (с некими номерами авторизаций, сроком действи€ с соответствующими подпис€ми), чтобы каждое действие внутри приложени€, сопровождалось авторизацонной транзакцией из листа, который мы прислали клиенту. — точки зрени€ безопасности, в этом подходе нет ничего плохого, если мы храним на своей стороне данные в безопасности и используем Javascript Object Signing and Encryption (JOSE), например. Ќо проблема по€витс€ в том случае, когда наш пользователь имеет более одной авторизации внутри приложени€ Ц такие схемы плохо поддаютс€ масштабированию.

ј что если вместо отправки листа авторизационных параметров, мы сохраним его у себ€, а пользователю отправим некий токен, который они должны отправл€ть дл€ авторизации? ƒалее, по этому токену, мы легко сможем найти авторизации юзера. Ёто делает систему гораздо масштабируемой. Redis, такой Redis.

»того, дл€ указанной выше схемы, мы хотим:

  • —корость
    • ћы не хотим, чтобы пользователь долго ожидал авторизации
  • ћасштабирумость системы
  • —опоставление ключа (токена) с авторизаци€ми юзера

ј вот, что на эти вызовы может ответить Redis:

  • Redis хранит данные в пам€ти Ц он быстрый.
  • Redis можно кластеризовать через компонент Sentinel. ћасштабируемость? ѕожалуйста.
  • ¬ Redis куча вариантов хранени€ списков. —амый простой будет €вл€тьс€ набором данных.

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


Redis как кэш!

Redis почти заменил memcached в современных приложени€х. ≈го фичи делают супер Ц удобным кэширование данных.

Redis как кэш

ќграничени€:

  • «начени€ не могут превышать 512 ћЅ
  • ќтсутствует искусственный интеллект, который будет очищать ваше хранилище данных

ѕрофит:

  • —овместное использование кэша разными сервисами по сети
  • ”добные фичи, такие как LUA скриптинг, который упрощает работы с кэшом
  • ¬ременные ограничени€ дл€ данных

≈ще один кейс

ѕредположим, перед нами така€ задача: приложение, отображает пользовател€м данные с определенными значени€ми, которые можно сортировать по множеству признаков. ¬се наши данные хран€тс€ в Ѕƒ (например, MySQL) и показывать отсортированные данные нужно часто. ƒергать Ѕƒ каждый раз весьма т€жело и ресурсозатратно, а значит, нам нужно кэшировать данные в отсортированном пор€дке.

ќкей, кейс пон€тен. –эдис, что скажешь на такие требовани€?

  •  эш должен хранить сортированные наборы данных
  • Ќам нужно вытаскивать наборы данных внутри наборов данных (дл€ пагинации, например, то есть дл€ переключени€ между страницами)
  • Ёто должно быть быстрее, чем пересчет данных с нул€

„то скажет Redis:

  • ’ранить наборы данных - легко
  • ћожет вытаскивать сабсеты из наборов - легко
  •  онечно быстрее. ¬едь данные хран€тс€ в пам€ти

Redis как брокер сообщений

–едис может выступать в качестве брокера сообщений. —хема обычна€ и весьма базова€ - publishЦsubscribe (pub/sub), или как можно перевести на русский €зык Ђ»здатель - подписчикї.

Redis как брокер сообщений

 ак и раньше, давайте обсудим плюсы и минусы, хот€ их тут и не так много. ћинусы:

  • “олько тривиальна€ модель pub/sub
  • ќтсутствие очередей сообщений

Ќу а плюсы, как обычно дл€ –едиса Ц скорость и стабильность.


 ейс напоследок

ѕростой пример Ц коллабораци€ сотрудников одной компании. ѕредположим, у них есть приложение, где они работают над общими задачами.  аждый пользователь делает свой набор действий, о котором другие пользователи должны знать. ј так же, юзеры могут иметь разные экземпл€ры приложений Ц десктоп, мобильный или что то еще.

“ребовани€ по этой задаче:

  • Ќизка€ задержка
    • ћы не хотим иметь трудности в процессе совместной работы сотрудников
  • —табильна€ работа и непрерывность
  • ћасштабирование
    •  ампани€ растет и развиваетс€

–едис, твой выход!

  • Ќизка€ задержка Ц да, говорили об этом ранее
  • —табильность Ц минимальное количество точек отказа в Redis
  • —табильна€ работа и непрерывность
  • ћасштабирование Ц сделаем кластер, нет проблем.

¬ыводы

Redis - крута€ штука, котора€ позвол€ет объедин€ть сервисы и следовать 12 принципам приложений. ƒл€ приложений, в которых нагрузка ориентирована на быстрое изменение наборов данных и высока€ безопасность данных не имеет завышенных требований Ц Redis прекрасный выбор.

≈сли данные нуждаютс€ в усиленной защите, –едис подойдет в меньшей степени, лучше посмотрите в сторону MongoDB или Elasticsearch.


ѕолезна ли ¬ам эта стать€?


Ёти статьи могут быть вам интересны: