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

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

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

Сила доброго имени

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

Видите ли, этот удивительный «словарь в памяти» невероятно оптимизирован для работы с ключами в том смысле, что он может обращаться к ним и даже устанавливать их с помощью операций O (1), и он даже может перечислять их с поддержкой подстановочных знаков в O ( N) время. Уже одно это дает вам очень интересный набор возможностей при выборе имен ваших ключей, позвольте мне объяснить:

Сохранение последнего времени входа вашего пользователя

Это классический пример, когда использование вашей базы данных SQL для обновления такого изменчивого значения является излишним, особенно если у вас есть Redis под рукой.

Вы можете создать один ключ для каждого пользователя с именем: [USERID]_last_login , и только он позволит вам получить доступ и установить значение за O (1) раз!

Вы можете просто установить его с помощью SET [USERID]_last_login "2018-06-28 13:41:22", который установит ключ, если он уже существует, и создаст его, если он не существует, в постоянное время. И вы можете получить это простым GET [USERID]_last_login за то же время.

Дополнительное примечание: что, если по какой-то причине пользователи вашей платформы не часто заходят в систему? Как избавиться от беспорядка, который вызывают все эти нажатия одной клавиши? Вы можете установить TTL (T ime- T o- L ive) для своих ключей, и Redis позаботится об их удалении за вас! Просто введите: EXPIRE YOUR_KEY_NAME YOUR_TTL_IN_SECONDS, например: EXPIRE 23099273_last_login 3600, и вы убедитесь, что ключ автоматически удаляется, если нет активности более часа, иначе установка ключа приведет к сбросу срока действия, так что вы тоже в порядке!

Сила подстановочных знаков

Допустим, вы сохраняете время последнего входа в систему для своих пользователей, как я показал вам, и что у вас есть TTL для этих ключей, равный 1 часу, вы можете просто получить список вошедших в систему пользователей с помощью одного вызова KEYS.

Например: KEYS *_last_login вернет список всех ключей (следовательно, всех активных пользователей за последний час) за время O (N). Учитывая достаточно большое количество ключей в вашей базе данных, использование KEYS может быть не лучшим решением, но в документации Redis есть альтернативы, которые так же хороши или даже лучше. Это просто быстрый, который дает потрясающие результаты, особенно если вы не имеете дело с слишком большим количеством записей.

Использование Redis для реляционных данных

Какие? Да ладно, вы, очевидно, должны быть осторожны с этим, но если у вас есть разные наборы информации, которые имеют изменчивый характер (или, другими словами, нет проблем, если вы случайно потеряете его) и могут быть связаны для одного объекта, вы также можете играть в реляционную игру в Redis, правильно называя свои ключи.

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

  • Присвоение вашим ключам имен [USERID]_last_login и [USERID]_profile_likes дает вам возможность связать эти два набора данных и сохранить время O (1) для команд SET и GET.
  • Для данного пользователя вы можете просто сделать KEYS [USERID]*, чтобы узнать всю имеющуюся у вас информацию о нем / ней.

Использование Redis для планирования повторяющихся задач

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

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

Что, если бы вы могли просто добавить немного логики в свою систему, чтобы просто ждать уведомления о запуске? Redis может помочь!

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

Установив для ключей TTL, равный интервалу выполнения, вы можете отреагировать на их «смерть», создав их снова (чтобы цикл продолжился) и выполнив свой повторяющийся код. Вот и все, вы сохраняете свою внутреннюю логику внутри своего приложения и получаете более высокий уровень контроля над тем, когда и как выполнять код.

Использование теневых ключей

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

Допустим, вы хотите сохранить в своей базе данных SQL обновленное количество лайков для вашего профиля пользователя (опять же, основываясь на приведенных до сих пор примерах), но только после того, как пользователь был вне системы в течение примерно часа, вы не может этого сделать, просто добавив TTL в 1 час к вашему [USERID]_profile_likes ключу, потому что, как только этот ключ истечет, все готово.

Итак, что вы делаете, вы создаете «теневой ключ», срок действия которого в основном истекает, вместо вашего ключа, что дает вам возможность получить фактические данные, которые вам нужны, а затем решить удалить настоящий ключ или нет. .

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