После прочтения этих 20 вопросов интервью Redis, можете ли вы записаться на собеседование с Ant Financial?

1. Что такое Redis и каковы характеристики Redis?

Полное название Redis: Remote Dictionary Server (удаленная служба данных).Redis — это система хранения, которая поддерживает различные структуры данных, такие как ключ-значение. Его можно использовать в таких сценариях, как кэширование, публикация событий или подписка, а также высокоскоростные очереди. Поддержка сети, предоставление строк, хэшей, списков, очередей, прямой доступ к структуре коллекции на основе памяти и возможность сохранения.

Функция 1: расширенные типы данных

Мы знаем, что многие базы данных могут обрабатывать только одну структуру данных:

Традиционные базы данных SQL обрабатывают двумерные реляционные данные;
База данных MemCached, и ключ, и значение являются строками;
База данных документов (MongoDB) — это документ, состоящий из Json/Bson.

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

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

Особенность 2: Память

Существует два типа баз данных: одна — база данных на жестком диске, а другая — база данных в памяти.

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

Хранение в памяти означает, что все данные хранятся в памяти, а скорость чтения и записи данных очень высока.

Особенность 3: функция сохранения

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

2. Какие структуры данных есть в Redis?

Redis — это база данных типа «ключ-значение».Тип ключа может быть только String, но тип данных значения богаче, в основном включает пять типов:

Нить
Хэш
Список
Набор
Сортированный набор

(1) Струнная струна

SET KEY_NAME VALUE

Строковый тип является двоично-безопасным. Это означает, что строка redis может содержать любые данные. Например, изображения в формате jpg или сериализованные объекты. Строковый тип является самым основным типом данных Redis, и ключ может хранить до 512 МБ.

(2) Хэш

HSET KEY_NAME FIELD VALUE

Хэш Redis — это набор пар ключ-значение (ключ=>значение). Хэш Redis — это таблица сопоставления поля и значения строкового типа, а хэш особенно подходит для хранения объектов.

(3) Список Список

//在 key 对应 list 的头部添加字符串元素
LPUSH KEY_NAME VALUE1.. VALUEN
//在 key 对应 list 的尾部添加字符串元素
RPUSH KEY_NAME VALUE1..VALUEN
//对应 list 中删除 count 个和 value 相同的元素
LREM KEY_NAME COUNT VALUE
//返回 key 对应 list 的长度
LLEN KEY_NAME

Списки Redis — это просто списки строк, отсортированные по порядку вставки. Вы можете добавить элемент в начало (слева) или хвост (справа) списка

(4) Коллекция наборов

SADD KEY_NAME VALUE1...VALUEn

Redis Set — это неупорядоченная коллекция строковых типов. Коллекция реализована через хеш-таблицу, поэтому сложность добавления, удаления и поиска составляет O(1).

(5) Sorted Set упорядоченная коллекция

ZADD KEY_NAME SCORE1 VALUE1.. SCOREN VALUEN

Redis zset, как и набор, также представляет собой набор элементов строкового типа, и повторяющиеся элементы не допускаются. Разница в том, что каждый элемент будет связан со счетом типа double.

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

Члены zset уникальны, но оценка (score) может повторяться.

3. Какова максимальная емкость, которую может хранить значение строкового типа?

Посмотрите официальную документацию ( https://redis.io/topics/data-types ), и вы увидите, что максимальная поддерживаемая длина значения типа String составляет 512M, поэтому правильный ответ — 512M.

4. Можете ли вы рассказать мне о сценариях использования каждой структуры данных Redis?

(1) Сценарии использования String

Сценарии использования строкового типа: информационный кеш, счетчик, распределенная блокировка и т.д.

Часто используемые команды: get/set/del/incr/decr/incrby/decrby

Практический сценарий 1. Запишите количество посещений каждого пользователя или запишите количество просмотров каждого продукта.

план:

Часто используемые имена ключей: userid:pageview или pageview:userid, если идентификатор пользователя равен 123, то соответствующий ключ redis — pageview:123, а значение — количество посещений пользователя. Чтобы увеличить количество раз, вы можно использовать команду: incr.

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

Практический сценарий 2. Кэширование часто читаемой, но нечасто изменяемой информации, например информации о пользователях и информации о видео.

план:

С точки зрения бизнес-логики: сначала прочитайте из redis, прочитайте из redis, если есть значение, прочитайте из mysql, если значения нет, и запишите копию в redis в качестве кеша, обратите внимание на установку времени истечения срока действия.

Ключ-значение:

Напрямую сериализовать запись mysql пользователя (обычно сериализованную в json) в качестве значения, userInfo:userid в качестве ключа, имя ключа: userInfo:123, а значение хранит строку json, соответствующую информации о пользователе. Например, ключ "user:id:name:1", а значение "{"name":"leijia","age":18}".

Практический сценарий 3: Ограничьте количество посещений в течение определенного периода времени для ip

план:

Используйте ключ для записи IP, а значение для записи количества посещений.При этом срок действия ключа установлен на 60 секунд.Если срок действия ключа истечет, он будет сброшен.В противном случае будет оценивается. Когда посещение превышает 100 раз в течение одной минуты, посещение будет запрещено.

Практический сценарий 4: Распределенный сеанс

Мы знаем, что сессия сохраняется на сервере в виде файла, если ваше приложение сбалансировано по нагрузке и проект веб-сайта размещен на нескольких серверах, то при входе пользователя на сервер А файл сессии будет записываться на сервер A ; Когда пользователь переходит на страницу и запрос назначается серверу B, файл сеанса не может быть найден, и пользователю придется снова войти в систему.

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

(2) Сценарии использования Hash

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

Если идентификатор продукта и количество продукта сериализованы в строку json, их также можно сохранить в указанном выше строковом типе. Давайте сравним две структуры данных:

Пункт сравнения

строка (json)

хэш

в заключение:

Когда свойство объекта нужно часто изменять, не подходит использование string+json, потому что это недостаточно гибко, и весь объект нужно повторно сериализовать и присваивать для каждой модификации; если тип хэша используется, его можно модифицировать отдельно для определенного свойства, без сериализации и без модификации всего объекта. Например, атрибуты, которые могут часто меняться, такие как цена товара, объем продаж, количество подписчиков и количество отзывов, подходят для хранения в хеш-типе.

(3) Сценарии использования списка

Список — это, по сути, упорядоченная очередь с повторяющимися элементами.

Реальный боевой сценарий: таблица лидеров по времени

Команда lrange типа списка может просматривать данные в очереди на страницах. Таблица лидеров, рассчитываемая время от времени, может быть сохранена в виде списка, например таблица лидеров материка QQ Music, которая рассчитывается один раз в неделю и сохраняется в виде списка.При доступе к интерфейсу страница и размер преобразуются в Команда lrange для получения данных таблицы лидеров.

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

(4) Установите сценарии использования

Коллекции характеризуются неупорядоченностью и детерминированностью (отсутствие повторения).

Реальная боевая сцена: Избранное

Например, если вам нравится песня в QQ Music, нажмите «Нравится», и песня будет помещена в ваши личные избранные. Каждый пользователь создает свою любимую коллекцию, и в каждой избранной коллекции хранятся идентификаторы песен, которые пользователь добавил в избранное.

Ключ — это идентификатор пользователя, а значение — набор идентификаторов песен.

(5) Сценарии использования Sorted Set

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

Реальный боевой сценарий: таблица лидеров в реальном времени

В QQ Music есть много видов списков в реальном времени, таких как Soaring List, Hot Song List и New Song List.Ключ Redis можно использовать для хранения типа списка, оценка — это количество кликов, значение — идентификатор песни. , и данные Redis будут обновляться каждый раз, когда пользователь нажимает на песню, отсортированный набор будет сортировать идентификаторы песен в соответствии со счетом, то есть количеством просмотров.

5. Как Redis обеспечивает постоянство? Можете ли вы рассказать о принципах реализации RDB и AOF?

Что такое настойчивость?

Постоянство (Persistence), то есть сохранение данных (например, объектов в памяти) на запоминающее устройство (например, на диск), которое можно хранить постоянно. Основное применение постоянства — хранить объекты в памяти в базе данных или в файле на диске, в файле данных XML и т. д.

[Ошибка загрузки изображения...(image-bcb944-1603435016634)]

Постоянство также можно просто понять на следующих двух уровнях:

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

Почему Redis должен сохраняться?

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

Как Redis достигает постоянства?

Redis официально предоставляет различные уровни постоянства:

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

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

постоянство RDB

Постоянство RDB (база данных Redis) — это процесс создания моментального снимка текущих данных памяти и сохранения его на жестком диске.Процесс запуска постоянства RDB делится на ручной запуск и автоматический запуск.

(1) Ручной триггер

Запуск соответствующей команды сохранения вручную заблокирует текущий сервер Redis до завершения процесса RDB.Для экземпляров с относительно большим объемом памяти это вызовет долгосрочную блокировку, поэтому не рекомендуется использовать ее в онлайн-среде.

(2) Автоматический триггер

Соответствующая команда bgsave запускается автоматически, и процесс Redis выполняет операцию разветвления для создания дочернего процесса.Процесс сохраняемости RDB отвечает за дочерний процесс и автоматически завершается после завершения. Блокировка происходит только на этапе форка, как правило, на короткое время.

Его можно настроить в конфигурационном файле redis.conf:

save <seconds> <changes>

Указывает, что bgsave автоматически запускается, когда данные изменяются xx раз в течение xx секунд. Если вы хотите отключить автоматическое срабатывание, вы можете добавить пустую строку после команды сохранения, а именно:

save ""

Существуют и другие распространенные триггеры для bgsave, такие как:

Если подчиненный узел выполняет операцию полного копирования, главный узел автоматически выполняет bgsave для создания файла RDB и отправляет его подчиненному узлу.
По умолчанию, когда выполняется команда выключения, bgsave выполняется автоматически, если функция сохраняемости AOF не включена.

bgsave рабочий механизм

[Ошибка загрузки изображения... (image-fedfd7-1603435016634)]

(1) Выполните команду bgsave, и родительский процесс Redis определит, существует ли в данный момент выполняющийся дочерний процесс, например дочерний процесс RDB/AOF.Если он существует, команда bgsave возвращает значение напрямую.

(2)Родительский процесс выполняет операцию fork для создания дочернего процесса.Во время операции fork родительский процесс будет заблокирован.Просмотрите параметр last_fork_usec с помощью команды info stats, чтобы получить время, затрачиваемое на последнюю операцию fork, в микросекундах

(3) После завершения разветвления родительского процесса команда bgsave возвращает сообщение «Начато сохранение в фоновом режиме» и больше не блокирует родительский процесс и может продолжать реагировать на другие команды.

(4) Дочерний процесс создает файл RDB, генерирует временный файл моментального снимка в соответствии с памятью родительского процесса и атомарно заменяет исходный файл после завершения. Выполните команду lastsave, чтобы получить время последней генерации RDB, которое соответствует параметру rdb_last_save_time информационной статистики.

(5) Процесс отправляет родительскому процессу сигнал о завершении, и родительский процесс обновляет статистическую информацию.

– Сохранение RDB завершено –

Сохранение AOF

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

Рабочий механизм сохранения AOF

Чтобы включить функцию AOF, вам необходимо настроить: appendonly yes, которая не включена по умолчанию.

Имя файла AOF задается в конфигурации appendfilename, а имя файла по умолчанию — appendonly.aof. Путь к хранилищу такой же, как и метод сохраняемости RDB, и определяется конфигурацией каталога.

Операции рабочего процесса AOF: запись команды (добавление), синхронизация файлов (синхронизация), перезапись файлов (перезапись), перезапуск загрузки (загрузка).

[Ошибка загрузки изображения...(image-1669b9-1603435016634)]

(1) Все команды записи будут добавлены в aof_buf (буфер).

(2) Буфер AOF синхронизируется с жестким диском в соответствии с соответствующей стратегией.

Почему AOF добавляет команды к aof_buf? Redis использует один поток для ответа на команды.Если каждая команда для записи файла AOF напрямую добавляется к жесткому диску, то производительность полностью зависит от текущей загрузки жесткого диска. Запись сначала в буфер aof_buf имеет еще одно преимущество: Redis может предоставить несколько стратегий синхронизации буфера, чтобы сбалансировать производительность и безопасность.

(3) Поскольку файл AOF становится все больше и больше, необходимо регулярно переписывать файл AOF для достижения цели сжатия.

(4) Когда сервер Redis перезапускается, файл AOF может быть загружен для восстановления данных.

Механизм перезаписи (перезаписи) AOF

Цель перезаписи:

Уменьшите пространство, занимаемое файлами AOF;
Файлы AOF меньшего размера могут загружаться и восстанавливаться Redis быстрее.

Перезапись AOF можно разделить на ручной запуск и автоматический запуск:

Ручной триггер: вызовите команду bgrewriteaof напрямую.
Автоматический запуск: определите время автоматического запуска в соответствии с параметрами auto-aof-rewrite-min-size и auto-aof-rewrite-percentage.

auto-aof-rewrite-min-size: указывает минимальный размер файла при выполнении перезаписи AOF, значение по умолчанию — 64 МБ.

auto-aof-rewrite-percentage: представляет отношение текущего файлового пространства AOF (aof_current_size) к файловому пространству AOF (aof_base_size) после последней перезаписи.

Автоматическое время триггера

当aof_current_size>auto-aof-rewrite-minsize 并且（aof_current_size-aof_base_size）/aof_base_size>=auto-aof-rewritepercentage。

Среди них aof_current_size и aof_base_size можно посмотреть в статистике info Persistence.

Почему файл AOF становится меньше после перезаписи?

(1) Старый файл AOF содержит недопустимые команды, такие как: del key1, hdel key2 и т. д. Перепишите команды записи, сохраняющие только окончательные данные.

(2) Можно комбинировать несколько команд, например lpush list a, lpush list b, lpush list c можно напрямую преобразовать в lpush list abc.

Восстановление данных файла AOF

[Ошибка загрузки изображения... (image-c23cde-1603435016634)]

Описание процесса восстановления данных:

(1) Если включено сохранение AOF и существуют файлы AOF, файлы AOF загружаются первыми.

(2) Если AOF закрыт или файл AOF не существует, загрузите файл RDB.

(3) После успешной загрузки файла AOF/RDB Redis успешно запускается.

(4) При возникновении ошибки в файле AOF/RDB Redis не запускается и выводит сообщение об ошибке.

- Сохранение AOF завершено -

Преимущества и недостатки RDB и AOF

Преимущества РБД

RDB — это очень компактный файл, который сохраняет набор данных в определенный момент времени, что очень удобно для резервного копирования набора данных.Например, вы можете сохранять данные за последние 24 часа каждый час и сохранять за последние 30 дней каждый день.Данные, чтобы, даже если что-то пойдет не так, вы могли восстановить другую версию набора данных в соответствии с вашими потребностями.
RDB представляет собой компактный отдельный файл, который легко перенести в другой удаленный центр обработки данных и который очень удобен для аварийного восстановления.
Когда RDB сохраняет файлы RDB, единственное, что нужно сделать родительскому процессу, — это разветвить дочерний процесс. Вся следующая работа выполняется дочерним процессом. Родительскому процессу не нужно выполнять другие операции ввода-вывода, поэтому метод сохраняемости RDB может максимизировать производительность Redis.
По сравнению с AOF метод RDB будет быстрее при восстановлении больших наборов данных.

Преимущества АОФ

Вы можете использовать различные стратегии fsync: без fsync, fsync каждую секунду, fsync каждый раз, когда вы пишете.Используя стратегию fsync по умолчанию каждую секунду, производительность Redis по-прежнему очень высока (fsync обрабатывается фоновым потоком, основной поток старается изо всех сил). обработка клиентских запросов), в случае сбоя вы потеряете до 1 секунды данных.
Файл AOF представляет собой файл журнала, который только добавляется, поэтому нет необходимости искать запись, даже если полная команда записи не выполняется по каким-либо причинам (дисковое пространство заполнено, время простоя во время записи и т. д.), вы также можете использовать инструмент redis-check-aof для устранения этих проблем.
Redis может автоматически перезаписывать AOF в фоновом режиме, когда размер файла AOF становится слишком большим: перезаписанный новый файл AOF содержит минимальный набор команд, необходимых для восстановления текущего набора данных. Вся операция перезаписи абсолютно безопасна, поскольку Redis продолжит добавлять команды к существующему файлу AOF в процессе создания нового файла AOF.Даже если в процессе перезаписи произойдет отключение, существующий файл AOF не будет потерян. Как только новый файл AOF будет создан, Redis переключится со старого файла AOF на новый файл AOF и начнет добавление к новому файлу AOF.
Файл AOF сохраняет все операции записи, выполняемые в базе данных, в упорядоченном порядке.Эти операции записи сохраняются в формате протокола Redis, поэтому содержимое файла AOF очень легко понять людям, а также очень легко для анализа (разбора) файла. Экспорт файла AOF также очень прост: например, если вы случайно выполнили команду FLUSHALL, но пока файл AOF не перезаписан, то просто остановите сервер, удалите команду FLUSHALL в конце файла AOF и перезапустите Redis. Набор данных может быть восстановлен до состояния до выполнения FLUSHALL.

Недостатки РБД

Для Redis относительно сложно полностью сохранить весь набор данных.Обычно полное сохранение выполняется каждые 5 минут или дольше.В случае непредвиденного простоя в Redis вы можете потерять несколько минут данных.
RDB необходимо часто разветвлять подпроцессы, чтобы сохранить набор данных на жесткий диск.Когда набор данных относительно велик, процесс разветвления занимает очень много времени, что может привести к тому, что Redis не сможет отвечать на запросы клиентов в течение миллисекунд.

Недостатки АОФ

Для одного и того же набора данных объем файлов AOF обычно больше, чем объем файлов RDB.
AOF медленнее, чем RDB, во время восстановления данных (загрузки), и обычно RDB может обеспечить более гарантированное максимальное время задержки.

Резюме простого сравнения RDB и AOF

Преимущества РДБ:

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

Недостатки РДБ:

RDB не может обеспечить постоянство в реальном времени или на втором уровне;
Старая и новая версии несовместимы с форматом RDB.

Преимущества АОФ:

Может лучше защитить данные от потери;
Производительность записи в режиме только для добавления относительно высока;
Он подходит для аварийного восстановления после катастрофического случайного удаления.

Недостатки АОФ:

Для одного и того же файла файл AOF больше, чем снимок RDB;
После включения AOF это повлияет на скорость записи QPS, а скорость записи уменьшится по сравнению с RDB;
Восстановление базы данных происходит относительно медленно, поэтому она не подходит для холодного резервного копирования.
Redis внутри использует обработчик файловых событий, который является однопоточным, поэтому Redis называется однопоточной моделью. Он использует механизм мультиплексирования ввода-вывода для одновременного мониторинга нескольких сокетов и выбирает соответствующий обработчик событий для обработки в соответствии с событиями на сокете.

Если интервьюер продолжает спрашивать, почему однопоточная модель Redis может быть такой эффективной?

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

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

(1) Проникновение в тайник

Что такое проникновение в кеш?

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

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

Общие решения для проникновения в кеш

(1) Фильтр Блума (рекомендуется)

Фильтр Блума (BF) был предложен Бертоном Ховардом Блумом в 1970 году и представляет собой вероятностную структуру данных с высокой эффективностью использования памяти.

Фильтры Блума предназначены для определения наличия определенного элемента в коллекции.

Если мы обычно хотим судить, находится ли элемент в наборе, мы обычно используем метод поиска и сравнения, Ниже анализируется эффективность поиска различных структур данных:

При использовании линейного табличного хранилища сложность времени поиска составляет O(N).
Хранится в сбалансированном двоичном дереве сортировки (AVL, красно-черное дерево), сложность времени поиска составляет O(logN).
При использовании хранилища хэш-таблиц с учетом коллизии хэшей общая временная сложность также составляет O[log(n/m)]

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

Идея дизайна фильтра Блума

Фильтр Блума представляет собой структуру данных, состоящую из битового массива (битового массива) длиной m бит и k хеш-функций (хеш-функции). Битовый массив инициализируется равным 0, и все хеш-функции могут хэшировать входные данные настолько равномерно, насколько это возможно.

Когда элемент должен быть вставлен в фильтр Блума, элемент вычисляется с помощью k хеш-функций для генерации k хеш-значений, и хэш-значение используется в качестве нижнего индекса в битовом массиве, и все k соответствующих битовых значений представлены на 0 устанавливается в 1.

Когда элемент должен быть запрошен, он также вычисляется с помощью хеш-функции для генерации хеш-значения, а затем проверяются соответствующие k битовых значений: если какой-либо бит равен 0, это указывает, что элемент не должен находиться в установлен; если все биты равны 1, это указывает на то, что набор, вероятно, находится в наборе. Почему не обязательно в коллекцию? Поскольку хеш-значения, вычисляемые разными элементами, могут быть одинаковыми, произойдет хэш-коллизия, в результате чего несуществующий элемент может соответствовать биту 1, что является так называемым «ложным срабатыванием». Напротив, «ложноотрицательные результаты» (ложноотрицательные результаты) никогда не появятся в BF.

Подводя итог: то, что фильтр Блума считает отсутствующим в наборе, не должно быть в наборе; то, что фильтр Блума считает находящимся в наборе, может быть, а может и не быть в наборе.

Например: на рисунке ниже показан фильтр Блума с 18 битами и 3 хеш-функциями. Три элемента x, y и z в наборе хэшируются в разные биты тремя хеш-функциями, а битовая позиция устанавливается равной 1. При запросе элемента w через три хеш-функции обнаруживается, что есть бит со значением 0, и можно определить, что элемента нет в наборе.

Преимущества и недостатки фильтра Блума

преимущество:

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

недостаток:

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

Применимые сценарии фильтра Блума

Дедупликация URL системы сканера
фильтрация спама
черный список

(2) Вернуть пустой объект

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

При таком подходе есть две проблемы:

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

(2) Разбивка кеша

Что такое разбивка кеша?

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

Опасность проникновения в кэш

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

Как решить?

Решение 1. Используйте блокировку мьютекса (ключ мьютекса)

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

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

Если это распределенное приложение, вам необходимо использовать распределенные блокировки.

Решение 2. Срок действия данных точки доступа не ограничен

Never expires на самом деле имеет два значения:

Физический срок действия не истекает, для ключей точки доступа не установлено время истечения срока действия.
Логическое истечение, сохраните время истечения в значении, соответствующем ключу, если обнаружится, что оно вот-вот истечет, создайте кеш через фоновый асинхронный поток

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

(3) Тайная лавина

Что такое кэш-лавина?

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

Кэш-лавинное решение

Часто используемые решения:

равномерное истечение
добавить мьютекс
кеш никогда не истекает
Стратегия двойного кэша

(1) Равномерное истечение

Установите разные сроки действия, чтобы сделать аннулирование кеша максимально однородным. Обычно к периоду действия может быть добавлено случайное значение или период действия может быть запланирован единообразно.

(2) Добавить мьютекс

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

(3) Срок действия кеша не ограничен.

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

(4) Стратегия двухуровневого кэширования

Используйте первичный и вторичный кэши:

Основной кеш: срок действия устанавливается в соответствии со значением опыта и устанавливается в качестве основного кеша чтения.После сбоя основного кеша последнее значение загружается из базы данных.

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

(4) Предварительный прогрев кэша

Что такое прогрев кеша?

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

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

Метод работы прогрева кеша

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

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

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

Переход на более раннюю версию, как правило, является операцией с потерями, поэтому постарайтесь свести к минимуму влияние перехода на более раннюю версию для бизнеса.

8. Механизм устранения памяти Redis

Стратегия устранения памяти Redis относится к стратегии обработки выбора вновь добавленных данных путем удаления старых данных, когда кэш-памяти недостаточно.

Как настроить максимальную память?

(1) Настройка через файл конфигурации

Измените файл конфигурации redis.conf.

maxmemory 1024mb //设置Redis最大占用内存大小为1024M

Примечание: maxmemory по умолчанию настроен на 0. Максимальная память Redis в 64-битной операционной системе — это оставшаяся память операционной системы.Максимальная память Redis в 32-битной операционной системе — 3 ГБ. (2) Конфигурация с помощью динамических команд

Redis поддерживает динамическое изменение размера памяти с помощью команд во время выполнения:

127.0.0.1:6379> config set maxmemory 200mb //设置Redis最大占用内存大小为200M
127.0.0.1:6379> config get maxmemory //获取设置的Redis能使用的最大内存大小
1) "maxmemory"
2) "209715200"

Классификация стратегий устранения

После того, как будет израсходована максимальная память, занятая Redis, если вы продолжите добавлять данные, как быть в этой ситуации? Фактически, Redis официально определил восемь стратегий для решения этой ситуации:

невыселение

Стратегия по умолчанию состоит в том, чтобы напрямую возвращать ошибку для запроса на запись без устранения.

allkeys-lru

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

volatile-lrulru (используется реже), наименее недавно использовавшийся. Используйте приблизительный алгоритм LRU для исключения из ключа с установленным сроком действия.

allkeys-случайный

Случайным образом исключается из всех ключей.

изменчиво-случайный

Случайным образом исключается из ключей с установленным сроком действия.

volatile-ttl

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

allkeys-lfu

lfu (наименее часто используемый), наименее часто используемая частота. Используйте приблизительный алгоритм LFU для исключения из всех ключей. Поддерживается с Redis4.0.

volatile-lfu

lfu (наименее часто используемый), наименее часто используемая частота. Используйте приблизительный алгоритм LFU для исключения из ключа с установленным сроком действия. Поддерживается с Redis4.0.

Примечание. При использовании трех стратегий volatile-lru, volatile-random и volatile-ttl, если невозможно удалить ключ с истекшим сроком действия, будет возвращена ошибка, аналогичная noeviction.

Алгоритм LRU

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

Реализация LRU в Redis

Redis использует приблизительный алгоритм LRU, который отличается от обычного алгоритма LRU. Приближенный алгоритм LRU исключает данные с помощью метода случайной выборки, каждый раз случайным образом выбирает 5 ключей (по умолчанию) и исключает из него ключи, которые использовались реже всего.

Количество выборок может быть изменено параметром maxmemory-samples, например: maxmemory-samples 10

Чем больше конфигурация maxmenory-samples, тем ближе результат исключения к строгому алгоритму LRU, но потребление ЦП также велико.

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

Redis3.0 оптимизация приблизительного LRU

В Redis 3.0 были внесены некоторые оптимизации в приблизительный алгоритм LRU. Новый алгоритм будет поддерживать пул кандидатов (размер 16), данные в пуле сортируются по времени доступа, ключ, случайно выбранный в первый раз, будет помещен в пул, а ключ, выбранный случайным образом каждый раз, будет выбирать только тогда, когда время доступа меньше, чем в пуле. Минимальное время будет помещено в пул, пока пул-кандидат не будет заполнен. Когда он заполнен, если необходимо ввести новый ключ, ключ с наибольшим временем последнего доступа (последний доступ) в пуле будет удален.

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

LFU-алгоритм

LFU (наименее часто используемые) — это новая стратегия устранения, добавленная в Redis 4.0.Его основная идея заключается в исключении ключей в соответствии с частотой их последнего доступа.

Алгоритм LFU может лучше представлять популярность ключа, к которому осуществляется доступ. Если вы используете алгоритм LRU, к ключу долгое время не обращались, а обращались лишь время от времени, то он считается горячими данными и не будет устранен, а некоторые ключи, скорее всего, будут доступны в будущее было устранено. Этого не произойдет, если используется алгоритм LFU, потому что его однократное использование не делает ключ горячими данными.

9. Есть ли в Redis механизм транзакций?

Есть механизм транзакций. Жизненный цикл транзакции Redis: Открытая транзакция: используйте MULTI, чтобы открыть транзакцию
Команда в очередь: команда для каждой операции будет добавлена в очередь, но команда в это время фактически не будет выполняться.
Отправить транзакцию: используйте команду EXEC, чтобы отправить транзакцию и начать последовательное выполнение команд в очереди.

## 10. Являются ли транзакции Redis атомарными?

Сначала посмотрите на определение атомарности в реляционной базе данных ACID: Атомарность: все операции в транзакции либо завершены, либо не завершены, и не будут заканчиваться определенной ссылкой в середине. Если во время выполнения транзакции возникает ошибка, она будет восстановлена (откат) до состояния до начала транзакции, как если бы транзакция никогда не выполнялась.

Официальный документ определяет сделку:

Транзакция — это отдельная изолированная операция: все команды внутри транзакции сериализуются и выполняются последовательно. Во время выполнения транзакции она не будет прервана командными запросами, отправленными другими клиентами.
Транзакция — это атомарная операция: выполняются либо все команды в транзакции, либо ни одна из них. Команда EXEC отвечает за запуск и выполнение всех команд в транзакции: если клиент не может выполнить EXEC из-за отключения после открытия транзакции с использованием MULTI, все команды в транзакции не будут выполнены. С другой стороны, если клиент успешно выполнит EXEC после открытия транзакции, все команды в транзакции будут выполнены.

Чиновники считают, что транзакции Redis — это атомарная операция, которая рассматривается с точки зрения выполнения или нет. Однако из определения атомарности ACID, строго говоря, транзакции Redis не являются атомарными, поскольку при последовательном выполнении команд, как только возникает ошибка выполнения команды, Redis не останавливает выполнение и не откатывает данные.

11. Почему Redis не поддерживает откат?

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

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

12. Какие команды связаны с транзакциями Redis?

(1) WATCH может обеспечить поведение проверки и установки (CAS) для транзакций Redis. Ключи, за которыми наблюдают, будут отслеживаться, и будет выясняться, были ли эти ключи изменены. Если хотя бы один из отслеживаемых ключей изменяется до выполнения EXEC, вся транзакция отменяется, и EXEC возвращает nil-reply, чтобы указать, что транзакция не удалась.

(2) МУЛЬТИ

Используется для запуска транзакции, всегда возвращает OK. После выполнения MULTI клиент может продолжать посылать на сервер любое количество команд.Эти команды не будут выполняться немедленно, а будут помещены в очередь.При вызове команды EXEC все команды в очереди будут казнен.

（3）НЕ СМОТРЕТЬ

Отмените мониторинг всех ключей с помощью команды WATCH, обычно используемой перед командами DISCARD и EXEC. Если команда EXEC или команда DISCARD выполняется первой после выполнения команды WATCH, то нет необходимости выполнять UNWATCH. Поскольку команда EXEC выполнит транзакцию, эффект от команды WATCH уже произведен; в то время как команда DISCARD отменяет транзакцию, а также отменяет весь мониторинг ключа, поэтому после выполнения этих двух команд нет необходимости выполнять НЕ СМОТРЕТЬ.

（4）УДАЛИТЬ

При выполнении команды DISCARD транзакция будет отменена, очередь транзакций будет очищена, а клиент выйдет из состояния транзакции.

(5) ИСПОЛНЕНИЕ

Отвечает за запуск и выполнение всех команд в транзакции:

Если клиент выполняет EXEC после успешного открытия транзакции, все команды в транзакции будут выполнены.

Если клиент не может выполнить EXEC из-за отключения после открытия транзакции с помощью MULTI, все команды в транзакции не будут выполнены. Важно отметить, что даже если некоторые/некоторые команды в транзакции не могут быть выполнены, другие команды в очереди транзакций продолжат выполняться, и Redis не прекратит выполнение команд в транзакции, в отличие от отношения, которое мы обычно используем откатом, например обычная база данных.

13. Что такое репликация Redis master-slave?

Репликация master-slave относится к копированию данных одного сервера Redis на другие серверы Redis. Первый называется главным узлом (master), а второй — подчиненным узлом (slave); репликация данных односторонняя, только от главного узла к подчиненному узлу.

Роль репликации master-slave

Избыточность данных: репликация ведущий-ведомый реализует горячее резервное копирование данных, что является методом избыточности данных, отличным от сохраняемости.
Восстановление после сбоя: при возникновении проблемы с главным узлом подчиненный узел может предоставить услуги для быстрого устранения сбоя; фактически это своего рода резервирование услуг.
Балансировка нагрузки: на основе репликации ведущий-ведомый в сочетании с разделением чтения и записи главный узел может предоставлять услуги записи, а подчиненные узлы могут предоставлять услуги чтения для распределения нагрузки на сервер; узлы разделяют нагрузку чтения, что может значительно увеличить параллелизм сервера Redis.
Краеугольный камень высокой доступности: репликация «главный-подчиненный» также является основой для реализации дозорных систем и кластеров, поэтому репликация «главный-подчиненный» — это основа высокой доступности Redis.

Принцип реализации master-slave репликации

Процесс репликации master-slave можно разделить на три этапа: этап установления соединения, этап синхронизации данных и этап распространения команд.

этап установления соединения

Основная функция этого этапа — установить соединение между ведущим и подчиненным узлами для подготовки к синхронизации данных.

Шаг 1: Сохраните информацию о главном узле

Команда slaveof является асинхронной. Когда команда slaveof выполняется на подчиненном узле, подчиненный узел немедленно возвращает клиенту ok. Внутри сервера подчиненного узла поддерживаются два поля, а именно поля masterhost и masterport, которые используются для хранения IP и информация о порте главного узла.

Шаг 2. Установите подключение к сокету

Подчиненный узел вызывает функцию синхронизации репликации replicationCron() один раз в секунду.Если он обнаружит, что есть главный узел, к которому можно подключиться, он создаст сокетное соединение в соответствии с IP-адресом и портом главного узла.

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

После того, как главный узел получает соединение сокета от подчиненного узла (то есть после принятия), он создает соответствующее состояние клиента для сокета и рассматривает подчиненный узел как клиент, подключенный к главному узлу.Главный узел отправляет форму командного запроса на продолжение.

Шаг 3: Отправьте команду ping

После того, как подчиненный узел становится клиентом главного узла, он отправляет команду ping для первого запроса, чтобы проверить, доступно ли сокетное соединение и может ли главный узел в настоящее время обработать запрос.

После отправки ведомым узлом команды ping могут возникнуть три ситуации:

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

(2) Тайм-аут: по истечении определенного периода времени подчиненный узел не получил ответа от главного узла, указывающего, что сокетное соединение недоступно, и подчиненный узел отключает сокетное соединение и снова подключается.

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

Шаг 4: Аутентификация

Если на подчиненном узле установлена опция masterauth, подчиненный узел должен пройти аутентификацию на главном узле; если эта опция не установлена, аутентификация не требуется. Аутентификация подчиненного узла выполняется путем отправки команды auth на главный узел, а параметром команды auth является значение masterauth в файле конфигурации.

Если состояние пароля, установленного главным узлом, согласуется с состоянием masterauth подчиненного узла (согласованное означает, что оба существуют, а пароль один и тот же, или ни один из них не существует), аутентификация проходит, и процесс репликации продолжается. ; если они несовместимы, подчиненный узел отключает сокет Connect и переподключается.

Шаг 5: Отправьте информацию о порте подчиненного узла

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

Этап синхронизации данных

После установления соединения между ведущим и подчиненным узлами может начаться синхронизация данных, которую можно понимать как инициализацию данных подчиненного узла. Конкретный метод выполнения: подчиненный узел отправляет команду psync на главный узел (Redis2.8 раньше был командой синхронизации), и синхронизация начинается.

Этап синхронизации данных является основным этапом репликации master-slave.В соответствии с текущим состоянием узла master-slave его можно разделить на полную репликацию и частичную репликацию.Эти два метода репликации и процесс выполнения команды psync будут будет объяснено позже и не будет подробно здесь.

Этап распространения команды

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

Следует отметить, что распространение команды является асинхронным процессом, то есть главный узел не ждет ответа от подчиненного узла после отправки команды записи, поэтому на самом деле трудно поддерживать согласованность в реальном времени между ведущим и подчиненные узлы, и задержка неизбежна. Степень несогласованности данных связана со статусом сети между ведущим и подчиненным узлами, частотой выполнения команды записи главного узла и конфигурацией repl-disable-tcp-nodelay в главном узле.

14. Можете объяснить принцип Sentinel (режим Sentinel)?

В режиме репликации master-slave Redis, если главный узел не может предоставлять услуги из-за сбоя, необходимо вручную повысить подчиненный узел до главного узла и в то же время уведомить клиента о необходимости обновить адрес главного узла. Этот метод обработки отказов в определенной степени неприемлем.

Redis 2.8 и более поздние версии предоставляют механизм Redis Sentinel для решения этой проблемы.

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

Схема архитектуры Redis Sentinel выглядит следующим образом:

Принцип дозорного режима

Основная функция режима Sentinel заключается в том, что он может автоматически завершать обнаружение сбоев и аварийное переключение, а также уведомлять клиента, чтобы обеспечить высокую доступность. Режим Sentinel обычно состоит из набора узлов Sentinel и набора (или наборов) узлов репликации master-slave.

механизм сердцебиения

(1) Sentinel и узел Redis

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

(2) Страж и Страж

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

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

отказоустойчивость

Каждый Sentinel будет регулярно проверять пульс. Когда тайм-аут обнаружения пульса главного узла будет обнаружен, главный узел считается недоступным в это время. Такое суждение называется субъективным отключением.

После этого узел Sentinel будет использовать команду sentinel ismaster-down-by-addr, чтобы запросить у других узлов Sentinel оценку главного узла. offline, то есть считать, что узел больше не доступен. Это также объясняет, почему необходима группа узлов Sentinel, поскольку один узел Sentinel может легко неверно оценить состояние отказа.

Здесь значение кворума задается при настройке режима Sentinel.О нем будет рассказано позже.Обычно это общее количество узлов Sentinel/2+1, то есть более половины узлов могут выполнять объективную автономную оценку. после вынесения субъективных суждений в автономном режиме.

Поскольку для выполнения работы по отработке отказа требуется только один узел Sentinel, среди узлов Sentinel будет проведен еще один выбор, и лидер Sentinel будет выбран на основе алгоритма Raft для выполнения работы по отработке отказа.

Конкретные шаги для избранного лидера Sentinel для отработки отказа следующие:

(1) Выберите узел из списка подчиненных узлов в качестве нового главного узла.

Фильтровать неработоспособные или неудовлетворительные узлы;
Выберите ведомый узел с наивысшим ведомым приоритетом (приоритетом), вернитесь, если он существует, и продолжите, если он не существует;
Выберите ведомый узел с наибольшим смещением репликации, вернитесь, если он существует, и продолжите, если он не существует;
Выберите подчиненный узел с наименьшим значением runid.

(2) Ведущий узел Sentinel выполнит команду slaveof no one для выбранного подчиненного узла, чтобы сделать его главным узлом.

(3) Ведущий узел Sentinel отправит команды оставшимся подчиненным узлам, чтобы позволить им скопировать данные с нового главного узла.

(4) Лидер Sentinel обновит исходный главный узел до подчиненного узла, проследит за ним и прикажет скопировать новый главный узел, когда он восстановится.

15. Можете ли вы объяснить принцип кластера?

Причина введения режима кластера: Будь то режим ведущий-ведомый или режим дозорного, только один ведущий может записывать данные.В сценарии массивных данных и высокой параллелизма узел подвержен узким местам при записи данных.Введение Режим кластера может позволить нескольким узлам записывать данные одновременно.

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

Как показано на рисунке, режим кластера на самом деле является комбинацией нескольких структур репликации master-slave Каждая структура репликации master-slave может рассматриваться как узел, поэтому в приведенном выше кластере кластера имеется три узла.

16. В чем разница между Memcache и Redis?

Метод хранения Memecache хранит все данные в памяти, и он будет зависать после сбоя питания, а данные не могут превышать размер памяти.

Часть Redis хранится на жестком диске, что обеспечивает сохранность данных.

Тип поддержки данных

Поддержка типов данных в Memcache относительно проста.

Redis имеет богатые типы данных.

Использование базовой модели отличается

Базовые методы реализации между ними и протоколы приложений для связи с клиентами различаются.

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

17. Допустим в Redis 100 миллионов ключей, среди которых 10w ключей начинаются с некоего фиксированного известного префикса, как их все найти?

使用keys指令可以扫出指定模式的key列表：
keys pre*

В это время интервьюер спросит, какое влияние окажет заказ на онлайн-бизнес, и сразу перейдет к следующему вопросу.

18. Если этот Redis предоставляет услуги для онлайн-бизнеса, в чем проблема с использованием команды ключей?

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

19. Если есть большое количество ключей, срок действия которых нужно установить одновременно, на что следует обратить внимание?

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

20. Каковы наиболее часто используемые клиенты Redis?

Jedis: это старомодный клиент реализации Redis Java, который обеспечивает всестороннюю поддержку команд Redis.

Redisson: реализует распределенную и масштабируемую структуру данных Java.

Lettuce: расширенный клиент Redis для потокобезопасного синхронного, асинхронного и реактивного использования с поддержкой кластеров, Sentinel, каналов и кодировщиков.

преимущество:

Jedis: Более подробно предоставляет рабочие характеристики Redis.

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

Lettuce: уровень связи, управляемый событиями, основанный на платформе Netty, вызовы методов которой являются асинхронными. API Lettuce является потокобезопасным, поэтому вы можете использовать одно соединение Lettuce для выполнения различных операций.