Достаточно понять Redis!

Поверь мне, читай дальше, ты меня ножом порежешь ни за что!

предисловие

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

Зачем вводить кэш процессора? Прежде чем объяснять, вы должны сначала понять процесс выполнения программы.Сначала выполните программу с жесткого диска, сохраните ее в памяти, а затем отдайте процессору операцию и выполнение. Поскольку скорость памяти и жесткого диска намного ниже, чем скорость процессора, процессору приходится ждать памяти и жесткого диска каждый раз, когда выполняется программа. Внедрение технологии кэширования должно разрешить это противоречие. Процессор намного быстрее считывает память , что повышает производительность системы. В настоящее время основные процессоры имеют кэши L1 и L2, а высокопроизводительные процессоры даже имеют кэши L3.

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

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

• Например, программа часто читает базу данных, но результаты, полученные запросом, всегда одинаковы, может ли эта часть одних и тех же результатов храниться в кеше?
• Выполнение сложных операций для получения результатов запроса занимает много времени, можно ли хранить результаты операций в кеше?
• Есть некоторые данные, которые необходимо использовать на каждой странице веб-сайта, например, данные пользователя, можно ли их поместить в кеш?

Существует много способов реализовать кеширование, например, кеш пакета Google guava, распределенный кеш redis, memcached, EHcache, пользовательский кеш (например, с использованием реализации статической карты) и т. д. Объясним наиболее часто используемый редис, там будут простые операции, еще не скачал, нет? Не паникуйте, нажмитеdownload.redis.io/releases/Загрузите, шаги после завершения загрузки, пожалуйста, перейдите к моей серии руководств по Redis;

Типы данных Redis и принципы работы с памятью

Redis — это высокопроизводительная система хранения ключей и значений, основанная на языке C. Она работает в памяти, но может сохраняться на жестком диске, имеет различные структуры данных: string (строка), hash (хеш), list (список), set ( коллекция) и zset (отсортированный набор: упорядоченный набор), а также некоторые расширенные структуры данных HyperLogLog, Geo, Pub/Sub. Каждый тип хранилища будет иметь свой внутренний формат кодирования (redisObject, SDS и т. д.).

В чем Redis такой сильный?

• Высокая производительность, Redis может читать 110 000 раз/с и записывать 81 000 раз/с.

- Поддерживает различные структуры данных, такие как string (строка), list (двухсвязный список), dict (хэш-таблица), set (набор), zset (набор сортировки), hyperloglog (оценка кардинальности)

• Атомарные, все операции Redis являются атомарными, что означает, что они либо выполняются успешно, либо вообще не выполняются. Одна операция атомарна. Транзакции также поддерживаются для нескольких операций, то есть атомарности, обернутой инструкциями MULTI и EXEC.
• Поддержка операций сохранения AOF и RDB, резервное копирование данных;
• Богатые функции, Redis также поддерживает публикацию/подписку, уведомление, истечение срока действия ключа и другие функции.

Введение в типы данных

Строка (строка)

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

• set key name сохраняет строковое значение объекта

Хэш (хеш-таблица)

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

Пример:

• hset хранит коллекцию пар ключ-значение хэша (значение поля ключа hset)
• hget получает значение хеш-ключа (поле ключа hget)

Сяомин распознает Hash для хранения Redis, и что Hash действительно хранит, так это ключ (год, оценка), значение (18, 99).

Список (связанный список)

Связанные списки Redis — это простые списки строк, отсортированные в порядке вставки. Элементы можно добавлять в начало или конец списка Redis, что позволяет добавлять повторяющиеся элементы;

Пример:

• Клавиша lpop перемещает элемент слева, клавиша rpop перемещает элемент справа
• Ключ len возвращает количество элементов в связанном списке, эквивалентном select count(*) в реляционных базах данных.
• lrange key start end Команда lrange вернет все элементы с индексом от начала до конца. Начальный индекс списка Redis равен 0.

Сет (коллекция)

Коллекция Redis — это неупорядоченная коллекция строк, в которой не допускается повторение.

Пример:

• значение ключа sadd добавляет строковый элемент в набор set, соответствующий ключу, успешно возвращает 1 и возвращает 0, если элемент уже находится в наборе;
• Ключ smembers возвращает все элементы набора, соответствующего ключу, и результат неупорядочен;

SortedSet (упорядоченный набор) zset

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

Пример:

• zadd key score value Добавить одно или несколько значений и их значение в набор
• ключ zrange start end 0 и -1 означает от элемента с индексом 0 до последнего элемента (аналогично команде LRANGE)
• Сортировка вывода по количеству баллов в диапазоне zrangebycore key start end
• Ключ zremrangebyscore start end может использоваться для операций удаления диапазона

Модель памяти Redis

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

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

• Данные: в качестве базы данных данные являются наиболее важной частью;
• Память, необходимая для запуска самого процесса: сам основной процесс Redis должен занимать память, такую ​​как код, постоянный пул и т. д.;
• Буферная память: Буферная память включает клиентский буфер, буфер невыполненных копий, буфер AOF и т. д.;
• Фрагментация памяти. Фрагментация памяти создается Redis в процессе выделения и освобождения физической памяти.

Память данных Redis

На приведенном выше рисунке представлена ​​модель данных, разработанная при выполнении set hello world;

Redis — это база данных с парами ключ-значение.Каждая пара ключ-значение будет иметь dictEntry, в котором хранятся указатели на ключ и значение, next указывает на следующий dictEntry, который не имеет ничего общего с этим ключом-значением. И Key, и Value имеют соответствующие структуры хранения.Каждый тип имеет не менее двух внутренних кодов.Преимущество этого в том, что с одной стороны интерфейс отделен от реализации.Когда внутренний код нужно добавить или изменить, пользовательский это не повлияет на использование.С одной стороны, внутреннее кодирование можно переключать в соответствии с различными сценариями применения для повышения эффективности.

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

В Redis также есть более важная структура SDS — SDS — это аббревиатура от Simple Dynamic String. Вместо прямого использования строк C (то есть массивов символов, оканчивающихся нулевым символом '\0') в качестве строкового представления по умолчанию, Redis использует SDS. Что же касается их строения, то я не буду о нем здесь рассказывать, подробно представлю в следующей статье.

Транзакции и конвейеры

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

О: Атомарная транзакция — это логическая единица работы базы данных, и операции, включенные в транзакцию, либо выполняются все, либо не выполняются вовсе.

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

I: Изоляция (Isolation) Выполнение транзакции не может быть нарушено другими транзакциями.

D: Долговечность/Постоянство (Durability) После того, как транзакция зафиксирована, ее изменения в данных в базе данных должны быть постоянными.

Redis-транзакции

Давайте кратко поговорим о транзакциях в Redis и сначала представим несколько инструкций Redis, а именно MULTI, EXEC, DISCARD, WATCH, UNWATCH. Эти пять инструкций составляют основу обработки транзакций Redis.

1、multi用来组装提供事务；
2、exec执行所有事务块内的命令。
3、discard取消事务，放弃执行事务块内的所有命令。
4、watch监视一个(或多个) key ，如果在事务执行之前这个(或这些) key 被其他命令所改动，那么事务将被打断。
5、unwatch取消 watch 命令对所有 key 的监视。

Транзакция Redis может выполнять несколько команд одновременно и проходить три этапа: запустить транзакцию, поставить команду в очередь и выполнить транзакцию. И он поставляется со следующими тремя важными гарантиями:

1. Пакетные операции помещаются в буфер очереди перед отправкой команды EXEC.

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

3. Во время выполнения транзакции запросы команд, отправленные другими клиентами, не будут вставлены в последовательность команд выполнения транзакции.

В приведенном выше примере мы видим слово QUEUED, что означает, что когда мы используем MULTI для сборки транзакции, каждая команда будет кэшироваться в очереди памяти, если появляется QUEUED, это означает, что наша команда была успешно вставлена ​​в очередь кэша. Когда EXEC будет выполняться в будущем, эти команды в ОЧЕРЕДИ будут собраны в транзакцию для выполнения.

Для выполнения транзакции, если Redis включает постоянство AOF, то после выполнения транзакции команды в транзакции будут записаны на диск одновременно с помощью команды записи (постоянство будет описано ниже).

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

Проблема перед вызовом EXEC

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

Redis безжалостно отклонил выполнение транзакции из-за «предыдущей ошибки»; (ошибка) EXECABORT Транзакция отклонена из-за предыдущих ошибок.

Проблема после вызова EXEC

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

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

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

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

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

Размышляя о разнице между redis и mysql, oracle таких транзакций реляционной базы данных, прежде всего, redis позиционируется как нереляционная база данных nosql, тогда как mysql и oracle являются реляционными базами данных.

SQL-запрос, выполняемый в реляционной базе данных, может быть достаточно сложным, а проверка и анализ будут выполняться только при фактическом выполнении SQL (в некоторых случаях он может быть предварительно скомпилирован). не знает, правильный ли следующий SQL, поэтому необходимо поддерживать откат транзакции. Но в Redis Redis использует очередь транзакций для хранения команд и выполняет проверку формата, Можно заранее знать, верна ли команда, поэтому, если только одна команда неверна, транзакция не может быть выполнена.

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

Так что, в конце концов, транзакции Redis действительно поддерживают идею атомарности: разработчики не должны глупо писать код с логическими проблемами!

Конвейерная технология Redis

Redis — это служба TCP, основанная на модели клиент-сервер и протоколе запрос/ответ. Это означает, что обычно запрос следует следующим шагам: клиент отправляет запрос на сервер и ожидает возврата сокета, обычно в режиме блокировки, ожидая ответа сервера. Сервер обрабатывает команду и возвращает результат клиенту.

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

Механизм сохраняемости (RDB и AOF)

Стойкость Redis

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

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

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

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

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

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

1. Небольшой размер: тот же объем данных rdb data меньше, чем aof, потому что rdb — компактный файл;

2. Быстрое восстановление: поскольку rdb представляет собой моментальный снимок данных, репликация данных не требует повторного выполнения команд;

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

недостаток:

1. Потеря из-за сбоя: поскольку rdb заполнен, мы обычно используем сценарий оболочки для создания резервной копии rdb для Redis в течение 30 минут, 1 часа или каждый день, но не реже одного раза в 5 минут, поэтому, когда служба умирает, по крайней мере, также теряется 5 минут данных.

2. Плохая надежность: по сравнению с асинхронной стратегией aof, поскольку репликация rdb заполнена, даже если дочерний процесс fork используется для резервного копирования, когда объем данных велик, потребление диска нельзя игнорировать, особенно при доступе. Когда сумма высока, время разветвления будет увеличено, что приведет к перегрузке ЦП и относительно низкой долговечности.

Сохранение AOF

Постоянство AOF (т. е. постоянство файла только с добавлением) заключается в записи каждой команды записи, выполняемой Redis, в отдельный файл журнала (что-то вроде binlog MySQL); при перезапуске Redis снова выполнять команды в файле AOF для восстановления данных.

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

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

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

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

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

недостаток:

1. Относительно низкая производительность: для восстановления данных команду нужно выполнять повторно, а производительность ниже, чем у RDB;

2. Объем относительно больше: файл aof хоть и переписан, но все равно большой;

3. Скорость восстановления медленнее;

Репликация master-slave (разделение чтения-записи)

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

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

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

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

• Балансировка нагрузки: на основе репликации master-slave с разделением чтения и записи главный узел может предоставлять услуги записи, а подчиненные узлы могут предоставлять услуги чтения (то есть приложение подключается к главному узлу при записи данных Redis, и приложение подключается к ведомому узлу при чтении данных Redis), разделяйте нагрузку на сервер; особенно в сценарии меньшего количества записей и большего чтения разделение нагрузки чтения через несколько подчиненных узлов может значительно улучшить параллелизм сервера Redis.

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

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

(1) Основная функция этапа установления соединения заключается в установлении соединения между ведущим и подчиненным узлами для подготовки к синхронизации данных;

(2) После установления соединения можно выполнить синхронизацию данных, которая также является инициализацией данных в ведомой фазе.Фаза синхронизации данных является основной фазой репликации ведущий-ведомый.В соответствии с текущим состоянием ведущего-ведомого подчиненный узел, его можно разделить на полную репликацию и частичную репликацию. Полная репликация, как следует из названия, заключается в копировании всех данных главного узла на подчиненный узел для резервного копирования.Эффективность полной репликации слишком низка, когда объем данных главного узла велик. Поэтому в Redis 2.8 была введена частичная репликация для обработки репликации данных при прерывании сети.Главный и подчиненный узлы автоматически определяют, подходит ли текущее состояние для полной репликации или частичной репликации;

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

Подробные принципы см. в главе о репликации master-slave в руководстве по Redis!

Сторожевой механизм

Когда вы думаете о Стражах, что приходит вам на ум?

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

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

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

Архитектура механизма Redis Sentinel

Он состоит из двух частей, дозорных узлов и узлов данных:

1. Дозорный узел: дозорная система состоит из одного или нескольких дозорных узлов.Сторожевые узлы — это специальные узлы Redis, которые не хранят данные. 2. Узлы данных. И главный узел, и подчиненный узел являются узлами данных. Узел master-slave в дозорной системе ничем не отличается от обычного узла master-slave.Обнаружение и передача ошибок контролируется и завершается дозорным.Суть дозорного также является узлом redis, но он не хранит данные. Каждый дозорный узел нужно настроить только для наблюдения за главным узлом (для наблюдения можно настроить несколько главных узлов), а другие дозорные узлы и подчиненные узлы могут быть обнаружены автоматически.

Сторожевой механизм

1. Временные задачи: каждый дозорный узел поддерживает 3 временных задачи.

Получите последнюю структуру master-slave, отправив информационную команду узлу master-slave.

Получить информацию о других дозорных узлах с помощью функции публикации и подписки;

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

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

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

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

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

Все стражи, контролирующие главный узел, могут быть избраны лидерами.Алгоритм, используемый в выборах, — это алгоритм Raft; основная идея алгоритма Raft — в порядке очереди: то есть в раунде выборов часовой A посылает B стать лидером, если B не согласился с другими часовыми, он согласится с A стать лидером. Конкретный процесс выборов здесь подробно описываться не будет.Вообще говоря, процесс выбора дозорных очень быстрый.Тот, кто первым выполнит задачу в автономном режиме, обычно становится лидером.

5. Аварийное переключение: выбранный лидер-страж запускает операцию аварийного переключения, которую можно условно разделить на 3 этапа:

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

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

(3) Установите автономный главный узел в качестве подчиненного узла нового главного узла.Когда исходный главный узел вернется в режим онлайн, он станет подчиненным узлом нового главного узла.

Кластерный механизм

Предыдущий часовой механизм имеет дефекты, операция записи не может быть сбалансирована по нагрузке, а емкость хранилища ограничена одной машиной. Кластер был создан для решения этих проблем.Это решение для распределенного хранения, представленное redis3.0.Кластер состоит из нескольких узлов (узлов), и данные Redis распределяются в этих узлах. Узлы в кластере делятся на главные узлы и подчиненные узлы: только главный узел отвечает за обслуживание запросов на чтение и запись и информацию о кластере; подчиненные узлы только реплицируют данные и информацию о состоянии главного узла. Обратите внимание на узлы master-slave в механизме различения и дозорного: только главный узел в дозорном отвечает за запросы на запись, а подчиненные узлы отвечают за запросы на чтение.

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

**Хранение разделов данных**

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

Существует множество стандартов для измерения качества методов разделения данных, но наиболее важными из них являются два фактора:

• Равномерно ли распределение данных?
• Влияние добавления или удаления узлов на распределение данных.

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

Разделы хэша можно дополнительно разделить на разделы остатка хэша, разделы согласованного хэша и разделы согласованного хэша с виртуальными узлами.Ниже приводится краткое введение.

** Раздел остатка хэша **

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

**Постоянный хэш**

Согласованное хеширование: организуйте все пространство хеш-значений в виртуальное кольцо с диапазоном 0-2^32-1; для каждых данных вычислите хэш-значение в соответствии с ключом, определите положение данных в кольце, а затем Местоположение движется по кольцу по часовой стрелке, и первый сервер, который он находит, — это тот, на который он должен сопоставляться.

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

Основная проблема согласованного разбиения хэша заключается в том, что при небольшом количестве узлов добавление или удаление узлов может сильно повлиять на один узел, что приведет к серьезному дисбалансу данных. Если взять приведенный выше рисунок в качестве примера, если node2 будет удален, данные в node4 изменятся примерно с 1/4 от общего объема данных до примерно 1/2, а нагрузка будет слишком высокой по сравнению с другими узлами.

Ссылка на оригинальную статью о консистенции хэша:

Оригинальная статья «Последовательное хеширование и случайные деревья» приведена ниже:

Официальная ссылка - PDF-версия

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

Официальная ссылка - PDF-версия

Согласованное хеширование с виртуальными узлами

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

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

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

Связь узла

В дозорной системе узлы делятся на узлы данных и дозорные узлы: первые хранят данные, а вторые реализуют дополнительные функции управления. В кластере нет различия между узлами данных и узлами без данных: все узлы хранят данные и участвуют в поддержании состояния кластера. С этой целью каждый узел в кластере предоставляет два порта: общий порт и порт кластера. Порт кластера — это обычный порт + 10000 (10000 — это фиксированное значение, которое нельзя изменить). .; не использовать клиент Терминал подключен к интерфейсу кластера. Сообщения, отправляемые посредством межузловой связи, в основном делятся на пять типов: сообщения о встрече, сообщения проверки связи, сообщения проверки связи, сообщения об ошибках и сообщения публикации. Различные типы сообщений, протоколы связи, частота и время отправки, выбор принимающих узлов и т. д. различны. Конкретный смысл сообщения здесь не вводится

Узлы в кластере требуют специализированных структур данных для хранения состояния кластера. Среди структур данных, предоставляемых узлами для хранения состояния кластера, наиболее важными являются структуры clusterNode и clusterState: первая записывает состояние узла, а вторая записывает состояние кластера в целом.

отказоустойчивые выборы

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

В процессе голосования участвуют все мастера в кластере.Если более половины мастер-нод общаются с мастер-узлом по тайм-ауту (cluster-node-timeout), текущий мастер-нода считается зависшей.

Где используется Redis?

• Кэширование: Кэширование в настоящее время является нирваной, используемой почти всеми средними и крупными веб-сайтами.Разумное использование кэширования может не только повысить скорость доступа к веб-сайтам, но и значительно снизить нагрузку на базу данных. При использовании кеша для повышения производительности это также принесет больше проблем, например, если кеш внезапно выйдет из строя, что приведет к попаданию большого количества запросов в БД, как бороться с лавинами кеша и поломкой кеша, а затем спроектировать кеш с истечением срока действия время (периодическое удаление и ленивое удаление) и 6 механизмов устранения памяти. Если в БД поступает большое количество запросов, которых нет в кеше и это приводит к проникновению в кеш, то как с этим бороться, нужно фильтровать запросы и использовать эффективныеФильтр Блума(Не знаете? Перейдите к моей серии руководств по Redis, бонус за интервью!!). Как обеспечить непротиворечивость кеша и базы данных, будь то строгая согласованность или конечная согласованность.

• Распределенные проблемы: распределенные транзакции, распределенные сеансы, распределенные блокировки и т. д., краткое введение

Распределенная транзакция

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

Распределенный сеанс

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

Распределенная блокировка

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

• Очередь сообщений: Очередь сообщений является обязательным промежуточным программным обеспечением для крупномасштабных веб-сайтов, таких как насильственная маршрутизация брокера Kafka, сложная маршрутизация брокера RabbitMQ, RocketMQ и жанр связи без брокера ZeroMQ, а также другое популярное промежуточное программное обеспечение очереди сообщений, в основном используемое для разделения бизнеса. , Снижение пикового трафика и асинхронная обработка сервисов с низкой производительностью в реальном времени. Redis предоставляет функции публикации/подписки и очереди блокировки.Очередь блокировки использует механизм тайм-аута для реализации простой системы очереди сообщений. Кроме того, это нельзя сравнить с профессиональным промежуточным ПО для сообщений.

• Автоматическое истечение срока действия: По сути, приведенная выше блокирующая очередь также является примером автоматического истечения срока действия Redis, но я считаю необходимым упомянуть, что Redis может устанавливать время истечения срока действия для данных.Эта функция также широко используется всеми. не требует от пользователей Обратите внимание, производительность также относительно высока. Наиболее распространенные из них: SMS-код подтверждения, индикация продукта с учетом времени и т. Д. Нет необходимости проверять время для сравнения, как базу данных.

Примечание автора

У галантереи есть качество, у гидрологии есть чувства, поиск в WeChat [управление программой], обратите внимание на эту интересную душу