Привет всем, я Сяолинь.

Прежде чем я это осознал, я написал множество статей из серии «Иллюстрированный Redis». Учитывая, что некоторые студенты брали интервью у Redis, я составил эссе Redis из восьми частей с 30 000 слов + 40 изображений и собрал более 40 вопросов для собеседования. всего.

Начнем!

контур

Познакомьтесь с Редисом

Что такое Редис?

Давайте посмотрим, как Redis официально представляет себя.

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

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

Redis Предоставляет различные типы данных для поддержки различных бизнес-сценариев, таких как String (строка), Hash (хэш), List (список)、Установить (набор)、Zсет (заказной комплект)、Растровые изображения、HyperLogLog (статистика мощности)、ГЕО (географическая информация)、Stream（поток）,и чтобыданныетипиз Все операциидаатомарностьиз,потому Команда чтоосуществлять обрабатывается одним пользователем, и проблем конкуренции за параллелизм не возникает.

Кроме того, Редис Также поддерживаетдела , настойчивость, Луа Скрипты, различные кластерные решения (репликация главный-подчиненныймодель、Режим охрана, режим кластера слайсеров), режим публикации/подписки, Механизм устранения память, механизм удаления истекшего срока действияи т. д.。

В чем разница между Redis и Memcached?

Многие говорят, что нужно использовать Redis в качестве кэша, но Memcached Это также база данных, основанная на памяти, почему бы не выбрать ее в качестве кэша? Чтобы ответить на этот вопрос, нам нужно выяснить Redis и Memcached разница. Redis и Memcached точки соприкосновения：

1. дни основе Памятьизданные Библиотека,В целомиспользовать Приходитькогда Делатькэшиспользовать。
2. У всех истек срок действия Стратегия.
3. Оба имеют очень высокую производительность.

Redis и Memcached разница：

• Redis Поддерживает больше типов (String, Hash, List, Set, ZSet) и Memcached Поддерживает только самую простую версию key-value данныетип；
• Redis Поддерживает данныеиз Выносливость, которые можно сохранить на диске и загрузить снова при перезапуске. Memcached Нет функции «Выносливость»,данные Сохранить всесуществовать Памятьсреди,Memcached перезапускается после зависания,данные пропали;
• Redis Встроенная поддержка режима кластера, В Memcached нет встроенного режима изкластера.,Вам нужно положиться на клиента, чтобы реализовать шардинг на кластерные;
• Redis Поддержка модели публикации-подписки, Lua Скрипты, дела и другие функции, при этом Memcached Не поддерживается;

Зачем использовать Redis в качестве кеша MySQL?

Главным образом потому, что Redis имеет две характеристики: «высокая производительность» и «высокий параллелизм».。

1. Redis имеет высокую производительность

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

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

2. Redis имеет высокий уровень параллелизма

QPS (количество запросов в секунду, обрабатываемых в секунду) Redis на одном устройстве в 10 раз больше, чем у MySQL. QPS одной машины Redis может легко превысить 100 000, в то время как QPS одной машины MySQL затруднительно. превысить 10 000.

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

Структура данных Redis

Каковы типы данных Redis и сценарии использования?

Redis предоставил Богатыйизданныетип,часто Видетьиз Есть пять видовданныетип：String (строка), Hash (хэш), List (список), Set (коллекция), Zset (упорядоченный набор)。

вместе с Redis В последней версии теперь поддерживаются четыре типа данных: BitMap（2.2 Новая версия), HyperLogLog (2.8 Новая версия), ГЕО (3.2 Новая версия), Стрим (5.0 новая версия)。 Redis Сценарии применения пяти типов данных:

• String Тип сценария использования: объект кэша, обычный счетчик, распределенная блокировка, общий доступ. session Информация и т. д.
• List Тип сценария следует использовать: Очередь сообщений (нет двух индивидуальных вопросов: 1. Производителям необходимо самостоятельно реализовывать глобальную уникальность. ID；2. Не могут потребляться в виде потребительских групп (данных) и т. д.
• Тип хэша: кэш-объект, корзина и т. д.
• Set Тип: сценарии расчета агрегации (объединение, пересечение, разница), такие как лайки, общий фокус на, лотерейные мероприятия и т. д.
• Zset Тип: сценарии сортировки, такие как рейтинг, сортировка по номеру телефона, имени и т. д.

Последующие версии Redis поддерживают еще четыре типа данных, а сценарии их применения следующие:

• BitMap (2.2 новая версия): Статистика двоичного состояния из сценария,напримерзнакприезжать、Определить статус входа пользователя в систему、Общее число последовательно приезжающихиспользовать домохозяйств и т.д.;
• HyperLogLog（2.8 новая версия): огромная статистика базы данных и сценарии, такие как веб-страницы миллиона уровней. UV счет и т. д.;
• GEO (3.2 новая версия): хранилище информации о географическом местоположении и сценариев, таких как Didi Taxi;
• Stream（5.0 новая версия): очередь сообщений, по сравнению со сна на основе реализации типа списка из очереди сообщений,У индивидуального есть две уникальные функции: автоматически генерировать глобально уникальный идентификатор сообщения.,Поддерживает потребление в виде группы потребителей.

::: tip

Хотите узнать больше об этом 9 тип данных, вы можете прочитать эту статью: 20 000 слов. + 20 Картина ｜ разрабатывать Redis часто Видетьданныетипиотвечатьиспользоватьсцена

:::

Как реализованы пять распространенных типов данных Redis?

я нарисовал картинку Redis данныетипи Первый этажструктура данныеиз соответствует картинке уровня, да слева Redis Версия 3.0, которая называется «Redis В книге «Проектирование и реализация» поясняется из Версия, сейчас существует читать все еще немного устарело, право да сейчас существует Redis 7.0 версия.

Внутренняя реализация строкового типа

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

• SDS может сохранять не только текстовые данные, но и двоичные данные.。потому что SDS использовать len Атрибут из значения без нулевого символа, чтобы определить, заканчивается ли строка, и SDS извсе API Все будет обрабатывать это двоичным способом. SDS магазинсуществовать buf[] Массив изданный. Итак, к SDS Нетсветовая энергиямагазинтекстданные,И умеет сохранять картинки, Аудио, видео, Сжатый документиз двоичных данных.
• **SDS Получить длину строки исходя из временной сложности да О(1)**. потому что C Языковая строка не записывает свою длину, поэтому сложность получения длины составляет О (п); SDS в структуреиспользовать len Атрибут записывает длину строки, поэтому сложность равна O(1)。
• Redis из SDS API безопасен, объединение строк не приведет к переполнению буфера.。потому что SDS существование проверит перед объединением строк SDS Соответствует ли помещение требованиям?,Если места недостаточно, емкость будет автоматически расширена.,Следовательно, это не вызовет проблем с переполнением буфера.

Внутренняя реализация типа списка

List Тип нижней структуры данныхда Зависит отдвусвязный списокилисжатый списоквыполнитьиз：

• если список из элемента индивидуального номера меньше 512 индивидуальный (значение по умолчанию, может быть list-max-ziplist-entries Конфигурация) каждый отдельный элемент в списке имеет значение меньше 64 байт (по умолчанию, настраивается list-max-ziplist-value конфигурация), Redis встречаиспользоватьсжатый списоккак List Тип нижней структуры данных；
• если список элементов не соответствует вышеуказанным условиям, Redis встречаиспользоватьдвусвязный списоккак List Тип нижней структуры данных；

носуществовать Redis 3.2 После версии, список Базовая структура данных типа данных состоит только из quicklist Реализован, замена двусвязного списокисжатый список。

Внутренняя реализация типа хеша

Hash Тип нижней структуры данныхда Зависит отсжатый списокили Хэш-таблицавыполнитьиз：

• если индивидуальный номер элемента типа Hash меньше 512 индивидуальный (значение по умолчанию, может быть hash-max-ziplist-entries конфигурации), значение все меньше 64 байт (по умолчанию, настраивается hash-max-ziplist-value Конфигурация) из, Redis встречаиспользоватьсжатый списоккак Hash Тип нижней структуры данных；
• Если элемент типа хеша не соответствует вышеуказанным условиям, Redis встречаиспользоватьХэш-таблицакак Hash Тип нижней структуры данных。

существовать Redis 7.0 , структура данных сжатого списка устарела и передана listpack структура данных Приходитьвыполнить Понятно。

Установить тип внутренней реализации

Set Тип нижней структуры данныхда Зависит отХэш-таблицаилинабор целых чиселвыполнитьиз：

• Все элементы в наборе if являются целыми числами, а количество отдельных элементов меньше 512 (по умолчанию, конфигурация set-maxintset-entries) индивидуальный, Redis встречаиспользоватьнабор целых чиселкак Set Тип нижней структуры данных；
• Если элемент из множества if не соответствует вышеуказанным условиям, то Redis использоватьХэш-таблицакак Set Тип нижней структуры данных。

ZУстановить тип внутренней реализации

Zset Тип нижней структуры данныхда Зависит отсжатый списокили Таблица прыжковвыполнитьиз：

• при заказе комплекта из отдельных элементов количество меньше 128 индивидуальный,И каждыйиндивидуальныйэлементизценить Маленький В 64 байт Когда, Редис встречаиспользоватьсжатый списоккак Zset Тип нижней структуры данных；
• Если элементы упорядоченного набора не соответствуют вышеуказанным условиям, Redis встречаиспользоватьТаблица прыжковкак Zset Тип нижней структуры данных；

В Redis 7.0 структура данных сжатого списка устарела и реализована структурой данных listpack.

::: tip

Хотите узнать больше об этом 9 вид структуры данных, вы можете прочитать эту статью: 20 000 слов. + 40 Картина ｜ разрабатывать Структура данных Redis

:::

Модель потока Redis

Является ли Redis однопоточным?

Redis одиннитьобратитесь кизда「Получить запрос клиента->запрос анализа ->руководитьданные Операции чтения и записи->отправлятьданныеклиенту」этотиндивидуальныйпроцессда Зависит отодининдивидуальныйнить（хозяиннить）завершить из,этоттакжеданасчастообъяснять Redis Это из-за одного потока.

но,Программа Redis — это не одна программа,Redis существоватьзапускатьизкогда,давстречаНачать фоновый поток（BIO）из：

• Redis существовать 2.6 Версия,встречазапускать 2 индивидуальный За кулисаминить,Ручка закрытия отдельнодокумент、AOF Эти две задачи по чистке диска;
• Redis существовать 4.0 Версияпосле,Добавлен новый человек новый из бэкенда нить,использовать Приходитьасинхронныйвыпускать Redis Память,это да lazyfree нить。Напримеросуществлять unlink key / flushdb async / flushall async В ожидании команды эти операции удаления будут отодвинуты на задний план. Нить интересоваться, преимущества да не вызовет Redis хозяиннить Застрял и остановился。поэтому,когдамы хотимудалитьодининдивидуальныйбольшой key изкогда,не хочуиспользовать del команда для удаления, потому что del дасуществоватьхозяиннитьиметь дело сиз,таквстречапривести к Redis Господи, нить лагов, поэтому нам следует использовать unlink команда — асинхронное удаление bolshoykey.

Причина Redis Для «Закрыть файл, AOF Эти задачи по «прошивке диска и освобождению Память» созданы отдельно для решения, дапотому чтоэти задачи и операции отнимают очень много времени, если позволить этим задачам заняться основной нить, то. Redis Основной поток легко блокируется, и он не может обрабатывать последующие запросы.

Фоновый поток эквивалентен потребителю. Производитель бросает трудоемкие задачи в очередь задач. Потребитель (BIO) постоянно опрашивает очередь и выполняет соответствующий метод при извлечении задачи.

Три задачи закрытия файлов, очистки AOF и освобождения памяти имеют свои собственные очереди задач:

• BIO_CLOSE_FILE,закрытиедокумент Очередь задач: после того, как в очереди появятся задачи, фон будетнастраиватьиспользовать close(fd) , Волядокумент закрыть;
• BIO_AOF_FSYNC,Задача флэш-диска AOFочередь：когда Журнал АОФ настроен как everysec После опции основной нить будет AOF Операция написания бревно инкапсулируется в индивидуальную задачу и также помещается в очередь приезжать. После того, как обнаружит, что в очереди есть задачи, фон нить будет скорректирован. fsync(fd),будет AOF документ Почистите диск,
• BIO_LAZY_FREE,lazy free Очередь задач: после того, как в очереди появятся задачи, фон будет free(obj) Освободить объект / free(dict) Удалить библиотеку данных для всех объектов / free(skiplist) Таблица релизов прыжковобъект；

Что такое однопоточный режим Redis?

Однострочный режим до Redis версии 6.0 выглядел следующим образом:

Синяя часть на картинке — это цикл событий, который отвечает за основной поток. Вы можете видеть сеть. I/O И обработка команд — это все одно нить. Redis Во время инициализации будут выполнены следующие действия:

• первый,настраиватьиспользовать epoll_create() создаватьодининдивидуальный epoll объектинастраиватьиспользовать socket() Создать индивидуальный сервер socket
• Затем,настраиватьиспользовать bind() привязать портиспользование listen() следить за socket；
• Затем,Волянастраиватьиспользовать epoll_ctl() Воля listen socket присоединиться к epoll, зарегистрируйтесь одновременно "события" подключения」иметь дело списьмочисло。

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

• первый,ПервыйнастраиватьиспользоватьОбработка функции очереди отправки,Проверьте, есть ли какая-либо задача в очереди отправки да,если есть задача отправить,тогда пройди write Клиент функции Воля отправляет кэш изданные. Если в этом раунде данные не будут отправлены, он зарегистрируется. функция обработчика событий, подождите epoll_wait Процесс после обнаружения того, что он доступен для записи 。
• Далее настройте использование epoll_wait письмочисло Дождитесь событияизприезжать Приходить：
  • еслидасобытия подключенияприезжать Приходить,новстречанастраиватьиспользоватьсобытия подключенияиметь дело списьмочисло,Долженписьмочисловстреча Делатьэтотнекоторые вещи：настраиватьиспользовать accpet Подключайтесь из socket -> настраиватьиспользовать epoll_ctl Воля на связи из socket присоединиться к epoll -> зарегистрироваться「прочитать функция обработки события;
  • еслидапрочитать событиеприезжать Приходить,новстречанастраиватьиспользоватьпрочитать событиеиметь дело списьмочисло,Долженписьмочисловстреча Делатьэтотнекоторые вещи：настраиватьиспользовать read Заставить клиента отправить изданные -> команда анализа -> команда обработки -> Клиентский объект "Воля" добавляет очередь отправки -> Результат воляосуществлять записан в области отправки приезжать и ожидает отправки кэша;
  • еслиданаписать событиеприезжать Приходить,новстречанастраиватьиспользоватьнаписать функцию обработки событий,Долженписьмочисловстреча Делатьэтотнекоторые вещи：проходить write Клиент функции Воля отправляет кэш изданные. Если в этом раунде данные не были отправлены, он продолжит регистрацию. функция обработчика событий, подождите epoll_wait Процесс после обнаружения того, что он доступен для записи 。

Почему Redis так быстро работает в одном потоке?

Официальный тест результатов да,одиннитьиз Redis Пропускная способность может быть достигнута 10 Вт/секунду,Как показано ниже:

Причина Redis Использование одного потока (сеть I/O иосуществлять Заказ）Такбыстрый,Есть несколько причин:

• Redis избольшойчастьдействоватьВсесуществовать Памятьзавершено в,и выбратьиспользовать Высокая эффективностьизструктура данных,поэтому Redis Узким местом может быть машина или полоса пропускания, а не ЦП, поскольку CPU Нетдаузкое место,Так Выбирайте это естественноиспользоватьодиннитьизрешение Понятно；
• Redis Выбиратьиспользоватьодин Модель резьбы МожеткИзбегайте конкуренции среди множества нить,Устранение затрат времени и производительности, вызванных множественным переключением,И это не вызовет проблем с взаимоблокировкой.
• Redis Выбиратьиспользовать Понятно Механизм мультиплексирования ввода-выводаиметь дело сбольшойколичествоизклиентсемьяконец Socket Запрос, ИО много Лу Фуиспользоватьмеханизмдаобратитесь кодининдивидуальныйнитьиметь дело смногоиндивидуальный IO Поток, просто мы часто слушаем приезжатьиз select/epoll механизм. Проще говоря, существовать Redis В случае запуска только одного нитиза этот механизм позволяет одновременно контролировать внутренний ядерный потенциал. Socket Подключено Розетка. Неиядерный всегда будет следить за этим Socket По запросу на подключение или данные запросы. После поступления заявки на проживание она будет передана Redis нитить обработку, благодаря чему достигается индивидуальный Redis нитьиметь дело смногоиндивидуальный IO Эффект потока.

Почему Redis использовал один поток до версии 6.0?

Мы все знаем, что однопоточные программы не могут использовать преимущества многоядерности сервера. CPU Да, так рано Redis Основная работа версии (сетевая I/O иосуществлять Заказ）почему до сих пориспользоватьодиннить Шерстяная ткань？нас Нетвред Первыйсмотретьодин ВнизRedisОфициально предоставленоизFAQ。

ядерный Значениеда：CPU Не ограничение Redis Производительностьизузкое место Местосуществовать,Чаще всего да ограничивается местом проживания Памятьбольшая МаленькийисетьI/Oиз,Так что нет ничего плохого в модели Redis «ядерный набор».,если вы хотите использовать сервис на мощном процессоре,Вы можете запустить несколько серверов на одном сервере, используя метод шардирования.

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

использовать Понятноодиннитьназад,Высокая ремонтопригодность,Отличная производительность в некоторых аспектах,но Это вносит процедурную неопределенность,Это привело к ряду проблем с одновременным чтением и письмом.,добавлена ​​сложность системы、В то же время можно сохранить существование переключателя.、Даже заблокировать и разблокировать、Взаимная блокировка приводит к потере производительности。

Почему многопоточность была введена после Redis 6.0?

Хотя Redis основная работа (сеть I/O (выполнить команду) в одной модели резьбы,носуществовать Redis 6.0 После версии несколько I/O Потоки для обработки сетевых запросов,Это дапотому чтовместе ссет Аппаратное обеспечение Улучшение производительности, Redis из Иногда возникают узкие места в производительности. I/O изобработка。

Итак, чтобы улучшить сеть I/O Степень параллелизма, Redis 6.0 для сети I/O Выбиратьиспользоватьмногонить Приходитьиметь дело с。нодлякоманда изосуществлять,Redis по-прежнему использует одну нить для обработки,Местокбольшой ДомНе поймите неправильно Redis Несколько потоков выполняют команды одновременно.

Официальное заявление Redis,Redis 6.0 Многопоточность введена в версии I/O Функции могут как минимум удвоить производительность。

Функция многопоточности ввода-вывода, поддерживаемая Redis версии 6.0. По умолчанию многопоточность ввода-вывода предназначена только для отправки данных ответа (клиентский сокет записи) и не обрабатывает запросы на чтение (клиентский сокет чтения) в многопоточном режиме. образом. Чтобы включить многопоточную обработку клиентских запросов на чтение, вам необходимо установить для элемента конфигурации io-threads-do-reads в файле конфигурации Redis.conf значение Yes.

//Запрос на чтение такжеиспользуем io больше нить
io-threads-do-reads да

В то же время файл конфигурации Redis.conf предоставляет элементы конфигурации для количества многопоточных операций ввода-вывода.

// io-threads N,выразить просветлениеиспользовать N-1 индивидуальный I/O многонить（хозяиннитьтакже Рассчитатьодининдивидуальный I/O нить）
io-threads 4

Что касается установки нити числа, официальная рекомендация даесли 4 ядерный CPU, рекомендуется установить количество потоков на 2 или 3,еслидля 8 ядерный CPU Рекомендуется установить количество потоков 6,Число нить должно быть меньше ядра ядра машины.,нить числа не в лучшую сторону.

поэтому, Redis 6.0 После версии Redis существоватьзапускатьизкогда,по умолчанию Состояние Внизвстречадополнительное создание 6 индивидуальныйнить（В число изниц здесь не входит основная нить.）：

• Redis-server ： Redisизхозяиннить,хозяинхотеть Ответственныйосуществлять Заказ;
• bio_close_file、bio_aof_fsync、bio_lazy_free: Три индивидуальных фоновых нит, соответственно асинхронные ручки закрытия задач документа.、Задача флэш-диска AOF、Выпустить миссию Память;
• io_thd_1、io_thd_2、io_thd_3：трииндивидуальный I/O нить,io-threads Значение по умолчанию: 4, так оно и начнётся 3（4-1）индивидуальный I/O многонить,использовать Приходитьделиться Redis сеть I/O из давления.

Постоянство Redis

Как Redis предотвращает потерю данных?

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

Redis имеет три метода сохранения данных:

• Журнал АОФ：Каждыйосуществлятьодинполоскаоперация записи Заказ,Просто добавьте команду изспособа написать индивидуальный документ;
• Снимок RDB：Воляопределенныйодинчасвырезатьиз Памятьданные,двоичный файл из режима записи диска;
• Микс Выносливость способ：Redis 4.0 Добавлен из метода, интегрирован AOF и RBD изпреимущество；

Как реализован журнал AOF?

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

Здесь я использую "_set name команда xiaolin_" в качестве примера, Redis Узнать После этой команды существует запись AOF Содержимое журнала следующее:

Позвольте мне объяснить это вам здесь.

«*3» означает, что текущая команда состоит из трех частей, каждая часть начинается с «

3 set» означает, что эта часть имеет 3 байта, что соответствует длине строки команды «set».

Зачем сначала выполнять команду, а потом записывать данные в журнал?

Рейдс сначала выполняет команду операции записи, а затем записывает ее в журнал AOF. На самом деле это имеет два преимущества.

• Избегайте дополнительных затрат на проверку：потому если сначала Воля напишет операцию, команду запишет приезжать Журнал АОФ, то изучите эту команду из, то есть проблема с синтаксисом команды из, прежде чем есликогда, то если не выполнить проверку синтаксиса команды, то записывается ошибка из команды приехать Журнал После АОФ, Redis существоватьиспользоватьбревно При восстановлении данные могут пойти не так.
• Нетвстречаблокироватькогдаоперация упреждающей записикоманда изосуществлять：потому Команда операции записи "чтокогда" будет записана только после успеха команды "Воля приезжать" Журнал АОФ。

Конечно, это также сопряжено с рисками:

• Данные могут быть потеряны: Можетзапускать фильмы с прокатом Можетк Можетк Можетк Внизнагрузканачальствосюжетхозяинхотеть Рассказывать Понятно, Что Redis существоватьвозвращатьсябез Приходитьпридетсяи Воля Заказписатьприезжатьжесткий диск,Сервер не работает,Эти индивидуальные данные окажутся под угрозой потери.
• Может блокировать другие операции: приезжать записывается только после успешного выполнения команды операции записи "изучить". Журнал АОФ, так к не будет блокировать когда бывшая команда изосуществлять, но потому что что Журнал АОФтакжедасуществоватьхозяиннитьсерединаосуществлять,Местоккогда Redis При установке бревнодокумента запишите диск, все еще заблокирует последующие операции и не сможет изучить.

Сколько существует стратегий обратной записи AOF?

Давайте сначала посмотрим на процесс записи журналов AOF в Redis, как показано ниже:

Конкретно:

1. Redis изучить После написания команды операции к команде Воля будет добавлена ​​фраза приезжать server.aof_buf буфер;
2. тогда пройди write() системанастраиватьиспользовать,Воля aof_buf буферизданныеписатьприезжать AOF документ, в настоящее время данные не имеют возможности писатьприезжать на жесткий диск, и необходимо скопировать внутренний ядерный буфер page cache,Ожидающийядерный Воляданныеписатьжесткий диск；
3. Конкретный размер буфера памяти определяется объемом памяти жесткого диска.

Redis предоставил 3 Эта стратегия обратной записи на жесткий диск управляет третьим шагом, упомянутым выше. существовать Redis.conf в файле конфигурации appendfsync Элементы конфигурации могут иметь следующее 3 Параметры могут быть заполнены:

• Always,Это индивидуальное слово из означает да «всего да».,Таким образом, «кит» означает «каждый раз после написания команды операции изучать»,синхронный Воля Журнал АОФданные осуществляет обратную запись на жесткий диск;
• Everysec,Это уникальное слово из означает «каждую секунду».,Таким образом, «кит» означает «каждый раз после написания команды операции изучать»,Первый Команда Воли для записи документа AOF в основной буфер,Затем Каждыйразделенныйодин Второй Волябуфервнутриизконтент, отпишитесь обратноприезжатьжесткий диск；
• No,иметь в виду Нет Зависит от Redis Контролируйте время обратной записи на жесткий диск и передайте его операционной системе для управления временем обратной записи. То есть после каждой команды операции записи сначала изучайте команду Воля писатьприезжать. AOF документизядерный буфер, а затем операционная система решает, когда содержимое буфера Воля записывается обратно на жесткий диск.

Я также суммировал преимущества и недостатки этих трех стратегий обратной записи в таблицу:

Если журнал AOF слишком велик, какой механизм сработает?

Журнал АОФдаодининдивидуальныйдокумент,вместе Сосуществовать с командами операций записи все больше и больше, большой документ будет становиться все более и более большим. есликогда AOF Если файл журнала слишком велик, это приведет к проблемам с производительностью, например, к перезапуску. Redis После этого вам нужно прочитать AOF документировать содержимое для восстановления данных, если документ большой, весь процесс индивидуального восстановления будет очень медленным.

Итак, Редис во избежание AOF документ Чем больше я пишу, тем лучшебольшой,предоставил Механизм перезаписи AOF,когда AOF После того, как размер файла превысит установленный порог, Redis будет включен AOF Переписать механизм сжатия AOF документ.

Механизм перезаписи AOF дасуществоватьпереписать,читатькогдавпередданные Библиотекасерединаизвсеключпара значений,Затем Воля Каждыйодининдивидуальныйключпара значенийиспользоватьодинполоска Заказ Записыватьприезжать「новыйиз AOF файл", подождите, пока все записи будут завершены, а затем добавьте новый AOF файл заменяет существующий AOF документ.

Подниматьиндивидуальныйпример,существовать Нетиспользоватьпереписатьмеханизмвперед,гипотезавпередназадосуществлять Понятно「_set name xiaolin_」и「_set name xiaolincoding_" эти две команды будут записаны в AOF документ.

носуществоватьиспользоватьпереписатьмеханизмназад,Сразувстречачитать name последний значение (пара ключ-значение) , а затем используйте 「set name Команда xiaolincoding» записывается в новый AOF документ,Нет необходимости записывать предыдущую первую индивидуальную команду.,потому что Оно принадлежит «историческому» порядку и больше не имеет значения. так что давай, пара индивидуальных ключей значенийсуществоватьпереписатьбревносередина Толькоиспользоватьодинполоска Заказ Сразу ХОРОШОПонятно。

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

Каков процесс перезаписи журналов AOF?

Redis изпереписать AOF Процесс состоит из фоновых дочерних процессов. bgrewriteaof завершить из,Это позволит достичь двух преимуществ:

• дочерний процесс AOF Во время перезаписи основной процесс может продолжаться. обработки запроса, чтобы избежать блокировки основного процесса;
• Дочерний процесс имеет копию основного процесса, изданную,Здесь используется дочерний процесс вместо данить,потому чтоеслидаиспользоватьнить,Память будет разделена между несколькими нить,Поэтому при существовании изменить долю Памятьданныеиз,Необходимо заблокировать для обеспечения безопасности,И это снизит производительность. И использовать дочерний процесс,При создании дочернего процесса,Родительско-дочерний процесс обмена Памятнымииз,Но этим человеком можно поделиться только в режиме только для чтения.,И любая из сторон процесса «отец-сын» изменила долю Память.,Это произойдет "при написании копировать",Таким образом, процесс «отец-сын» имеет независимую копию, изданную,Для обеспечения безопасности нет необходимости добавлять замок.

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

нопереписать процесс,Основной процесс все еще может работать нормально.,В этом проблема,переписать Журнал В процессе АОФ основной процесс изменил существующее существование. ключ-значение, то в это время произойдет копирование при записи. key-value Подпроцесс «Данныесуществовать» из Память данные несовместим с основным процессом «Из Памятьданные». Что нам теперь делать?

Чтобы решить эту проблему несогласованности данных, Redis Настройте AOF переписатьбуфер,этотиндивидуальныйбуферсуществоватьсоздавать bgrewriteaof Дочерний процесс начнет использовать его позже.

существоватьпереписать AOF во время, когда Redis осуществлятьнадодининдивидуальный Писать Заказпосле,этовстречаВ то же время я хотел бы написать индивидуальную команду для фото. 「AOF буферная зона 「AOF переписатьбуфер"。

То есть, да,существовать bgrewriteaof выполнение дочернего процесса AOF Во время перезаписи основной процесс должен выполнить следующие три задачи:

• осуществлятьклиентсемьяконец发Приходитьиз Заказ;
• Воляосуществлятьназадиз Писать Заказдобавлениеприезжать 「AOF буфер";
• Воляосуществлятьназадиз Писать Заказдобавлениеприезжать 「AOF переписатьбуфер";

Когда дочерний процесс завершит работу по перезаписи AOF (_сканирует все данные в базе данных, преобразует пары ключ-значение данных памяти в команду одну за другой, а затем записывает команду в журнал перезаписи_), будет выдан сигнал: отправляется основному процессу. Это метод межпроцессного взаимодействия, который является асинхронным.

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

• Воля AOF перезаписать извсе содержимое в буфере добавляется AOF издокумент, изготовление старых и новых индивидуальных AOF Статус изданных библиотек, сохраненных документом, соответствует;
• новыйиз AOF издокумент переименован, охватывая существующие AOF документ.

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

::: tip

Это содержимое журнала AOF. Если вы хотите узнать больше о принципе работы журнала AOF, вы можете подробно прочитать эту статью: Как реализовано сохранение AOF.

:::

Как реализован снимок RDB?

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

Чтобы решить эту проблему, Redis добавлен Снимок RDB。Местопредикатиз Снимок,Просто зафиксируйте определенный момент.,Например, когда мы фотографируем пейзаж,В этот момент изображение и информация зафиксировали фото.

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

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

Будет ли RDB блокировать потоки при создании снимков?

Redis предоставилдваиндивидуальный Заказ Приходитьгенерировать RDB файлы соответственно save и bgsave,ихизразница Сразусуществовать Вданетсуществовать「хозяиннить」внутриосуществлять：

• осуществлять Понятно save команда, она будет сгенерирована RDB документ,Зависит от Виосуществлятьдействовать Заказсуществоватьтакой жеодининдивидуальныйнить,Так что клисписать документ RDB занимает слишком много времени.,Заблокирует основной поток；
• осуществлять Понятно bgsave команда создаст отдельный подпроцесс для генерации RDB документ,так МожеткИзбегайте блокировки основного нитьиз；

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

save 900 1
save 300 10
save 60 10000

Не смотрите на название опции сохранение действительно выполняется bgsave команда, то есть будет создан дочерний процесс для генерации Снимок RDBдокумент. Если любое из вышеперечисленных условий соблюдено, оно будет выполнено. bgsave, их значения следующие:

• 900 В течение нескольких секунд библиотека данных была обновлена ​​как минимум 1 модификации;
• 300 В течение нескольких секунд библиотека данных была обновлена ​​как минимум 10 модификации;
• 60 В течение нескольких секунд библиотека данных была обновлена ​​как минимум 10000 модификации.

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

RDB существоватьосуществлять Снимокизкогда,Можно ли изменить данные?

Да, выполнить bgsave В процессе Redis все ещеВы можете продолжить обработку команд операциииз,То есть даданныеда могут быть изменены из,закрыватьключизтехнология Сразусуществовать ВТехнология копирования при записи (COW).

осуществлять bgsave Команда пройдет fork() Создайте дочерний процесс. На данный момент дочерний процесс и родительский процесс используют одну и ту же часть Памятьданныеиз, потому что. что При создании дочернего процесса он будет копировать родительский процесс из таблицы страниц, а таблица страниц но указывает на изфизическую Памятьвсе ещеодинчеловек, на этот раз основная цель операции чтения, затем основная цель bgsave Дочерние процессы не влияют друг на друга.

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

::: tip

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

:::

Почему существует смешанная настойчивость?

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

Преимущество AOF в том, что теряется меньше данных, но восстановление данных происходит не быстро.

Чтобы объединить преимущества обоих, Redis 4.0 предлагать Понятносмешиваниеиспользовать Журнал АОФи Память Снимок,Также называется смешанной выносливостью.,Оба гарантированы Понятно Redis Скорость перезапуска и снижение риска потери данных.

смешивание Выносливость Работасуществовать Журнал АОФпереписатьпроцесс,когда включится микширование Выносливость,существовать AOF При переписывании журнала форк Когда дочерний процесс выйдет, он будет первым передан в общий доступ основной общей папке и данным. RDB способ написать AOF документ, и тогда основная команда обработки операции будет записана в буфер существованияпереписать, а буфер перезаписи будет увеличен командой к AOF способ написать AOF файл, после завершения записи уведомите основной процесс о добавлении нового файла, содержащего RDB Формат AOF Отформатированный AOF Файл заменяет старый AOF документ.

Другими словами, используется гибридная персистентность, AOF. документизПервая половина RDB Отформатированный Полныйколичестводанные,назад半частьда AOF Отформатированныйувеличиватьколичестводанные。

такизбенефитссуществовать, перезапустить Redis При загрузке данных, поскольку первая половина RDB содержание,такЗагрузка будет очень быстрой。

Загружено RDB Вторая половина контента будет загружена только после AOF Контент, контент здесь Redis Переписывание фонового дочернего процесса AOF период,Основная обработка рабочей команды,Можеткделатьданные меньше потеряны。

Преимущества гибридной устойчивости:

• Микс Выносливость комбайнов RDB и AOF Выносливостьизпреимущество,началодля RDB из формата, такого, что Redis Можно запустить быстрее и в сочетании с AOF из-за собственности, снижается риск потери большого количества данных.

Недостатки гибридной устойчивости:

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

Кластер Redis

Как Redis обеспечивает высокую доступность сервиса?

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

репликация главный-подчиненный

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

Главный сервер может выполнять операции чтения и записи.,когда автоматически синхронизирует операцию записи с сервером при возникновении операции записи,А с серверов вообще да только чтение,И примите команду операции записи, синхронизированную основным сервером.,Затемосуществлятьэтотполоска Заказ。

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

Уведомление,хозяинотмежду серверамииз Заказкопироватьдаасинхронныйруководитьиз。

Конкретно,существует основной этап распространения команды сервера,После того, как главный сервер получит команду «приехать новое из записи».,будет отправлен на сервер. но,Главный сервер не ждет, пока сервер приезжатьот действительно выполнит команду.,Затем верните результаты клиенту.,А сам основной сервер существует локально после выполнения команды,Просто пойду в клиент и возвращает результат. еслиот сервер еще не изучил основной сервер, синхронизированный из команды,Есть несоответствия между основными серверами.

Следовательно, строгая гарантия согласованности не может быть достигнута (данные «главный-подчиненный» всегда остаются согласованными), и несогласованность данных неизбежна.

::: tip

Хотите узнать больше подробностей Redis репликация принцип работы главный-подчиненный, детализированный синий цвет: репликация главный-подчиненныйдакаквыполнитьиз？

:::

Режим охраны

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

Чтобы решить эту проблему, Redis добавлен Режим охраны（Redis Sentinel）,потому что Режим охраны готов следить за основным сервером,и предоставитьОсновной отузел аварийного переключения из функции.

::: tip

Хотите узнать больше подробностей Redis Подробнее о принципе работы Sentinel можно прочитать в этой статье: Как реализован Sentinel?

:::

Режим срезового кластера

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

Redis Cluster Решение использует хэш-слот (Hash Slot) для обработки отношений сопоставления между даннымииузел. существовать Redis Cluster плансередина,одининдивидуальныйкусочеккластерделиться 16384 индивидуальныйхеш-слот,Эти хеш-слоты похожи на разделы данных.,Каждыйиндивидуальныйключпара все воспоминания будут основаны на этом Ключ привязан к месту проживания-индивидуальныйхеш-слот. Конкретный процесс изучения разделен на два больших этапа:

• По ключевому параграфу значенийиз ключ,согласно CRC16 алгоритм计Рассчитатьодининдивидуальный 16 bit изценить。
• Сноваиспользовать 16bit пара значений 16384 Возьмем модуль и получим 0~16383 В диапазоне из модуля каждый индивидуальный модуль представляет собой индивидуальный соответствующий номер изхеш-слота.

Следующий вопрос: как эти хэш-слоты сопоставляются с конкретными узлами Redis? Есть два варианта:

• Равномерно распределены: существоватьиспользовать cluster create Команда для создания Кластер RedisКогда, Редис Автоматически распределит всеш-слоты равномерно по приезжающемукластерузел. Например, в кластере есть 9 индивидуальныйузел,но Каждыйиндивидуальныйузел Верхний бакизиндивидуальныйчислодля 16384/9 индивидуальный。
• Ручное распределение: Доступно киспользовать cluster meet Команда вручную устанавливает соединение между узлом, образующим кластер, а затем использует cluster addslots Заказ,обратитесь к Конечно Каждыйиндивидуальныйузелначальствоизхеш-слотиндивидуальныйчисло。

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

Кластер срезов на рисунке выше имеет в общей сложности 2 узлы, предполагая, что есть 4 Хэш-слот (Слот 0～Slot 3), мы можем вручную выделить хеш-слоты с помощью таких команд, как node 1 Сохранить хэш-слот 0 и 1. Узел 2 Сохранить хэш-слот 2 и 3。

redis-cli -h 192.168.1.10 –p 6379 cluster addslots 0,1
redis-cli -h 192.168.1.11 –p 6379 cluster addslots 2,3

Затем существованиекластер запускается из процесса, ключ1 и key2 Рассчитано CRC16 После значения указывается общее количество хеш-слотов. 4 Возьмите модуль, а затем сопоставьте его с хеш-слотом в соответствии с результатами соответствующего модуля. 1 (соответствует узлу 1) и хеш-слот 2 (соответствует узлу 2).

нуждаться Уведомлениеизда,существовать Распределение вручнуюхеш-слотчас,нуждаться Пучок 16384 Все слоты были выделены, в противном случае Кластер Redis работает неправильно.

Что делать, если разделение кластера приводит к потере данных?

Что такое расщепление мозга?

Давайте сначала разберемся в феномене кластерного расщепления мозга. Это похоже на то, что у человека два мозга, так кто же ими управляет?

Таксуществовать Redis В чем заключается феномен потери данных, вызванный разделением кластера?

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

В это время,Часовой также обнаружил, что главный узел потерял связь.,Он думает, что основной блок не работает (но на самом деле основной блок работает нормально),Только у дасеть проблема),Вдадозорный Сразувстречасуществовать「отузел」серединавыбирать Подниматьвнеодининдивидуальный leader В качестве главного узла кластер теперь имеет два главных узла. —— Появляется расщепленный мозг。

Затем,сеть внезапно исцелилась,дозорныйпотому Тот, кто ранее избрал нового владельца узла, понизит старого владельца узла до отузел (А), а затем отузел (А) Пойду вновыйхозяинузелпроситьданныесинхронный,потому что Первая синхронизация находится в режиме полной синхронизации. В это время изотузел (А) очистит свои локальные изданные, а затем выполнит полную синхронизацию. так, процесс предыдущего клиента существует A написанные будут потеряны, а у дакластера возникнет проблема с расщеплением мозга.。

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

решение

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

существовать Redis В файле конфигурации мы можем установить два параметра:

• min-slaves-to-write x, главный узел должен иметь как минимум x индивидуальныйотузелсоединять,если Маленький Вэтотиндивидуальныйчисло,Лорд узел запретил бы запись данных.
• min-slaves-max-lag x, мастер отданныекопировать синхронизацию, задержка не может превышать x Второй,если больше, чем,Лорд узел запретил бы запись данных.

мы можем поставить min-slaves-to-write и min-slaves-max-lag Эти два элемента конфигурации используются вместе, и для них установлены определенные пороговые значения соответственно. N и T。

Требование после объединения этих двух элементов конфигурации заключается в том, что подчиненная библиотека, подключенная к главной библиотеке,должна иметь как минимум N индивидуальныйот Библиотека,ихозяин Библиотекаруководитьданныекопироватьчасиз ACK Задержка сообщения не может превышать T секунд, иначе основная библиотека больше не будет получать запросы на запись от клиента.

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

Когда откроется новая главная библиотека приезжать,Только новая основная библиотека может получать и обрабатывать запросы клиентов.,в это время,Вновь написанные изданные будут вписаны непосредственно в заселение в новую главную библиотеку. Исходная основная библиотека будет понижена до уровня библиотеки Sentinel.,Даже если оно изданное опустеет,Новые данные не будут потеряны.

Приведем еще один пример.

Предположим, мы установили min-slaves-to-write на 1, min-slaves-max-lag на 12 с и сентри вниз после миллисекунд на 10 с. Основная библиотека по какой-то причине зависает на 15 с, в результате чего Sentinel решил, что Основная база данных была объективно отключена и начала выполнять переключение главный-подчиненный.

В то же время,поскольку исходная основная библиотека застряла 15s,безесть одинот Библиотекаспособныйи Оригиналхозяин Библиотекасуществовать 12s Репликация данных выполняется внутри базы данных, и исходная основная база данных не может принимать запросы клиентов.

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

Удаление Redis с истекшим сроком действия и удаление памяти

Какова стратегия удаления по истечении срока действия, используемая Redis?

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

Каждый раз, когда мы против одного человека key Когда срок действия установлен, Redis воля key приноситьначальство Истекшийчасмеждухранилищеприезжатьодининдивидуальныйсловарь с истекшим сроком действия（expires dict), то есть «словарь с истекшим сроком действия» сохраняет все key срок годности.

когданас Запросодининдивидуальный key Когда, Редис Сначала проверьте key данетжитьсуществовать Всловарь с истекшим сроком действиясередина：

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

Redis использоватьиз Истекшийудалить Стратегияда「Ленивое удаление + обычное удаление」этотдвадобрый Стратегиясоответствоватьииспользовать。

Что такое стратегия ленивого удаления?

Ленивое удаление Стратегияиз Как это сделать,Не удаляйте ключи с истекшим сроком действия активно.,Каждый Второсортныйотданные Библиотекадоступ key время, все обнаружения key Если срок действия истек, удалите его, если срок действия истек. key。

Блок-схема отложенного удаления выглядит следующим образом:

инерцияудалить Стратегияизпреимущество：

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

инерцияудалить Стратегияизнедостаток：

• еслиодининдивидуальный key Срок действия истек, и этот индивидуальный key И все равно держать существующие в библиотеке, то до тех пор, пока у этого индивида не истечет срок действия. key одинпрямой Нетпосетил,Он не будет выпущен,причина Понятноодин Конечноиз Памятькосмоснапрасно тратить。так,Ленивое удаление Стратегии недружелюбно к Память.

Что такое политика запланированного удаления?

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

Обычный процесс удаления Redis:

1. отсловарь с истекшим сроком Случайно выбрано из действия 20 индивидуальный key；
2. проверьте это 20 индивидуальный key да Нет истекшего срока, и удалить просроченный из key；
3. если срок действия этого раунда проверок истек key из количества, превышающего 5 индивидуальный (20/4), также известный как да "Просроченный key из Количество"Пропорция"Выбирается случайным образом key изчислоколичество」большой В 25%, затем продолжайте повторять шаги 1;если Истек срок key доля меньше, чем 25%, перестаньте удалять просроченные ключ, а затем дождитесь следующего раунда, чтобы проверить еще раз.

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

Процесс периодического удаления выглядит следующим образом:

обычныйудалить Стратегияизпреимущество：

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

обычныйудалить Стратегияизнедостаток：

• Трудно определить продолжительность и частоту операций удаления. если слишком часто существовать, это будет CPU Недружественное слишком мало еслиосуществлятьиз - это то же самое, что ленивое удаление, срок действия истек; key Отчетность о прибытии не будет выдана вовремя.

Можетксмотретьприезжать,Ленивое удаление Стратегии регулярное удаление Стратегия каждая имеет свои собственные изпреимущество,Месток Redis выбирать「Ленивое удаление + обычное удаление」этотдвадобрый Стратегиясоответствоватьииспользовать,кпроситьсуществовать Разумныйиспользовать CPU Найдите баланс между временем и избеганием потерь.

::: tip

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

:::

Как при запуске Redis будут обрабатываться ключи с истекшим сроком действия?

Постоянство Документ Redis имеет два формата: RDB (Redis Database）и AOF（Append Only File), давайте посмотрим на статус представления просроченного ключа, существующего в этих двух форматах.

RDB Файл разделен на два этапа: Фаза создания документа RDBифаза загрузки。

• Фаза создания документа RDB：от Памятьсостояние Выносливостьстановиться RDB (документ) из, на key руководить Истекшийисследовать,Ключи с истекшим сроком действия «не будут» сохраняться в документе RDB «Доступ к месту жительства».,поэтому Redis ключи с истекшим сроком действия не будут генерировать новые RDB документ имеет какое-либо влияние.
• Этап загрузки RDB：Этап загрузки Когда используется RDB, это зависит от сервера: главный сервер все ещеотсервер,соответственноотвечатьк Вниздвадобрый Состояние：
  • если Redis да Режим работы "Основной Сервер" из, затем загружается существование RDB документчас,Программа проверит ключ, сохраненный в документе.,Ключи с истекшим сроком действия «не будут» загружаться в приезжатьданные библиотеки.。Месток Истекшийключ Нетвстречавернонагрузка入 RDB затронут главный сервер документиз;
  • если Redis да「отсервер」режим работы, затем загружается существование RDB При оформлении документа ключ да будет загружен в приезжатьданные библиотеки независимо от того, истек его срок действия или нет.。но Зависит от Вхозяинотсерверсуществоватьруководитьданныесинхронныйчас,от Изданные сервера будут очищены. Так что вообще говоря,Истекшийключвернонагрузка入 RDB Сервер документизот также не будет затронут.

AOF Файл разделен на два этапа: AOF документписатьэтапи AOF Этап перезаписи.

• AOF документписатьэтап：когда Redis к AOF модель Выносливостьчас,еслиданныеKumou индивидуальный ключ с истекшим сроком действия не был удален,Так AOF документ сохранит этот ключ с истекшим сроком действия, когда этот ключ с истекшим сроком будет удален, Redis. Пойду в AOF документдобавил один DEL команда для явного удаления ключа。
• AOF переписатьэтап：осуществлять AOF переписать, чтобы Redis серединаизключпара значенийруководитьисследовать,Ключи с истекшим сроком действия не сохраняются. Приехатьпереписать из документа AOF,поэтому Нетвстречаверно AOF переписать, вызывая какие-либо последствия.

Как бороться с ключами с истекшим сроком действия в режиме Redis master-slave?

когда Redis при работе в режиме существования mainот,библиотека не выполняет сканирование по истечении срока действия,библиотека обрабатывает истечение срока действия из пассивного состояния。это да Несмотря на тоот Библиотекасерединаиз key Срок его действия истек. Когда клиент обращается к библиотеке, вы все равно можете приехать. key Соответствующее значение возвращается как пара ключ-значение с неистекшим сроком действия.

обработка ключа с истекшим сроком действия зависит от управления главным сервером,хозяин Библиотекасуществовать key приезжать Ожидатьчас,встречасуществовать AOF Добавить элемент в файл del обратитесь кделать,Синхронизировать приезжатьвсеизот библиотеку,от Библиотекапроходитьосуществлятьэтотполоска del команда для удаления истекшего key。

Что происходит, когда память Redis заполнена?

существовать Redis избегать Памятьдостигатьприезжать Понятноопределенныйиндивидуальныйклапанценить,СразувстречакурокМеханизм устранения памяти,Этот порог — это то, что мы установили для запуска самого большого,этотценитьсуществовать Redis Его можно найти в файле конфигурации, а элемент конфигурации — maxmemory。

Каковы стратегии удаления памяти Redis?

Существует восемь типов Стратегии удаления Redis Память. Эти восемь типов Стратегиибольшой делятся на два типа Стратегии: «без удаления данных» и «с удалением данных».

1. Стратегия предотвращения уничтожения данных

noeviction（Redis3.0после,по умолчаниюиз Памятьнеиспользование Стратегия） ：это значиткогда Сбить Памятьбольшинствобольшойнастраивать Памятьчас,Не удаляя никакие данные,И да больше не предоставляет услуги,Верните ошибку напрямую.

2. Стратегии удаления данных

По категории «ликвидация данных» ее можно подразделить на два типа Стратегии: «ликвидация в рамках существования» и «ликвидация в рамках существованиявседанные». существования задает срок годности изданных на уничтожение:

• volatile-random：случайныйнеиспользованиенастраивать Понятно Истекшийчасмеждуизпроизвольныйключценить；
• volatile-ttl：отличный Первыйнеиспользованиеранее Истекшийизключценить。
• volatile-lru（Redis3.0 Извперед,По умолчанию из Память устаревшее Стратегия): устаревшее все устанавливает срок действия на основе значения ключа,Наиболее длительное отсутствиеиспользования значения ключа;
• volatile-lfu（Redis 4.0 После нового дополнения из Память исключена Стратегия): удалены все установки срока действия из значения ключа, наименьшего использования из значения ключа;

Устранение в пределах существованиявседанные:

• allkeys-random：случайныйнеиспользованиепроизвольныйключценить;
• allkeys-lru：неиспользованиевсеиндивидуальныйключценитьсередина Наиболее длительное отсутствиеиспользования значения ключа;
• allkeys-lfu（Redis 4.0 Позже добавлено из Память исключено Стратегия): исключено наименьшее значение использования ключа среди всего индивидуального значения ключа.

В чем разница между алгоритмом LRU и алгоритмом LFU?

Что такое алгоритм LRU?

LRU Полное имя Least Recently Used переводитьдлябольшинствозакрыватьбольшинствонемногоиспользовать,Будет решено исключить самые последние использованные изданные.

Традиция LRU алгоритм На основе структуры «связанного списка» элементы в связанном списке располагаются вперед и назад в соответствии с порядком операций. Последняя операция с ключом будет перемещена в начало таблицы, только когда ее необходимо удалить. необходимо удалить элементы из в конце связанного списка, потому что Элемент из в конце связанного списка представляет элемент, который не использовался в течение длительного времени.

Redis Это не реализовано таким образом LRU алгоритм,потому что Традицияиз LRU алгоритмжитьсуществоватьдваиндивидуальныйвопрос：

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

Как Redis реализует алгоритм LRU?

Redis выполнитьиздаодиндобрыйПримерный алгоритм LRU,Проект издадля лучшего спасения Память,этоизМетод реализации дасуществовать Redis из структуры объекта добавляет отдельное дополнительное поле для записи времени последнего доступа к этим данным.。

когда Redis при выполнении устранения Память,встречаиспользоватьСлучайная выборка для исключения данных,Он случайным образом выбирает 5 индивидуальных значений (это значение можно настроить),ЗатемУстранено в течение длительного временииспользоватьиз этого человека。

Преимущества алгоритма LRU, реализованного Redis:

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

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

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

Что такое алгоритм LFU?

LFU Полное имя Least Frequently Used переводитьдляРеже всего в последнее времяиспользуетсяиз,Алгоритм LFU исключает обработку данных на основе количества посещений данных.,Это изядерныймысльда“еслиданные в прошлом посещали много раз.,Так Воля Приходитьпосетилизчастотатакжевыше”。

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

Как Redis реализует алгоритм LFU?

LFU алгоритмпо сравнению с LRU Реализация алгоритма записывает больше информации о «частоте доступа к данным». Редис Структура объекта следующая:

typedef struct redisObject {
    ...
      
    // 24 биты, использовать для записи информации о доступе к объекту
    unsigned lru:24;  
    ...
} robj;

Redis в заголовке объекта lru Поле,существовать LRU алгоритм Внизи LFU Методы, используемые в алгоритме, не одинаковы.

существовать LRU в алгоритме,Redis заголовок объекта 24 bits из lru Поля используются для записи key из временной метки доступа, поэтому существует LRU режиме Redis можно настроить в соответствии с заголовке объекта lru Запись поля из значения для сравнения последнего key из Время доступа велико, от и самое долгое время не устраненоиспользоватьиз key。

существовать LFU в алгоритме,Redisзаголовок объекта 24 bits из lru Поле разделено на два сегмента для хранения, высокий 16bit хранилище ldt(Last Decrement время), используемый для записи key из Отметка времени доступа низкая; 8bit хранилище logc(Logistic счетчик), используемый для записи key из Частота посещений.

::: tip

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

:::

Дизайн кэша Redis

Как избежать лавины кэша, поломки кэша и проникновения кэша?

Как избежать лавины кэша?

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

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

Для проблемы лавины кэша мы можем использовать два решения.

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

Как избежать выброса кэша?

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

есликэшсерединаизопределенныйиндивидуальный Точка доступаданные ИстекшийПонятно,в это времябольшойколичествоизпроситьдоступ Понятно Должен Точка доступаданные,Его нельзя прочитать в открытом виде.,Прямой доступ к библиотеке данных,Библиотека данных легко перегружена большим количеством одновременных запросов.,этот СразудаРазбивка кэшаизвопрос。

Можетк Обнаружить Разбивка тайник — лавина Кэша очень похожа, вы можете думать о кэше как о Разбивке. кэшадалавина кэшаизодининдивидуальныйподмножество。 Чтобы справиться с поломкой кеша, можно использовать два упомянутых ранее решения:

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

Как избежать проникновения кэша?

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

когдаиспользоватьдоступ пользователяизданные,теперь это Нетсуществоватькэшсередина,также Нетсуществоватьданные Библиотекасередина,Причины существования запроса на доступ к кэшу,Обнаружил, что кэш отсутствует,Когда я снова захожу в библиотеку данных,Было обнаружено, что нет доступа к изданным в библиотеке данным.,Нет возможности построить кэшданные,для обслуживания последующих запросов. Тогда, когда у вас большая сумма, приходит запрос на прибытие,Библиотека данных из-за давления внезапно увеличивается,этот Сразудапроникновение в кэшизвопрос。

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

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

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

• Незаконный запрос из-за ограничения：когдаиметьбольшойколичествозлонамеренныйпроситьдоступ Нетжитьсуществоватьизданныеизкогда,Также происходит проникновение в кэш,Поэтому на входе в API существования нам необходимо определить, является ли параметр запроса да разумным.,Содержит ли параметр запроса да недопустимое значение и содержит ли поле запроса существование.,if определяет, что да является вредоносным запросом, и напрямую возвращает ошибку.,Избегайте дальнейшего доступа к кэшидированной библиотеке.
• Установить пустое значение или значение по умолчанию：когданас Проволоканачальствобизнес Обнаружитьпроникновение в кэшиз Феноменчас,Доступно для запросов изданные,Установите пустое значение или значение по умолчанию в существующем кэше.,так что последующие запросы могут читать пустое значение прибытия или значение по умолчанию в коткэш.,Вернуться к следует использовать,Вместо того, чтобы продолжать запрашивать библиотеку данных.
• сипользовать Фильтр Блума быстро определяет, существует ли датада, избегая необходимости запрашивать библиотеку данных, чтобы определить, существует ли датада：нас Можетксуществоватьписатьданные Библиотекаданныечас,использовать фильтр Блума, сделать индивидуальную пометку,Затем существоватьиспользовать, когда пользователь просит приехать,После того, как бизнес нит подтвердит, что срок кэша истек,может пройти запрос Фильтр Блума быстро определяет, содержит ли данныеда существование, если не содержит существования, то он не исп ользовать определяет, существует ли данныеда, путем запроса библиотеки данных, даже если происходит проникновение в кэш, запросы большого объема будут только запрашивать Redis Фильтр Блума без запроса библиотеки данных, гарантирующий, что библиотека данных может работать нормально, Redis Он также поддерживает фильтры Блума.

::: tip

Рекомендуемая литература: Что такое лавина, разрушение и проникновение кэша?

:::

Как разработать стратегию кэширования, позволяющую динамически кэшировать «горячие» данные?

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

Точка доступаданныединамичныйкэшиз Стратегия Общая идея：Рейтинг на основе данных о времени последнего посещения,И отфильтровать нечасто посещаемые изданные,Оставить только частые посещения изданные。

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

• Для начала сделайте индивидуальную очередь сортировки через кэш-систему (типа хранения 1000 индивидуальныйтовар）,Система определит время доступа в зависимости от продукта.,Обновить информацию об очереди,Чем позже вы посетили сайт, тем выше рейтинг продукта;
• При этом система будет регулярно отфильтровывать последних в очереди. 200 отдельные произведения, а затем случайным образом зачитывать их из отданной библиотеки 200 отдельные товары добавляются в очередь;
• Каждый раз, когда запрашивается прибытие, товар будет получен из очереди первым. Идентификатор, если он попал, просто на основе ID Сноваот Другойодининдивидуальныйкэшструктура Прочитайте фактическую информацию о продукте из данных и верните ее.

существовать Redis Может использоваться в zadd Метод и zrange Методы выполнения очереди сортировки и получения 200 индивидуальныйтовариздействовать。

Поговорим об общих стратегиях обновления кэша?

Существует 3 типа распространенных обновлений изкэша Стратегия:

• Стратегия кэширования；
• Стратегия чтения/записи через；
• Стратегия обратной записи；

В реальной разработке Redis и MySQL из Даженовый Стратегияиспользоватьизда Cache Кроме того, две другие стратегии не могут быть применены.

Стратегия кэширования

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

Шаги для написания Стратегиииз:

• Сначала обновите библиотеку данныхсерединаизданные,Затем удалите кэш-изданные.

Шаги для чтения Стратегияиз:

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

Уведомление,Порядок шагов по написанию Стратегиииз изменить нельзя.,Прямо сейчасНельзя сначала удалить кэш, а потом обновить базу данных,Причина наличия «чтения + записи» одновременно во времени,Из-за кэшидированных библиотек возникнут изданные несоответствия.

Подниматьиндивидуальныйпример,гипотезаопределенныйиндивидуальныйиспользоватьсемьяизвозрастда 20, запрос A Чтобы обновить возраст пользователя до 21. Так он удалит контент в кэше. В это время еще один индивидуальный запрос B Чтобы прочитать это индивидуальноиспользовать домашнее извлечение, он запрашивает кэш и после обнаружения промаха читает сообщение о прибытии в библиотеку как 20, и записать его в кеш, затем запросить A Продолжайте изменять библиотеку данных, Воляиспользовать домохозяйство по возрасту обновлено до 21。

финальный,Должениспользоватьсемьявозрастсуществоватькэшсерединада 20（старыйценить）,существоватьданные Библиотекасерединада 21（новыйценить）,кэшиданные Библиотекаизданные Нетодин К。

для Что「Сначала обновите библиотеку данных Сноваудалитькэш」Нетвстречаиметьданные Нетодин Кизвопрос？

Продолжайте использовать «Читать + написать «запрос параллельного сценария для анализа».

еслиопределенныйиндивидуальныйиспользоватьсемьяданныесуществоватькэшсередина Нетжитьсуществовать,просить A При чтении данных возраст запрашивается из базы данных. 20,существоватьеще нетписатькэшсерединачас Другойодининдивидуальныйпросить B Обновить данные. Он обновляет библиотеку данных по мере возраста 21 и очистите кэш. Запрос в это время A Читать отданные в библиотеке как приезжатьизаж 20 изданныеписатьприезжатькэшсередина。

финальный,Должениспользоватьсемьявозрастсуществоватькэшсерединада 20（старыйценить）,существоватьданные Библиотекасерединада 21 (новое значение), данные кэшидированной библиотеки противоречивы. отначальстволапшаизтеорияначальствоанализировать,Сначала обновите библиотеку данных,Если вы удалите кэш еще раз, возникнут проблемы с несогласованностью.,Но на самом деле,Вероятность возникновения этой проблемы невелика.。

потому что кэшизписать обычно намного быстрее, чем данные Библиотекаизписать.,Местоксуществоватьдействительныйсерединаочень难вне现просить B База данных обновлена ​​и кэш удален, запросите A Только что закончил обновлять ситуацию. И однажды попросил A раньше, чем просили B Если кэш был обновлен до удаления кэша, то следующий запрос будет, потому что вкэш не удаляется, а отданные перечитываются в библиотеке, поэтому такого несоответствия не произойдет.

Стратегия Cache Aside подходит для сценариев, в которых больше читается и меньше пишется.,Не подходит для написания нескольких сцен.,Когда потому чтокогдаписать чаще,кэш-изданные будут часто чистить,это окажет некоторое влияние на процент попаданий кэшиз. если у бизнеса строгие требования к кэш-рейту,Так Можеткучитыватьдвадобрыйрешение：

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

Стратегия чтения/записи через

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

1. Прочтите стратегию

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

2、Написать через Стратегия

когдаиметьданные Даженовыйизкогда,Первый Запросхотетьписатьизданныесуществоватькэшсерединаданетужежитьсуществовать：

• есликэшсерединаданныеужежитьсуществовать,Затем обновите кэш-изданные,А приезжатьданные библиотеки обновляются синхронно кэш-компонентом,Затемкэшкомпонентыинформироватьотвечатьиспользоватьпрограмма Даженовыйнадстановиться。
• есликэшсерединаданные Нетжитьсуществовать,Непосредственное обновление библиотеки данных,Затемвозвращаться；

Ниже Read Through/Write Through Стратегияиз Принципиальная схема：

Read Through/Write Through Стратегияиз Возможности, которые можно использовать кэшузел вместо использования программы для работы с иданными библиотеками, существуют по сравнению с нашим процессом разработки. Cache Aside Стратегия менее распространена, поэтому мы часто используем компоненты распределенного кэша, независимо от того, да Memcached все еще Redis Ни один из них не предоставляет написанные библиотеки, автоматическую загрузку библиотеки данных и функции зданных. И когда мы будем существоватьиспользовать локальный кэшиз, можно будет рассмотреть возможность использования такой стратегии.

Стратегия обратной записи

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

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

Write Back да Проектирование архитектуры компьютера, например CPU изкэш, документ операционной системы, системные изкэш все принятыиспользовать Стратегия обратной записи。

Стратегия обратной записи особенно подходит для написания нескольких сцен.,потому что Когда происходит операция записи,Просто нужно обновить кэш,Он немедленно вернулся. например,При написании документиз,Фактически, даписатьприездокументировать система изкэш вернулась,На диск не пишет.

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

Разместите один здесь CPU кэши Памятьиспользовать Write Back Стратегияизпоток Ченг Ту：

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

Как обеспечить согласованность данных кэша и базы данных?

::: tip

Рекомендуемая литература: Как библиотека данных обеспечивает согласованность?

:::

Редис на практике

Как Redis реализует очередь задержки?

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

• существовать Оформить заказ на Taobao, JD.com и других торговых площадках,Неуплата более определенного периода времени,Заказ будет автоматически отменен;
• Когда едешь на такси,существуют Ни один автовладелец не принял заказ в указанный срок,Платформа отменит ваш заказ и напомнит, что в настоящее время нет автовладельца, который мог бы принять заказ;
• При заказе на вынос,если Продавец существующего не принял заказ в течение 10 минут,Заказ будет автоматически отменен;

существовать Redis Доступно киспользоватьиметьнабор последовательностей（ZSet）из Способ Приходитьвыполнить Задерживатьинформацияочередьиз,ZSet есть один Score свойство Доступно киспользовать Приходитьхранилище Задерживатьосуществлятьизчасмежду。

использовать zadd score1 value1 Команда всегда может создавать сообщения в памяти. повторное использование zrangebysocre Запросить ожидающие задачи, соответствующие условиям извсе, Просто циклически перемещайтесь по задаче «Изучить очередь».

Как бороться с большими ключами в Redis?

Что такое ключ Redis?

большой key не означает key изценитьоченьбольшой,ида key Переписка value оченьбольшой。

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

• String Тип из Значение большое в 10 KB；
• Hash、List、Set、ZSet Тип элемента индивидуальный количество превышает 5000индивидуальный；

большой key Какие проблемы это вызовет?

большой key Это приведет к следующим четырем последствиям:

• Блокировка тайм-аута клиента。Зависит от В Redis осуществлять Заказдаодиннитьиметь дело с,Затемсуществоватьдействоватьбольшой key Это займет больше времени и заблокирует Redis,с точки зрения клиента,Ответа долго не было.
• Вызвать перегрузку сети。Каждый Второсортныйполучатьбольшой key производитьизсетьпотокколичествосравниватьбольшой,еслиодининдивидуальный key избольшой Маленькийда 1 МБ, количество посещений в секунду 1000, то он будет генерироваться каждую секунду 1000MB Что касается трафика, то для обычной гигабитной сетевой карты это катастрофа.
• Заблокировать рабочий поток。еслииспользовать del удалитьбольшой key час,встреча Заблокировать рабочий поток, так что не сможет обрабатывать последующие команды.
• Неравномерное распределение памяти。кластер Модельсуществовать slot При равномерном сегментировании будет наблюдаться перекос в запросах данных, а некоторые могут иметь большие key из Redis узелзаниматьиспользовать Памятьмного,QPS Также сравните большой.

как найтиприезжатьбольшой key ？

1、redis-cli --bigkeys Находитьбольшойkey

может пройти redis-cli --bigkeys Команда найти большой key：

redis-cli -h 127.0.0.1 -p6379 -a "password" -- bigkeys

использоватьизкогда Уведомлениеиметь значение：

• Лучше всего выбрать команду, которая будет существовать в сети, поскольку когда основной узел работает, он блокируется;
• если Нетотузел,Затем вы можете выбрать существующий экземпляр Redis, нагруженный бизнесом, и этап с низкой пиковой нагрузкой для сканирования и запроса.,к Никакого воздействияприезжать Примеризтолькочастобегать；или ВОЗДоступно киспользовать -i Параметры управляют интервалом сканирования, чтобы избежать долговременного ухудшения качества сканирования. Redis Пример из производительности.

Недостатки этого метода:

• Этот индивидуальный метод может возвращать только самые большие объемы каждого типа, bigkey,Не удалось получитьприезжатьбольшой Маленький Рядсуществоватьвперед N Кусочекиз bigkey；
• для типа коллекции,Этот метод подсчитывает только количество элементов набора.,И да на самом деле составляет сумму использования Память. но,одининдивидуальныйсобиратьсерединаизэлементиндивидуальныйчисломного,и Нетодин Конечнозаниматьиспользоватьиз Память Сразумного。потому что,Возможно, что на каждый элемент индивидуальности приходится очень малая,такиз сленг,Даже если есть много элементов индивидуальных,Общая стоимость также невелика;

2、использовать SCAN Команда найти большой key

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

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

для типа коллекции,Есть два способа получить его:

• если иметь возможность заранее знать элементы коллекции на бизнес-уровне от среднего большого маленького,Так,Доступно киспользовать Внизлапшаиз Заказполучатьсобиратьэлементизиндивидуальныйчисло,Затем умножьте к элементов множества из среднего большого на маленькое.,так Сразуспособный获придетсясобиратьзаниматьиспользоватьиз Памятьбольшой Маленький Понятно。List тип：LLEN Команда Хэш; тип：HLEN Команда Установить; тип：SCARD Команда отсортирована; Set тип：ZCARD Заказ;
• если нельзя знать заранее, напишите коллекцию из элементов большого маленького размера,Доступно киспользовать MEMORY USAGE команда (требуется Redis 4.0 икначальство Версия）,Запросодининдивидуальныйключпара значенийзаниматьиспользоватьиз Памятькосмос。

3、использовать RdbTools Инструменты для поиска больших key

использовать RdbTools Для анализа можно использовать сторонние инструменты с открытым исходным кодом. Redis Снимок（RDB）документ,попытаться найтиприезжать Чтосерединаизбольшой key。

например,Следующая команда,Волябольшой В 10 kb из key 输внеприезжатьодининдивидуальныйлистдокумент.

rdb dump.rdb -c memory --bytes 10240 -f redis.csv

Как удалить большую key？

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

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

так,еслиодин Внизребеноквыпускать Понятнобольшойколичество Память,Время работы блок-листа «Память» в режиме ожидания увеличится,Взаимноотвечатьземля Сразувстречапричина Redis Основной нитиз заблокирован. Когда основной нитиз заблокирован, другие все запросы могут привести к тайм-ауту. Redis Соединение исчерпано, и создаются различные исключения.

поэтому,удалитьбольшой key Нам следует быть осторожными с этим шагом. Как это сделать конкретно? Вот два метода:

• Удалить пакетно
• асинхронное удаление (Redis Версия 4.0начальство）

1. Удалить пакетно

дляудалитьбольшой Hash,использовать hscan команда, получить каждый 100 поле, затем используйте hdel команда, удалять каждый раз 1 поля.

Код Python:

def del_large_hash():
  r = redis.StrictRedis(host='redis-host1', port=6379)
    large_hash_key ="xxx" #Чтобы удалить имя ключа изbighash
    cursor = '0'
    while cursor != 0:
        # использовать hscan команда,получить каждый 100 индивидуальный Поле        cursor, data = r.hscan(large_hash_key, cursor=cursor,count=100)
        for item in data.items():
                # Сноваиспользовать hdel команда, удалять каждый раз1индивидуальныйполе
                r.hdel(large_hash_key, item[0])

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

Код Python:

def del_large_list():
  r = redis.StrictRedis(host='redis-host1', port=6379)
  large_list_key = 'xxx'  #Чтобы удалить имя ключа из большого списка
  while r.llen(large_list_key)>0:
      #Каждый раз удаляем только 100 крайних правых отдельных элементов
      r.ltrim(large_list_key, 0, -101) 

дляудалитьбольшой Set,использовать sscan команда, каждый раз при сканировании коллекции 100 элементы, затем используйте srem Команда удаляет по одному ключу за раз.

Код Python:

def del_large_set():
  r = redis.StrictRedis(host='redis-host1', port=6379)
  large_set_key = 'xxx'   # Чтобы удалить имя ключа избольшойсетиз
  cursor = '0'
  while cursor != 0:
    # использовать sscan команда,каждый раз при сканировании коллекции 100 индивидуальныйэлемент    cursor, data = r.sscan(large_set_key, cursor=cursor, count=100)
    for item in data:
      # Сноваиспользовать srem Команда для удаления одного индивидуального ключа за раз
      r.srem(large_size_key, item)

дляудалитьбольшой ZSet,использовать zremrangebyrank команда, удалять каждый раз top 100 элементов.

Код Python:

def del_large_sortedset():
  r = redis.StrictRedis(host='large_sortedset_key', port=6379)
  large_sortedset_key='xxx'
  while r.zcard(large_sortedset_key)>0:
    # использовать zremrangebyrank команда, удалять каждый раз top 100 индивидуальных элементов
    r.zremrangebyrank(large_sortedset_key,0,99) 

2. Асинхронное удаление

из запуска версии Redis 4.0,Можетк Выбиратьиспользоватьасинхронное удалениеЗакон,использовать unlink замена команды del удалить。

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

Помимо активных звонков unlink Помимо команды достижения асинхронного удаления, мы также можем Пройти параметры конфигурации, автоматически выполнить асинхронныйудалить при выполнении определенных условий.

В общей сложности включены 4 сценария, все из которых по умолчанию отключены:

lazyfree-lazy-eviction no
lazyfree-lazy-expire no
lazyfree-lazy-server-del
noslave-lazy-flush no

Они обозначают из и имеют следующие значения:

• lazyfree-lazy-eviction：выражатькогда Redis Сбить Память maxmeory когда, включать ли lazy free Удаление механизма;
• lazyfree-lazy-expire：Указывает настройки Время истечения срока действия ключа, открывать ли да после истечения срока действия lazy free Удаление механизма;
• lazyfree-lazy-server-del: Некоторые команды существования будут включать есть при обработке существующих ключей существования. один Скрытыйиз del Ключевые операции, такие как rename Команда, когда целевой ключ сохранен, существует, Redis Целевые ключи будут удалены первыми, если эти целевые ключи являются индивидуальными. big ключ, это вызовет проблему блокировки удаления. Эта конфигурация указывает, включено ли да в этом сценарии. lazy free Удаление механизма;
• раб-ленивая промывка: для slave (отузел) Выполнить полную синхронизацию данных, ведомый существовать加нагрузка master из RDB документ будет запущен раньше flushall Чтобы очистить изданные, указывается, включено ли в это время да. lazy free механизмудалить.

Рекомендуется включить lazyfree-lazy-eviction, lazyfree-lazy-expire, lazyfree-lazy-server-del и другие конфигурации, которые могут эффективно повысить основную эффективность.

Для чего используются конвейеры Redis?

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

Обычный командный режим, как показано на рисунке ниже:

Конвейерный режим, как показано на рисунке ниже:

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

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

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

Поддерживает ли транзакция Redis откат?

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

Redis не предоставляет механизм отката.,Хотя Redis предоставил DISCARD Заказ,ноэтотиндивидуальный Заказ Толькоспособныйиспользовать Приходитьхозяинсдатьсяделаосуществлять,Очистить временную очередь команд,Эффекта отката проезда нет.

Ниже DISCARD Использование команды:

#читать count изценить4
127.0.0.1:6379> GET count
"1"
#Опендела
127.0.0.1:6379> MULTI 
OK
#Отправь делаиз первой индивидуальной операции и уменьши счет на 1
127.0.0.1:6379> DECR count
QUEUED
#осуществлять команда DISCARD, добровольно отказаться от дел
127.0.0.1:6379> DISCARD
OK
#Прочитайте значение a:stockiz еще раз, значение не было изменено
127.0.0.1:6379> GET count
"1"

В процессе делаосуществлять не было сообщено об ошибке, когда команда if была добавлена ​​в очередь, но после того, как дела были отправлены, фактически было сообщено об ошибке. Правильную команду все еще можно использовать в обычном режиме. Redis не обязательно гарантирует атомарность.（атомарность：деласерединаиз Заказхотеть Нет Полный部успех,Иначе все провалится).

Например, следующий пример:

#Получаем исходное значение имени
127.0.0.1:6379> GET name
"xiaolin"
#Опендела
127.0.0.1:6379> MULTI
OK
#Установим новое значение
127.0.0.1:6379(TX)> SET name xialincoding
QUEUED
#Обратите внимание, эта команда неверна
# expire Срок годности правильно представляет собой число, а не строку из десятков, но все еще Успешно присоединился к команде
127.0.0.1:6379(TX)> EXPIRE name 10 с
В ОЧЕРЕДИ
# полный фильм дела,Сообщить об ошибке
#смотретьсмотретьзаходите в гости set осуществлятьуспех,и expire осуществлятьошибка。
127.0.0.1:6379(TX)> EXEC
1) OK
2) (error) ERR value is not an integer or out of range
#Можетксмотретьприезжать,name все ещеодеялоустановлен новое значение
127.0.0.1:6379> GET name
"xialincoding"

Почему Redis не поддерживает откат транзакций?

Официальная документация Redis объясняет это следующим образом:

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

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

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

Как использовать Redis для реализации распределенных блокировок?

Распределенная блокировкадаиспользовать ВРаспределенная среда Внизи发контрольизодиндобрыймеханизм,использовать Вконтрольопределенныйиндивидуальныйресурссуществоватьтакой жеодинчасвырезать Толькоспособныйодеялоодининдивидуальныйотвечатьиспользовать Местоиспользовать。Как показано ниже:

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

Redis из SET Есть команда Параметр NX может реализовать «вставить ключ, только если он не существует»,Месток Доступно киспользоватьэто Приходитьвыполнить Распределенная блокировка：

• если key Нетжитьсуществовать,Это покажет, что вставка прошла успешно.,Доступно киспользовать Приходитьвыражать Замокуспех；
• если key житьсуществовать,Это покажет, что вставка не удалась,Доступно киспользовать Приходитьвыражать Замокнеудача。

на основе Redis узелвыполнить Распределенная блокировкачас,для операции блокировки,Нам необходимо выполнить три индивидуальных условия.

• Блокировка включает три операции: чтение переменной блокировки, проверку значения переменной блокировки и установку значения переменной блокировки.,Но это должно быть завершено с помощью атомарной операции из,так,насиспользовать SET Приказать принести NX возможность реализации блокировки;
• Переменная блокировки должна установить срок действия.,Исключение произошло после того, как свободный клиент взял замок проживания,В результате блокировку невозможно снять.,так,нассуществовать SET Добавить команду "изучить" EX/PX возможность установить срок действия;
• Значение переменной блокировки должно позволять различать операции блокировки от разных клиентов.,Свободно существуют при снятии блокировки,Произошла ошибочная операция освобождения,так, когда мы используем команду SET для установки значения переменной блокировки,Каждый индивидуальный клиент устанавливает индивидуальное уникальное значение.,использовать для идентификации клиента;

Распределенная команда, удовлетворяющая этим трем индивидуальным условиям, выглядит следующим образом:

SET lock_key unique_value NX PX 10000 

• lock_key — ключевой ключ;
• unique_value да Клиент генерирует уникальный идентификатор, чтобы отличать операции блокировки от разных клиентов;
• NX представляет собой толькосуществовать lock_key Только когда нет существования lock_key Выполнить операции настройки;
• PX 10000 Указывает настройки lock_key срок годности 10-е, это даво предупреждение Клиент обнаружил исключение и не смог снять блокировку.

Процесс разблокировки прост как да Воля lock_key ключ удаления (del lock_key), но не может удалить его случайным образом и гарантирует, что клиент заблокирован при работе с клиентом. так, при разблокировке надо сначала определить блокировку unique_value да это не заблокированный клиент, даиз, значит Воля lock_key ключ для удаления.

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

// При отпускании блокировки сначала сравните unique_value Равно ли да, чтобы избежать случайного снятия блокировки
if redis.call("get",KEYS[1]) == ARGV[1] then
    return redis.call("del",KEYS[1])
else
    return 0
end

Как только так наступит, passuse SET команда и Lua Скриптсуществовать Redis одинузелначальствонадстановиться Понятно Распределенная блокировкаиз Замоки Разблокировать。

на основе Redis Каковы преимущества и недостатки реализации распределенных блокировок?

на основе Redis выполнить Распределенная блокировкаизпреимущество：

1. Эффективная производительность（этотдавыбиратькэшвыполнить Распределенная блокировкабольшинствоядерный Сердцеизотправная точка）。
2. Легко реализовать. Многие инженеры-исследователи выбирают использование Redis Для реализации распределенных блокировок очень просто реализовать распределенные блокировки. что Redis предоставил setnx Метод, очень удобно реализовать распределенные блокировки.
3. Избегайте единых точек отказа (поскольку Redis да Развертывание по кластерам естественным образом позволяет избежать единых точек сбоя).

на основе Redis выполнить Распределенная блокировкаизнедостаток：

• Тайм-аут сложно установить。если Замокиздогонятьчасчасмеждунастраивать Проходить长,Повлияет на производительность,Если установка слишком короткого периода ожидания защитит общие ресурсы. Например, в некоторых сценах существуют,одининдивидуальныйнить A После получения блокировки прибытия изучение бизнес-кода может занять много времени, в результате чего время ожидания блокировки будет превышено и автоматически аннулировано. Обратите внимание, что. A нитьбезосуществлятьнад,Последующий нить B снова случайно удержал замок,означает, что общие ресурсы могут использоваться,Такдваиндивидуальныйнитьмеждуизобщийресурс Сразубезуправлять Законруководить Сохранять护Понятно。
  • Итак, как разумно установить тайм-аут? Мы можем основе Продлить контрактиз Способнастраиватьдогонятьчасчасмежду：Первый Давать Замокнастраиватьодининдивидуальныйдогонятьчасчасмежду,Затем запустите индивидуального опекуна.,Пусть охранник нитьсуществовать через некоторое время,Сбросьте тайм-аут индивидуальной блокировки. Способ достижения: напишите индивидуальному охраннику.,Затем оцените ситуацию с блокировкой,когда срок действия блокировки скоро истечет,Продлите договор и заблокируйте его снова,когдахозяиннитьосуществлятьнадстановитьсяназад,Просто уничтожьте замок обновления,Однако этот метод относительно сложен в реализации.
• Redis репликация главный-подчиненныймодельсерединаизданныедаасинхронныйкопироватьиз,такпривести к Распределенная блокировкаиз Нет Может Надежность。еслисуществовать Redis После того, как главный узел получает блокировку прибытия, существование не синхронизируется с другим узлом прибытия. Редис Главный компьютер не работает В настоящее время новый компьютер не работает. Redis Основной пользователь по-прежнему может получить блокировку, и все несколько служб могут получить блокировку одновременно.

Redis Как решитькластер Состояние Вниз Распределенная блокировкаиз Может Надежность？

для Понятно Сохранять证кластерсреда Вниз Распределенная блокировкаиз Может Надежность,Redis Чиновник разработал алгоритм распределенной блокировки Редлок.

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

Redlock алгоритмиз Основные идеи,да Пусть клиент и несколько отдельных пользователей, независимых от узла Redis, по очереди запросят заявку на блокировку,если клиент может успешно завершить операцию блокировки на половине компьютеров,Такнас Сразураспознаватьдля,Клиент успешно получил распределенную блокировку,В противном случае блокировка не удастся。

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

Redlock алгоритм Замоктрииндивидуальныйпроцесс：

• Первый шагда,Клиент получает время до момента (t1).
• Второй шаг заключается в том, что клиент последовательно N индивидуальный Redis узелосуществлять Замокдействовать：
  • Замокдействоватьиспользовать SET Закажи, принеси NX,Опции EX/PX,к И приведите уникальный идентификатор клиента.
  • еслиопределенныйиндивидуальный Redis узел вышел из строя, для обеспечения существования в данном случае Redlock алгоритм может продолжать работать, нам нужно установить индивидуальный таймаут для «операции блокировки» (не установить таймаут для «операции блокировки», а установить таймаут для «операции блокировки»), время ожидания операции блокировки должно быть далеко Удаленное местоположение меньше, чем срок действия блокировки, который, как правило, даустановлен. десятки миллисекунд.
• Третий шаг да, как только клиент от превысит половину (большой равен N/2+1）из Redis После успешного получения блокировки узла, получите время до повторного появления (t2), а затем рассчитайте общее время индивидуального процесса блокировки из (t2-t1). если t2-t1 < Замокиз Истекшийчасмежду,в это время,Считается, что клиент заблокирован успешно.,В противном случае блокировка считается неудавшейся.

Можетксмотретьприезжать,Замокуспеххотетьтакой жечасудовлетворитьдваиндивидуальныйсостояние（Краткое описание: если имеет более половины из Redis узелуспехизполучатьприезжать Понятно Замок,И общий расход времени не превышает блокировки эффективного времени.,Так Сразуда Замокуспех）：

• Условие 1: Более половины клиентов (большие) равны N/2+1）из Redis Успешно получен замок на узле;
• Условие 2: Общее время, потраченное большинством клиентов на получение блокировки (t2-t1), меньше годового срока установки блокировки.

После успешной блокировки,Клиенту необходимо пересчитать время действия этой блокировки,Результатом расчета является «начальное время установки и истечения срока действия блокировки» минус «общее время, затраченное большинством клиентов на получение блокировки (t2-t1)». если результат расчета слишком запоздал для завершения операции обмена данными,Мы можем снять замок,чтобы не создалось впечатление, что операция с данными еще не завершена,Срок действия блокировки истек.

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

Ссылки:

• «Проектирование и реализация Redis»
• 《Редис на практике》
• 《Redis ядерный Сердцетехнологияи Настоящий бой》
• 《Redis ядерный Сердце Оригинал理и Настоящий бой 》