Кэширование играет ключевую роль в нашей повседневной разработке, и наша система может быть улучшена во многих отношениях с помощью компонентов кэширования. И Redis является типичным компонентом кэша. Бывает, что в последнее время Redis используется чаще, поэтому я намерен фиксировать проблемы, возникающие при разработке Redis, и некоторые спецификации разработки в статьях. Статьи, опубликованные вGithub, будет обновляться, приветствуются звезды и дополнения
Ключевой дизайн
легко управлять
То есть по названию можно примерно узнать, о каком бизнесе идет речь. Обычно мы называем его с помощью service:characteristics, например pubg_chat:uid:room_id, чтобы максимально избежать конфликтов (конечно, для разных бизнесов лучше использовать разные Redis).
быть максимально кратким
Redis — это, по сути, база данных в памяти, и размер памяти намного меньше, чем размер жесткого диска. Если ключ слишком велик, это уменьшит содержимое, которое может хранить Redis. Поэтому в повседневной жизни рекомендуется, чтобы Ключи были как можно короче, а вместо полных слов использовались аббревиатуры.
избегайте специальных символов
Управляющие символы, такие как запятые, символы новой строки, пробелы и кавычки, не должны использоваться.
установить жизненный цикл
- Redis не должен быть компонентом постоянного хранилища, установите срок действия для каждого ключа
- Если вам действительно нужно Redis для постоянного хранения определенного типа контента, то это следует делать асинхронным методом «продолжения», и вам не следует устанавливать для него постоянный жизненный цикл в начале, чтобы избежать аварий обслуживания, когда потребуются последующие изменения .
Использование ценности
Избегайте больших ключей!
- Redis является однопоточным, он будет выполнять другие команды после выполнения одной команды.
- Во-первых, когда большой ключ передает пары ключ-значение, это будет давить на сеть (проблема с пропускной способностью), а некоторые прокси будут передавать большой контент фрагментами, что снова увеличит время передачи по сети.
- Во-вторых, для таких структур, как список и хеш, если вы используете инструкции O(n) или используете команду del, это вызовет серьезную блокировку.
- Вообще говоря, строковый тип контролируется в пределах 10 КБ, а количество элементов hash, list, set, zset не должно превышать 5000.
- ps: большой ключ обычно можно разделить хэшем
Сжатие значения
Рассмотрите возможность использования protobuf, MessagePack и т. д. для сериализации, что может улучшить использование Redis, повысить эффективность сериализации и обеспечить возможность использования значения на разных языках.
использование команды
Избегайте частого добавления строк
Рассмотрите возможность использования списка вместо этого
Операции класса коллекции
- Следует отметить O(n) инструкций. Для классов коллекций, таких как set, zset, list, hash и т. д., следует обратить внимание на влияние O(n) команд на производительность. Обычно следует избегать прямого использования инструкций O(n), а HSCAN, SSCAN, ZSCAN можно использовать для последовательной работы, чтобы предотвратить блокировку команд.
- Прогрессивное удаление. Вы не должны использовать del напрямую, но вы должны написать свой собственный скрипт, чтобы удалить немного
Отключить опасные команды
keys, flush, flushdb... Излишне говорить, что как только Redis приходит напрямую, люди ошеломлены.
Рациональное использование конвейерного режима
- При получении большого объема данных прокси-сервер будет распаковывать и распаковывать, что увеличивает нагрузку на уровень прокси-сервера, и режим конвейера будет напрямую пересылаться. Так, в случае пакетного приобретенияЭффективность конвейера обычно выше, чем у mget.
- Следует отметить одновременно два момента:
- mget — атомарная операция, а конвейер — нет. Поэтому его не следует использовать вслепую в бизнесе.
- Конвейер может отправлять разные команды, конечно, этого можно добиться и с помощью lua
Избегайте ненужных указаний
Например, некоторые клиенты Redis будут иметь команды обнаружения, такие как TestOnBorrow.Таких команд следует избегать без особых требований, чтобы уменьшить нагрузку на Redis и нагрузку на сеть.
Особые требования должны быть сделаны для Lua
- Все ключи должны передаваться массивом KEYS
- Все значения должны передаваться массивом ARGS
- Все ключи должны быть в 1 слоте
команда запроса производительности
- slowlog получить, запросить медленную команду
- info commandstats, запрашивать информацию о выполненной команде, включая время и время и т. д.
- список клиентов, запросите команду блокировки
Использование клиента
Избегайте смешивания экземпляров
Экземпляры должны быть разделены для разных бизнес-направлений, чтобы избежать проблем с цепочкой, вызванных смешанным использованием, таких как перекрытие ключей, блокировка команд и т. д.
Использовать пул соединений
Существует несколько проблем с созданием нового соединения каждый раз, когда вы его используете:
- Увеличьте нагрузку на Redis
- трата сетевых ресурсов
- Влияет на эффективность выполнения
- сложно поддерживать
предохранитель
Redis также является «сервисом» по своей сути, поэтому механизм прерывателя цепи незаменим.
Аутентификация
Избегайте неправильного использования нерелевантных сервисов или ошибок в данных.
Избегать как очередь сообщений
Redis действительно может поддерживать применение очередей сообщений, но его эффективность чтения и записи не так хороша, как у других MQ, таких как Kafka, RabbitMQ и т. д. А из-за своих структурных настроек он не способен поддерживать некоторые основные возможности MQ, поэтому его следует избегать.
разное
стратегия устранения
В соответствии с типом вашего бизнеса выберите maxmemory-policy (политика исключения максимальной памяти) и установите время истечения срока действия. Стратегия по умолчанию — volatile-lru, то есть после превышения максимального объема памяти алгоритм lru используется для удаления ключей из ключей с истекшим сроком действия, чтобы гарантировать, что неистекшие данные не будут удалены, но могут возникнуть проблемы с OOM
- allkeys-lru: удалять ключи по алгоритму LRU, независимо от того, установлен ли в данных атрибут тайм-аута, пока не освободится достаточно места
- allkeys-random: случайным образом удалять все ключи, пока не станет достаточно места.
- volatile-random: случайным образом удалять просроченные ключи, пока не освободится достаточно места
- volatile-ttl: удалить данные, срок действия которых истекает недавно, в соответствии с атрибутом ttl объекта «ключ-значение». Если нет, вернитесь к стратегии невыселения.
- noeviction: никакие данные не будут удалены, все операции записи будут отклонены, и будет возвращено сообщение об ошибке клиента «(ошибка) команда OOM не разрешена при использовании памяти». В настоящее время Redis отвечает только на операции чтения
- allkey-lfu и volatile-lfu, представленные после версии 4.0
- Его можно рассматривать как дальнейшее усовершенствование алгоритма lru.
- allkey-lfu: удалить наименее часто используемый ключ из всех ключей
- volatile-lfu: исключить наименее часто используемый ключ из всех ключей, настроенных со сроком действия.
Не злоупотребляйте транзакциями Redis
Транзакции Redis не так «безопасны», как транзакции БД, и не поддерживают откат, поэтому их не следует использовать слишком часто. Потому что я мало им пользовался, см.официальная документация