❝В конце концов, Redis по-прежнему является очень популярным промежуточным программным обеспечением для кэширования, поэтому вам нужно изучить его все сразу.В сценариях с высоким параллелизмом он также используется больше, и также часто проводятся собеседования.
❞
контурный рисунок
Что такое Редис
Проще говоря, Redis — это"база данных", но в отличие от традиционных баз данных, база данных Redis существует"ОЗУ", так"Очень высокая скорость чтения и записи", поэтому Redis широко используется в"тайник"направление. Кроме того, Redis также часто используется для выполнения"Распределенная блокировка", Redis предоставляет различные типы данных для поддержки различных бизнес-сценариев. Кроме,"Redis поддерживает транзакции","Упорство","луа-скрипт","События, управляемые LRU","несколько кластеров"план.
Зачем использовать Redis
- "высокая производительность": Предположим, что пользователь обращается к некоторым данным в базе данных в первый раз. Этот процесс будет более медленным, поскольку"читать с жесткого диска"из. доступ пользователя"данные кэшируются", чтобы при следующем доступе к данным вы могли получить их прямо из кеша. Держать"Кэш предназначен для работы с памятью напрямую, поэтому скорость довольно высокая.". Если соответствующие данные в базе данных изменены, соответствующие данные в кэше могут быть изменены синхронно!
- "Высокий параллелизм":"Запрос, который может выдержать кэш прямой операции, намного больше, чем прямой доступ к базе данных.", поэтому мы можем рассмотреть возможность переноса части данных в базе данных в кеш, чтобы часть запроса пользователя попадала сразу в кеш, минуя базу данных.
Каковы преимущества использования Redis
- "высокоскоростной", так как данные находятся в памяти, аналогично HashMap, преимущество HashMap в том, что временная сложность поиска и операции составляет O(1)
- Поддержка расширенных типов данных, поддержка"строка, список, набор, отсортированный набор, хэш"
- "Поддержка транзакций", операции атомарны, так называемая атомарность заключается в том, что изменения данных либо выполняются все, либо не выполняются вообще
- Богатые возможности:"Может использоваться для кеша, сообщения, установить время истечения срока действия в соответствии с ключом, он будет автоматически удален после истечения срока действия."
- и т.д...
Зачем использовать Redis вместо map/guava для кеширования
Кэш делится на"локальный кеш"и"Распределенный кеш". Возьмите Java в качестве примера, используйте встроенный"Карта или гуава реализуют локальное кэширование", самая главная особенность"Легкий и быстрый, жизненный цикл заканчивается разрушением jvm, а в случае нескольких экземпляров каждый экземпляр должен сохранять собственный кеш, а кеш не согласован."
использовать"что-то вроде redis или memcached называется распределенным кешем", в случае нескольких экземпляров каждый экземпляр совместно использует кэшированные данные,"Кэш согласован". Недостатком является то, что вам нужно сохранить"Высокая доступность сервисов Redis или memcached", вся структура программы более сложная.
В чем преимущества Redis перед Memcached
- memcached все значения"простые строки", redis в качестве замены, поддерживает больше"Богатые типы данных"
- Redis быстрее, чем memcached"быстрый"полно
- редис может"Упорство"его данные
Поточная модель Redis
Redis использует внутренний обработчик файловых событийfile event handler, этот обработчик событий файла"один поток", поэтому Redis называется"однопоточная модель". он принимает"Механизм мультиплексирования ввода-вывода"Прослушивание нескольких сокетов одновременно в соответствии с событиями на сокете"Выберите соответствующий обработчик события"для обработки.
Структура обработчика файловых событий состоит из 4 частей:
- несколько сокетов
- мультиплексор ввода/вывода
- файловый диспетчер событий
- Обработчик событий (обработчик ответа на соединение, обработчик запроса команды, обработчик ответа команды)
Несколько розеток могут"Параллелизм производит различные операции", каждая операция соответствует отдельному событию файла, но мультиплексор ввода-вывода будет прослушивать несколько сокетов и будет"События ставятся в очередь", диспетчер событий берет событие из очереди за раз и передает событие соответствующему"обработчик события"для обработки.
Распространенные проблемы с производительностью Redis и их решения
- Мастеру лучше не выполнять никакой постоянной работы, такой как снимки памяти RDB и файлы журнала AOF.
- Если данные более важны, ведомое устройство позволяет AOF выполнять резервное копирование данных, а политика настроена на синхронизацию один раз в секунду.
- Для скорости репликации master-slave и стабильности соединения лучше всего, чтобы Master и Slave находились в одной локальной сети.
- Старайтесь не добавлять подчиненные библиотеки в загруженную главную библиотеку.
- Репликация master-slave не использует структуру графа, более стабильно использовать структуру односвязного списка, то есть: Master
Общие структуры данных Redis и анализ сценариев использования
String
❝Общие команды: set, get, decr, incr, mget и т. д.
❞
Структура данных String представляет собой простой тип ключ-значение, и значение может быть не только строкой, но и числом. Обычное приложение кэширования ключей и значений; обычный подсчет: количество микроблогов, количество подписчиков и т. д.
Hash
❝Общие команды: hget, hset, hgetall и т. д.
❞
Хэш представляет собой таблицу сопоставления поля и значения строкового типа. Хэш особенно подходит для хранения объектов. В последующих операциях вы можете напрямую изменять значение поля в объекте. Например, мы можем использовать структуру данных Hash для хранения информации о пользователе, информации о товарах и так далее.
List
❝Общие команды: lpush,rpush,lpop,rpop,lrange и т. д.
❞
Список представляет собой связанный список.Список Redis имеет множество сценариев применения, а также является одной из наиболее важных структур данных Redis.Например, с помощью списка могут быть реализованы следующие функции Weibo, список поклонников, список сообщений и другие функции. Структура Redis.
Список Redis реализован как двусвязный список, который может поддерживать обратный поиск и обход, что более удобно в работе, но требует дополнительных затрат памяти.
Кроме того, вы можете использовать команду lrange, то есть сколько элементов считывается из определенного элемента, и вы можете реализовать запрос на подкачку на основе списка.Это отличная функция, основанная на Redis для достижения простой высокопроизводительной подкачки, вы можете сделать выпадающее меню, как в Weibo.
Set
❝Общие команды: sadd,spop,smembers,sunion и т.д.
❞
Функция, предоставляемая набором для внешнего мира, аналогична функции списка, которая является функцией списка.Особенностью является то, что набор может автоматически переупорядочиваться.
Если вам нужно сохранить список данных и вы не хотите дублировать данные, хорошим выбором будет набор, а набор предоставляет важный интерфейс для определения того, находится ли элемент в коллекции наборов, что также не предоставляется списком. Операции пересечения, объединения и разности могут быть легко реализованы на основе множества.
Например, в приложении Weibo все подписчики пользователя могут храниться в наборе, и все подписчики пользователя могут храниться в наборе. Redis может легко реализовать такие функции, как общее внимание, общие поклонники и общие предпочтения. Этот процесс также является процессом поиска пересечения.Конкретные команды заключаются в следующем:sinterstore key1 key2 key3Сохраните пересечение в key1
Sorted Set
❝Общие команды: zadd, zrange, zrem, zcard и др.
❞
По сравнению с набором, отсортированный набор добавляет оценку весового параметра, так что элементы в наборе могут быть упорядочены по количеству баллов.
Например: в системе прямой трансляции информация о ранжировании в реальном времени включает в себя список онлайн-пользователей в комнате прямой трансляции, различные рейтинги подарков, сообщения в чате с маркерами (которые можно понимать как ранжирование сообщений в соответствии с измерением сообщения) и другую информацию. информация, которая подходит для хранения в структуре SortedSet в Redis.
Redis устанавливает время истечения срока действия
В Redis есть функция установки времени истечения срока действия, то есть время истечения может быть установлено для значения, хранящегося в базе данных Redis. В качестве базы данных кеша это очень полезно. Например, токен или какая-то информация для входа в наш общий проект, особенно код подтверждения SMS, ограничены по времени.Согласно традиционному методу обработки базы данных, мы обычно сами судим об истечении срока действия, что, несомненно, серьезно повлияет на производительность проекта.
Когда мы устанавливаем ключ, мы можем указать время истечения срока действия, которое является временем истечения срока действия.Через время истечения срока действия мы можем указать время, в течение которого ключ может существовать.
Периодическое удаление + ленивое удаление
- Периодическое удаление: по умолчанию Redis случайным образом выбирает некоторые ключи со сроком действия каждые 100 мс, проверяет, истек ли срок их действия, и удаляет их, если срок их действия истек. Обратите внимание, что это случайный выбор. Почему случайно? Подумайте об этом, если Redis хранит сотни тысяч ключей и проходит через все ключи со сроком действия, установленным каждые 100 мс, это сильно нагрузит ЦП!
- Ленивое удаление: периодическое удаление может привести к тому, что многие ключи с истекшим сроком действия не будут удалены, когда придет время. Так что есть ленивое удаление. Если ваш ключ с истекшим сроком действия не удален обычным удалением, он все еще остается в памяти, если ваша система не проверит ключ, он будет удален с помощью Redis. Это так называемое ленивое удаление, и оно достаточно ленивое!
Что будет, если вы пропустите много просроченных ключей при обычном удалении, и вовремя не проверите, и не пойдете на ленивое удаление? Если в памяти накапливается большое количество ключей с истекшим сроком действия, блок памяти redis исчерпывается. Как решить эту проблему?
"Механизм устранения памяти Redis."
Mysql имеет 20 миллионов данных, а redis хранит только 200 000. Как убедиться, что данные в redis являются горячими данными
Когда размер набора данных памяти Redis возрастет до определенного размера, будет реализована стратегия удаления данных. Redis предлагает 6 стратегий удаления данных:
- voltile-lru: выберите данные из набора данных, которые использовались наименее недавно, с установленным временем истечения срока действия (server.db[i].expires) для удаления.
- volatile-ttl: выберите данные, срок действия которых истекает, из набора данных (server.db[i].expires), в котором установлено время истечения срока действия.
- volatile-random: произвольный выбор удаления данных из набора данных с установленным временем истечения срока действия (server.db[i].expires)
- allkeys-lru: выбрать наименее использованные данные из набора данных (server.db[i].dict) для исключения
- allkeys-random: Случайный выбор данных из набора данных (server.db[i].dict) для исключения
- no-enviction: запретить удаление данных
В чем разница между Memcache и Redis
-
способ хранения
- Memecache хранит все данные в памяти, он зависает после сбоя питания, и данные не могут превышать размер памяти.
- Часть Redis хранится на жестком диске, что обеспечивает сохранность данных.
-
Тип поддержки данных
- Memcache имеет относительно простую поддержку типов данных. Нить
- Redis имеет сложные типы данных. Redis не только поддерживает простые данные типа k/v, но также обеспечивает хранение таких структур данных, как list, set, zset и hash.
-
Используйте базовую модель по-другому
- Базовые реализации между ними и протокол приложения, используемый для связи с клиентом, различаются.
- Redis напрямую сам строит механизм ВМ, потому что, если общая система вызывает системные функции, она будет тратить определенное количество времени на перемещение и запрос.
-
кластерный режим
У memcached нет собственного режима кластера, и ему нужно полагаться на клиента для записи данных в кластер в сегментах; однако Redis в настоящее время поддерживает режим кластера по умолчанию.
-
Memcached — это многопоточная, неблокирующая сетевая модель мультиплексирования ввода-вывода; Redis использует модель мультиплексирования ввода-вывода с однопотоковым мультиплексированием.
Механизм сохранения Redis
Много раз нам нужно сохранять данные, то есть записывать данные из памяти на жесткий диск.Большинство причин заключается в повторном использовании данных позже (например, перезапуск машины, восстановление данных после сбоя машины) или для резервного копирования данных для предотвращения сбоев системы в удаленном месте.
Очень важное различие между Redis и Memcached заключается в том, что"Redis поддерживает постоянство"и поддерживает две разные операции сохранения. Метод сохранения Redis называется"Моментальные снимки (моментальные снимки, RDB)", другой способ"Файл только для добавления (AOF)"Каждый из этих двух методов имеет свои достоинства.Ниже я подробно расскажу, что это за два метода сохранения, как их использовать и как выбрать метод сохранения, который вам подходит.
Сохранение моментальных снимков (RDB)
Redis может получить копию данных, хранящихся в памяти, в определенный момент времени, создав снимок. После того, как Redis создаст моментальный снимок, вы можете создать его резервную копию, скопировать снимок на другие серверы, чтобы создать копию сервера с теми же данными (структура Redis master-slave, в основном используемая для повышения производительности Redis), и вы можете оставить снимок в место для перезапуска сервера при использовании.
Сохранение моментальных снимков — это метод сохранения по умолчанию, используемый Redis.В файле конфигурации redis.conf по умолчанию используется следующая конфигурация:
save 900 1 #在900秒(15分钟)之后，如果至少有1个key发生变化，Redis就会自动触发BGSAVE命令
创建快照。
save 300 10 #在300秒(5分钟)之后，如果至少有10个key发生变化，Redis就会自动触发BGSAVE命令创建快照。
save 60 10000 #在60秒(1分钟)之后，如果至少有10000个key发生变化，Redis就会自动触发BGSAVE命令创建快照。
Сохранение AOF (файл только для добавления)
По сравнению с сохранением моментальных снимков, AOF"Постоянная производительность в реальном времени лучше", поэтому она стала основной схемой сохранения. По умолчанию Redis не включает сохранение AOF (добавлять только файл), которое можно включить с помощью параметра appendonly:appendonly yes
После включения сохраняемости AOF каждый раз, когда выполняется команда, которая изменяет данные в Redis, Redis записывает команду в файл AOF на жестком диске. Местоположение файла AOF совпадает с местоположением файла RDB, которое задается параметром dir.Имя файла по умолчанию — appendonly.aof.
В файле конфигурации Redis есть три разных метода сохранения AOF:
appendfsync always #每次有数据修改发生时都会写入AOF文件,这样会严重降低Redis的速度
appendfsync everysec #每秒钟同步一次，显示地将多个写命令同步到硬盘
appendfsync no #让操作系统决定何时进行同步
Чтобы сбалансировать производительность данных и записи, пользователи могут использовать опцию appendfsync everysec, позволяющую Redis синхронизировать файлы AOF каждую секунду, и это практически не повлияет на производительность Redis. И таким образом, даже если система выйдет из строя, пользователь потеряет данные, сгенерированные не более чем за одну секунду. Когда жесткий диск занят выполнением операций записи, Redis изящно замедляет себя, чтобы обеспечить максимальную скорость записи жесткого диска.
"Оптимизация Redis 4.0 для механизма сохраняемости"
Redis 4.0 начал поддерживать смешанное сохранение RDB и AOF (по умолчанию отключено, его можно включить с помощью элемента конфигурации aof-use-rdb-preamble).
Если гибридное сохранение включено, при перезаписи AOF содержимое RDB будет записано непосредственно в начало файла AOF. Преимущество этого заключается в том, что он может сочетать преимущества RDB и AOF, быстрой загрузки и предотвращения потери слишком большого количества данных. Конечно, есть и некоторые недостатки.Часть RDB в AOF заключается в том, что формат сжатия больше не является форматом AOF, а читабельность плохая.
AOF переписать
Перезапись AOF может создать новый файл AOF.Этот новый файл AOF имеет то же состояние базы данных, что и исходный файл AOF."но меньше".
Перезапись AOF — неоднозначное имя, функция"ключевое значение"Для этого программе не нужно читать, анализировать или записывать какие-либо существующие файлы AOF.
При выполнении команды BGREWRITEAOF сервер Redis поддерживает AOF."буфер перезаписи", который записывает все команды записи, выполненные сервером во время создания нового файла AOF дочерним процессом."Когда дочерний процесс завершит работу по созданию нового файла AOF, сервер добавит все содержимое буфера перезаписи в конец нового файла AOF, чтобы состояние базы данных, сохраненное новым и старым файлами AOF, было согласовано.". Наконец, сервер заменяет старый файл AOF новым файлом AOF, чтобы завершить операцию перезаписи файла AOF.
Redis-транзакции
Redis реализует функции транзакций с помощью таких команд, как MULTI, EXEC и WATCH. Транзакции обеспечивают"Механизм для упаковки нескольких командных запросов, а затем выполнения нескольких команд одновременно и последовательно, и во время выполнения транзакции сервер не будет прерывать транзакцию и переходить на выполнение командных запросов других клиентов, он будет выполнять все команды в транзакции. все казнены", а затем обрабатывать запросы команд от других клиентов.
В традиционных реляционных базах данных свойства ACID часто используются для проверки надежности и безопасности функций транзакций. В Redis транзакции"всегда"У него есть атомарность, согласованность и изоляция, а когда Redis работает в определенном режиме персистентности, транзакция также имеет долговечность.
Каковы общие проблемы с производительностью Redis? Как решить?
- Мастер записывает снимки памяти, а команда сохранения назначает функцию rdbSave, которая блокирует работу основного потока.Когда снимок относительно большой, влияние на производительность очень велико, и служба будет периодически приостанавливаться, поэтому мастер не должен записывать снимки памяти.
- Мастер AOF является постоянным.Если файл AOF не перезаписывается, влияние этого метода сохранения на производительность минимально, но размер файла AOF будет продолжать расти.Если файл AOF слишком велик, это повлияет на скорость восстановления мастера начать сначала. Ведущему устройству лучше не выполнять никакой постоянной работы, включая создание моментальных снимков памяти и файлов журнала AOF, особенно не включать моментальные снимки памяти для сохраняемости. синхронизировать раз в секунду.
- Мастер вызывает BGREWRITEAOF для перезаписи файла AOF. AOF будет занимать много ресурсов ЦП и памяти при перезаписи, что приводит к высокой нагрузке на службу и кратковременной приостановке службы.
- Проблема производительности репликации master-slave Redis, для скорости репликации master-slave и стабильности соединения лучше всего, чтобы Slave и Master находились в одной локальной сети.
Вы понимаете механизм синхронизации Redis?
Синхронизация ведущий-ведомый. При синхронизации в первый раз"Главный узел выполняет bgsave", и в то же время записать последующие операции модификации в"буфер памяти", должен быть завершен"Синхронизируйте все файлы rdb с узлом репликации.", после того как узел репликации примет"Загрузите образ rdb в память". После завершения загрузки снова уведомите главный узел"Синхронизируйте записи операций, измененные в течение периода, с узлом реплики для воспроизведения."Процесс синхронизации завершен.
Использовать ли кластер Redis и каков принцип кластеризации
Redis Sentinel фокусируется на высокой доступности: когда главный сервер выходит из строя, он автоматически повышает подчиненный уровень до главного и продолжает предоставлять услуги.
Redis Cluster фокусируется на масштабируемости и использует Cluster для сегментированного хранилища, когда одной памяти Redis недостаточно.
Cache Avalanche и решения проблем с кэшем
Кэш Лавина
Кэш выходит из строя на большой площади одновременно, поэтому последующие запросы будут падать на БД, вызывая коллапс БД из-за большого количества запросов за короткий промежуток времени.
- Предварительно: постарайтесь обеспечить высокую доступность всего кластера Redis и компенсируйте это как можно скорее, когда машина не работает. Выберите подходящую стратегию вывода из эксплуатации памяти.
- В процессе: локальный кеш ehcache + текущее ограничение hystrix и понижение версии, чтобы избежать сбоя MySQL
- Постфактум: данные, сохраненные механизмом сохранения redis, используются для скорейшего восстановления кеша.
проникновение в кеш
Как правило, хакеры намеренно запрашивают данные, которых нет в кеше, в результате чего все запросы падают на базу данных, вызывая обрушение базы данных из-за большого количества запросов за короткий промежуток времени.
Решение. Существует множество способов эффективного решения проблемы проникновения в кэш, наиболее распространенным из которых является использование фильтра Блума для хеширования всех возможных данных до достаточно большого размера."bitmap"В этом случае данные, которые не должны существовать, будут перехвачены этим растровым изображением, что позволит избежать давления запроса на базовую систему хранения. Есть и более простой и грубый способ (им мы пользуемся), если"Данные, возвращаемые запросом, пусты."(независимо от того, не существуют ли данные или система неисправна), мы все равно кэшируем этот пустой результат, но его"Срок годности будет очень коротким", максимум пять минут.
Как решить ключевую проблему конкурентного параллелизма Redis
Так называемая проблема параллельной конкуренции ключей в Redis заключается в том, что несколько систем работают с одним ключом одновременно, но окончательный порядок выполнения отличается от ожидаемого, что приводит к разным результатам!
Рекомендуемое решение: распределенные блокировки (и zookeeper, и redis могут реализовать распределенные блокировки). (Если нет проблемы конкуренции с одновременным доступом к Redis, не используйте распределенные блокировки, это повлияет на производительность)
Распределенные блокировки, которые могут быть реализованы временными упорядоченными узлами на базе zookeeper. Общая идея такова: когда каждый клиент блокирует метод, создается уникальный мгновенный упорядоченный узел в каталоге назначенного узла, соответствующего методу на zookeeper. Способ определить, следует ли получить блокировку, очень прост, просто нужно оценить блокировку с наименьшим порядковым номером в упорядоченном узле. При снятии блокировки просто удалите переходный узел. В то же время это может избежать проблемы взаимоблокировки, когда блокировка не может быть снята из-за простоя службы. После завершения бизнес-процесса удалите соответствующий дочерний узел, чтобы снять блокировку.
На практике, конечно, он основан на надежности. Итак, первая рекомендация — Zookeeper.
Как обеспечить согласованность данных при двойной записи между кешем и базой данных
Пока вы используете кеш, это может включать двойное хранение и двойную запись в кеш и базу данных. Пока вы используете двойную запись, будут проблемы с согласованностью данных. Итак, как вы решаете проблему согласованности?
Вообще говоря, если ваша система строго не требует согласованности кеша и базы данных, кэш может иногда не согласовываться с базой данных.Перейдите к очереди памяти, чтобы убедиться, что не будет несоответствий
После сериализации пропускная способность системы будет сильно снижена, и для поддержки запроса на линии используется в несколько раз больше машин, чем обычно.
❝Это не легко создать, если вы найдете это полезным, дайте маленькую звезду. адрес гитхаба 😁😁😁
❞