предисловие
Когда дело доходит до распределенного кэширования, большинство людей, вероятно, думают о Redis.Почему Redis может выделиться в высококонкурентной войне кэшей? Причины следующие: хорошая производительность, богатые возможности и структуры данных, а также простые операции API. Однако, если его будет использовать больше людей, будет много нарушений или небрежности, а в серьезных случаях даже привести к производственным авариям, поэтому нам необходимо поговорить о некоторой «правильной позе» при использовании Redis.
Избегайте полос
Не смешите всех... Многие начинающие или неопытные разработчики устанавливают Redis на сервер с пользователем root, открывают порт по умолчанию и счастливо запускают его, открывая подключение к внешней сети и порт по умолчанию, даже для производства. тоже так, завидуя удобству момента, такая ситуация чаще встречается в некоторых стартап-компаниях (в том числе N лет назад я тоже так делал...)
Так что же может пойти не так? Наиболее распространенной является уязвимость несанкционированного доступа Redis. После того, как злоумышленник просканирует открытый ip интернета и дефолтный порт 6379, он напрямую подключается к редису вашего сервера локально и удаленно, и записывает публичный ключ, сгенерированный локальной машиной, в авторизованные ключи сервера через команду Redis.В настоящее время на локальной машине можно войти по ssh без пароля. Затем вы можете написать rebound-шелл, повысить привилегии и делать все, что хотите, что является одной из причин, по которой на вашем сервере внезапно появляется программа для майнинга.
Чтобы предотвратить вышеуказанные риски, мы можем справиться с этим из следующих мест.
-
Изменить порт по умолчанию 6379
-
Привязать доступ к интрасети к bing 127.0.0.1
-
Добавить аутентификацию по паролю для Redis
-
запустить Redis от имени пользователя с низким уровнем привилегий
-
При необходимости установите политики брандмауэра.
Запретите "ключ *", используйте вместо него "скан"
Говоря об этом, автор тоже весь в слезах.Когда я был молодым и невежественным, я однажды выполнил этот заказ в производственных условиях, а потом чуть не собрал свой рюкзак и ушел с работы пораньше. Почему эта операция такая ужасная? Операция «ключ *» означает возврат всех совпадающих ключей в базе данных. Она будет сканировать все записи одновременно. Когда объем данных в вашей библиотеке велик, это приведет к блокировке Redis, резкому увеличению загрузки ЦП и медленному замедлению. перетащите соответствующие запросы на redis в проекте, пока не возникнут различные тайм-ауты...
После Redis 2.8 для перемещения по ключам предоставляется улучшенная операция «сканирование», которая похожа на ResultSet в нашем jdbc, итерируя курсор. Метод использования: «СКАНИРОВАНИЕ курсора [Шаблон ПОИСКПОЗ] [счетчик COUNT]».
redis 127.0.0.1:6379> scan 0
1) "17"
2) 1) "key:12"
2) "key:8"
3) "key:4"
4) "key:14"
5) "key:16"
6) "key:17"
7) "key:15"
8) "key:10"
9) "key:3"
10) "key:7"
11) "key:1"
redis 127.0.0.1:6379> scan 17
1) "0"
2) 1) "key:5"
2) "key:18"
3) "key:0"
4) "key:2"
5) "key:19"
6) "key:13"
7) "key:6"
8) "key:9"
9) "key:11"
"сканировать 0" означает начать новую итерацию. Когда возвращенный первый параметр равен 0, это означает, что итерация заканчивается. Если он не равен 0, следующая итерация приведет этот курсор к началу следующего обхода, пока он не вернет 0. Второй параметр - значение, пройденное в настоящее время. При его использовании нужно обращать внимание на версию.Если версия ниже 2.8, вам нужно обновиться, прежде чем вы сможете ее использовать.
ключевой дизайн
Во-первых, для разделения ключа обычно используется ":". Когда вы используете его самостоятельно, старайтесь не использовать вместо этого некоторые специальные символы. Для нашего ключевого дизайна, пожалуйста, обратитесь к нашей реляционной базе данных.
Если есть пользовательская таблица с полями userid, age и username, то наш ключ может быть оформлен как "user:userid:useridValue:username", имя таблицы используется как префикс ключа, а условия запроса помещаются в конце. Поле отделено от соответствующего ему значения посередине, и все дизайны спроектированы так, чтобы сделать запросы более удобными.
Разумное использование нескольких БД
Нижний индекс db для redis по умолчанию равен 0-15, то есть их 16. Обычно большинство людей используют db0, все к-в лежат в одной библиотеке. Это на самом деле не большая проблема, но redis не является реляционной базой данных, и хранимые данные не так уж связаны друг с другом, поэтому рекомендуется рассредоточить данные по разным библиотекам по разным бизнесам, чтобы мы могли выбирать разные Работают БД для выполнения различных бизнес-модулей.
Эффективно используйте 5 структур данных
Redis предоставляет 5 структур данных, но по результатам предыдущих собеседований многие кандидаты используют в проекте практически только строковый тип, и даже мало знают о других типах. На самом деле, когда мы сможем эффективно использовать разные структуры в разных сценариях, эффективность значительно повысится. Несколько примеров кратко описаны ниже.
SortSet
Он предоставляет приоритет (оценку) для сортировки, мы можем установить значение оценки в виде метки времени, чтобы мы могли получать данные в определенный период времени с помощью некоторых операций по времени, таких много в модуле робота наши операции класса проекта. Другим распространенным местом является таблица лидеров, которую можно быстро и эффективно обновлять за счет изменения значения очков.
list
Его реализация представляет собой двусвязный список.Мы можем хранить какие-то задачи, которые нужно выполнить через lpush и rpush для формирования заказа, удовлетворяющего нашим потребностям.Наконец, мы их достаем и выполняем последовательно, аналогично mq.
set
Он используется для выполнения некоторых автоматических операций дедупликации, таких как команда Redis для пересечения, которая может удалить общих друзей двух людей.
Отключить команды с высоким риском
В Redis есть много команд с высоким риском. Например, «flushdb», «config» и т. д., мы можем отключить или переименовать эти команды, чтобы сделать операцию более безопасной.
Нам нужно изменить файл конфигурации redis redis.conf, в пункте БЕЗОПАСНОСТЬ добавить
rename-command FLUSHALL ""
rename-command CONFIG ""
Если его переименовать
rename-command FLUSHALL abcdefg
Он вступает в силу после перезапуска конфигурации.
Эпилог
Что касается темы Redis, то на самом деле их гораздо больше, таких как публикация и подписка, механизм сохраняемости, кластеризация и т. д. Многие лучшие практики необходимо постоянно изучать в сочетании с вашим собственным бизнесом. Опять же, то, что подходит вам, является лучшим.