«Эта статья участвовала в мероприятии Haowen Convocation Order, щелкните, чтобы просмотреть:Двойные заявки на внутреннюю и внешнюю стороны, призовой фонд в 20 000 юаней ждет вас, чтобы бросить вызов!"
предисловие
Привет, я Ураган
Индекс прошлых статей выглядит следующим образом:
00-Redis, ты действительно понимаешь?
01-Типы данных Redis, о которых вы знаете больше, чем это
02-Проем хеш-таблицы Redis
03-Почему Redis такой быстрый
04-Вы действительно понимаете постоянный AOF Redis?
05-Тайна RDB для Redis Persistence
06-Redis высокочастотные вопросы интервью Неизвестный секрет кэширования [проникновение лавинного пробоя]
передний04а также05Мы обсудили постоянство Redis, хотя Redis может полагаться на механизм постоянства для восстановления данных после сбоя машины, а затем можно делать обычные запросы.В то время служба была недоступна в период от простоя до восстановления. как Redis обеспечивает аварийное переключение с высокой доступностью?
Так как же добиться высокой доступности? Самый важный момент это избыточные данные Redis реализует избыточное хранение данных через master-slave репликацию, так что после вызова master redis down достаточно переключиться на slave, таким образом реализуя отказоустойчивость и обеспечивая высокую доступность Ну а сегодня мы в основном говорим о master-slave репликация А как переключиться на slave после того, как master не работает, мы поговорим об этом в следующей статье.
как сделать резервную копию
Я думаю, что нужно смотреть на следующие три основных концепция, прежде чем смотреть на репликацию Redis Master-Slave.
Резервное копирование делится наХолодный резерва такжеГорячий резерв, если копнуть глубже, то естьжить более.
- Горячий резерв: основной библиотекой или основным дата-центром берется бизнес-трафик,в реальном времениРезервное копирование данных в подчиненную базу данных или подчиненный центр обработки данных. Как показано ниже.
- Холодный резерв: основная база данных или основной центр обработки данных отвечает за бизнес-трафик, а резервные данные будутЗапланированное или автономное руководствоСценарий выполнения синхронизирует данные с подчиненной библиотекой или из центра обработки данных, как показано ниже.
- Активный-активный: Два ЦОДа отвечают за бизнес-трафик, а ЦОД активный и резервный.Как правило, основной ЦОД будет нести большую часть трафика, а другой ЦОД будет нести небольшую часть трафика, т.к. показано на рисунке ниже.
Примечание: Определение объяснено непосредственно здесь.Что касается того, как сделать ручное или автоматическое аварийное переключение после сбоя, эта статья не будет объяснять это.Когда мы поговорим о redis sentinel позже, мы поговорим об этом подробно. Приведенная выше диаграмма просто позволяет нам углубить наше понимание концепции резервного копирования.
Итак, к какой резервной копии относится Redis? Думаю, вы поймете после прочтения.
определение
Репликация master-slave относится к копированию данных одного сервера Redis на другие серверы Redis. Первый называется ведущим узлом (master), второй — подчиненным узлом (slave), репликация данных односторонняя, только от главного узла к подчиненному узлу. У главного узла может быть несколько подчиненных узлов, но у подчиненного узла может быть только один главный узел.
Посмотрите на картинку:
Здесь мы не будем говорить или объяснять этапы установки redis master-slave, они будут в этом онлайн-посте в блоге и на официальном сайте, я верю, что все будут успешно настроены шаг за шагом.
В основном мы объясним:
- Что испытала репликация master-slave с момента ее создания, что она синхронизирует, данные или файлы?
- Что делать, если в процессе ведущий-ведомый сеть прерывается?
- Какие факторы в процессе синхронизации увеличат нагрузку на основную библиотеку?
Полная синхронизация
Когда мы настроим синхронизацию master-slave, поскольку ранее синхронизация не выполнялась, мы сначала выполним полную синхронизацию данных с библиотекой slave.
соединение ведущий-ведомый
После установки конфигурации синхронизации ведущий-ведомый первым шагом является установление соединения между ведущим и ведомым.Главные должны узнать друг друга и установить доверительные отношения, прежде чем можно будет начать синхронизацию.
После выполнения slaveof, что получилось, смотрим на картинку и говорим:
В это время подчиненная библиотека будет активно взаимодействовать с основной основной библиотекой и отправлять команду psync, которая будет передавать два параметра главному, первый параметр — идентификатор основной библиотеки (runID), при запуске redis он будет для Генерируется сам идентификатор, а второй — это место, где ведомому нужно начать репликацию данных с ведущего, то есть смещение смещения ведомого, реплицирующего данные мазера.
В первый раз, когда слейв связался с мастером, потому что он не знал идентификатор мастера в начале, он его передал?
Поскольку это первая копия, передача -1 означает, что полная копия должна быть выполнена впервые.
Затем Мастер получает команду, переданную Ведомым, и соответствующие параметры.Если это ? и -1, он знает, что Ведомый собирается выполнить полную репликацию.Мастер посылает ведомому команду fullresync, сообщая ведомому запустить полную репликацию след., и привести свой ID, Slave сохранит эти два параметра после их получения. Посмотрите на картинку и скажите:
отправить файл rdb
Затем мастер выполнит bgsave, чтобы сгенерировать подпроцесс для завершения генерации файла rdb.После того, как файл rdb сгенерирован, он отправит файл rdb на ведомое устройство, а ведомое устройство получит файл rdb.Перед получением, он сначала очистит собственные данные базы данных Ведомого [этот процесс заблокирован], после завершения очистки начнет получать файл rdb, а после завершения приема загрузит файл rdb в память.
Здесь есть еще одна проблема.При получении файла rdb у Мастера может быть новая операция записи.Поскольку rdb это снимок памяти в определенное время, то последующие данные сюда передаваться не могут.Здесь redis принимает.Для решения используется буфер Проблема. После отправки rdb новые данные запроса на запись будут помещены в этот буфер. прием завершен. , данные master-slave согласованы, посмотрите на картинку и говорите:
Передача файла rdb:
Буферная передача:
Передача последующих команд:
На самом деле этот буфер в Redis называется буфером репликации, Redis будет генерировать такой буфер для каждого слейва, подключенного к мастеру, потому что время, когда каждый слейв начинает синхронизироваться, может быть разным, и прогресс синхронизации точно не будет одинаковым. То же самое, поэтому нам нужно настроить буфер репликации отдельно.
Пока ведомое устройство и ведущее устройство устанавливают хорошее соединение, будет установлен соответствующий буфер ведомого устройства.Если соединение будет разорвано, буфер будет освобожден.
В начале выполнения bgsave для генерации rdb все последующие запросы на запись будут сохраняться в этот буфер, то есть буфер репликации, то есть все последующие запросы на запись будут отправляться на слейв через этот буфер.
Посмотрите на картинку и скажите:
Как показано на рисунке выше, каждому подчиненному устройству соответствует буфер, который является буфером репликации.
Инкрементная репликация
На самом деле, после завершения всего вышеописанного процесса, полная репликация завершена.Пока соединение не прервется, репликация master-slave будет продолжаться.Вы когда-нибудь задумывались, что если шлюз раскачается или прервется, master- ведомое соединение отключено и перераспределено. Как это будет обрабатываться? Переделать полную копию?
Сеть прервана, что делать?
Если сеть прервется, до redis2.8 она снова пройдет полную генерацию rdb для репликации и передачи, что является очень ресурсоемкой и производительной операцией. После Redis 2.8 этот процесс был оптимизирован, и механизм добавочной репликации используется для уменьшения исходящих данных и достижения цели быстрой репликации.Следующее в основном объясняет процесс добавочной репликации.
Помните, когда выполняется полное копирование, слейву будет возвращено смещение? На самом деле, после того, как ведомое устройство получит данные, оно увеличит это смещение, чтобы записать, сколько данных в настоящее время получает ведущее устройство. Если смещение между Master и Slave равно 1000, а ведомому передается 30 байт, то смещение между Master и Slave должно быть 1030.
Если сеть прервется, она попытается повторно подключиться к Мастеру.После соединения он отправит свое собственное смещение Мастеру, и Мастер решит, следует ли выполнять инкрементную репликацию или полную репликацию на Слейв в соответствии со смещением, отправленным Раб.
Зная общий процесс, то после прерывания сети и до восстановления связи данные в период прерывания не должны синхронизироваться.Так где же хранятся данные?
Пока начинается репликация ведущий-ведомый, новые запросы на запись будут записываться в буфер с именем repl_backlog_buffer при записи в буфер репликации, который представляет собой кольцевой буфер, в котором записывается получение Мастером новых данных запроса на запись. Смещение и новая команда записи, так что после повторного подключения слейва он может отправлять команды слейву отсюда.
Взгляните на карту расположения буфера репликации и repl_backlog_buffer (кольцевой буфер), чтобы углубить впечатление:
Обратите внимание, что когда соединение не разорвано, эти два буфера существуют одновременно.Если соединение разорвано, буфер репликации, соответствующий ведомому, будет удален..
На самом деле, каждый сегмент кольца записывает текущие данные и смещение, так как текущее записанное смещение продолжает увеличиваться, потому что это кольцевой буфер, это произойдет.перезаписать предыдущие данные.
Кольцевой буфер, запись repl_backlog_buffer представляет собой аккумулированное значение смещения (master_repl_offset) нового запроса на запись, полученного текущим мастером, с указанием прогресса мастера.Когда происходит прерывание сети, все ведомые устройства будут сравниваться со смещением мастера , так это все Slave public.
Процесс инкрементной репликации
- Ведомый пытается отправить psync с runID ведущего и своим собственным смещением (slave_repl_offset).
- После того, как мастер получает psync, он определяет, следует ли выполнять добавочную репликацию или полную репликацию.
Можно выполнить инкрементную репликацию, см. рисунок:
Если полученный runID и Master runID совпадают, и смещение буфера repl_backlog_buffer будет сравниваться со смещением, отправленным Slave, если разрыв между master и slave узлами не превышает длину кольцевого буфера, или нет возникает цикл, то есть его не будет. Если данные перед перезаписью произойдут, мастер ответит ведомому «Продолжить», сообщив ведомому, что можно выполнить инкрементную репликацию.
Если обнаружится, что runID не соответствует текущему Мастеру, или разница в смещении мастера и слейва превышает длину буфера repl_backlog_buffer, то будет выполнена полная копия, так что больше здесь говорить не буду.
- Мастер отправляет команду после смещения Ведомому, смотрит на картинку и говорит.
Поскольку смещение, отправленное ведомым устройством, равно 998, а теперь смещение ведущего устройства равно 1000, ведущее устройство будет продолжать передавать команды между 998 и 1000 ведомому устройству, чтобы обеспечить пошаговую передачу.
Суммировать
Теперь весь процесс репликации master-slave в redis объяснен, а теперь давайте подведем итоги.
Существует два типа синхронизации ведущий-ведомый:
- Полная синхронизация
Полный синхронный redis выполнит bgsave для создания файла rdb, а затем отправит его в подчиненную библиотеку.Перед получением из библиотеки данные подчиненной библиотеки будут очищены, чтобы предотвратить загрязнение данных, вызванное предыдущими данными.После получения файла rdb , будет загружен rdb. Синхронизация файлов с памятью не завершена. При генерации файлов rdb будут поступать новые запросы на запись. В это время эти запросы на запись будут кэшироваться в буфере, называемом буфером репликации. После загрузки rdb из библиотеки будут получены все команды записи для этого буфера, и полное копирование завершится.
Поскольку производство rdb будет блокировать основной поток, этот процесс очень ресурсоемкий.Если используется один мастер и несколько слейвов, это неизбежно увеличит нагрузку на основную библиотеку.Можно выбрать один слейв, а затем разделить один или больше рабов из библиотеки.Раб, чтобы уменьшить нагрузку на основную библиотеку.
Если вы хотите быстро генерировать rdb-файлы, вам следует уменьшить размер памяти, установленный Redis, чтобы генерация rdb-файлов была быстрой и уменьшала время блокировки.
- Инкрементная синхронизация
Если главный-ведомый отключен, главная библиотека Redis определяет, следует ли выполнять полную репликацию или добавочное копирование.Главная библиотека выполнит смещение в соответствии с идентификатором запуска, отправленным из подчиненной библиотеки и копии подчиненной библиотеки.Если идентификатор запуска и главный Идентификаторы библиотек совпадают, и у главной библиотеки разрыв смещения от ведомой не превышает длину буфера repl_backlog_buffer, и команда repl_backlog_buffer между смещениями будет скопирована на ведомую.
Два буфера:
- replication buffer
Буфер репликации создается после успешного соединения ведомой библиотеки и ведущей библиотеки.После отключения ведущей и ведомой библиотеки буфер также будет удален ведущей библиотекой.Передача команд репликации между ведущей и ведомой библиотеками будет проходить через этот буфер и Этот буфер уникален для каждой подчиненной библиотеки.
- repl_backlog_buffer
Перед началом передачи команды будет создан этот буфер.В этот буфер записывается новое смещение команды записи, полученное текущим Мастером, и сама команда.Это буфер, общий для всех ведомых.После того, как ведомый отправит psync, он будет сравниваться с смещение мастера. , чтобы решить, следует ли выполнять инкрементную репликацию.
будь осторожен:
1. Размер памяти экземпляра Redis не должен быть установлен слишком большим, что может сократить время создания файлов rdb, сократить время полной репликации и уменьшить использование полосы пропускания.
2. Если тайм-аут отключения от подчиненной библиотеки и основной библиотеки слишком велик, данные в буфере repl_backlog_buffer, вероятно, будут перезаписаны, что приведет к полной репликации.В это время вы можете установить параметр repl_backlog_size больше .
3. Буфер репликации, на этот буфер тоже стоит обратить внимание.Если прием от библиотеки медленный, то буфер будет заполнен, а redis может быть OOM.Если буфер заполнен, что будет делать redis?Redis предоставляет клиент- output- Параметр buffer-limit ограничивает размер буфера.Если он заполнен, основная библиотека отключится от слейва и удалит буфер.Если слейв снова запросит ссылку, это может вызвать порочный круг.
Вот и все, чем мы сегодня поделимся, кодировать слова и рисовать картинки непросто, я с нетерпением жду вашихНравится, подписывайтесь, делайте репост,Спасибо.
Ваши лайки и внимание — самая большая движущая сила для создания Hurricane.
Если у вас есть какие-либо вопросы, пожалуйста, оставьте сообщение, обсудите и исправляйте вместе.
Добро пожаловать, чтобы следоватьgithub
WeChat добавить: zookeeper0