Приближается кластер Redis — мастер-подчиненная репликация техники теневого клонирования | битва Redis (9)

задняя часть
Приближается кластер Redis — мастер-подчиненная репликация техники теневого клонирования | битва Redis (9)

Это 23-й день моего участия в Gengwen Challenge.Подробности о мероприятии:Обновить вызов

Статьи по Теме

Сводка боя Redis:Редис в действии

предисловие

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

1. Концепция

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

  • основной эффект:

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

    • ②Восстановление после сбоя: при возникновении проблемы с главным узлом подчиненный узел может предоставить услуги для достижениябыстрая отработка отказа; на самом деле является избыточностью службы.

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

    • ④Краеугольный камень высокой доступности (кластера): в дополнение к вышеперечисленным функциямРепликация master-slave также является основой для реализации Sentinel и кластера., поэтому репликация master-slave является основой высокой доступности Redis.

2. Конфигурация среды (кластер из одной машины)

  • 1. Базовая команда просмотра:

在这里插入图片描述

127.0.0.1:6379> ping  #测试是否连接成功！
PONG
127.0.0.1:6379> info replication  #查看当前redis信息
# Replication
role:master  #角色--主机
connected_slaves:0  #从机数量为0
master_replid:b9565cf2edea63b7e9860f3ef1a170d59ff7a4d4  #唯一标识的id
master_replid2:0000000000000000000000000000000000000000
#下面的这些咱不用管他是啥
master_repl_offset:0
second_repl_offset:-1
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

  • 2. Запустите три службы:

    • ①Скопируйте три файла конфигурации:

    在这里插入图片描述

    • ② Измените следующую конфигурацию:

      порт:

      在这里插入图片描述

      имя пид:

      在这里插入图片描述

      имя файла журнала:

      在这里插入图片描述

      имя dump.rdb:

      在这里插入图片描述

      ③ Запустите все и просмотрите:

      在这里插入图片描述

      在这里插入图片描述

      在这里插入图片描述

      Просмотреть все порты Redis: Докажите, что запуск прошел успешно!

      在这里插入图片描述

3. Один ведущий и два подчиненных (автономный тест)

  • 1. Признайте Большого Брата!!!

在这里插入图片描述

127.0.0.1:6380> ping
PONG
127.0.0.1:6380> slaveof 127.0.0.1 6379  #让本机认6379的机器为大哥！
OK
127.0.0.1:6380> info replication  #查看信息
# Replication
role:slave  #从机
master_host:127.0.0.1  #主机ip
master_port:6379   #主机端口
master_link_status:up
master_last_io_seconds_ago:3
master_sync_in_progress:0
slave_repl_offset:14
slave_priority:100
slave_read_only:1
connected_slaves:0
  • 2. Аналогично для второй машины посмотрим информацию о хосте:

在这里插入图片描述

127.0.0.1:6379> ping
PONG
127.0.0.1:6379> info replication
# Replication
role:master  #主机
connected_slaves:2  #有两台从机
#从机的ip、端口等信息
slave0:ip=127.0.0.1,port=6380,state=online,offset=56,lag=1  
#从机的ip、端口等信息
slave1:ip=127.0.0.1,port=6381,state=online,offset=56,lag=1

Появится приведенный выше контент, который доказывает, что наша конфигурация успешна!

  • 3. Примечание: эта конфигурация с помощью команды является «одноразовой».Если машина не работает, выключена и т. д., вам необходимо повторно идентифицировать старшего брата!

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

在这里插入图片描述

Вышеупомянутая конфигурация может быть изменена для реализации конфигурации ведущего и ведомого!

  • 4. Протестируйте операции чтения и записи:

①Мастер записывает, ведомый читает

Писать:

在这里插入图片描述

читать:

在这里插入图片描述

在这里插入图片描述

Докажите, что репликация master-slave прошла успешно!

②Если хост отключен

在这里插入图片描述

Ведомый может нормально читать данные:

在这里插入图片描述

Просмотр информации о ведомом устройстве:

在这里插入图片描述

在这里插入图片描述

Это доказывает, что, хотя мастер отключен, ведомый все еще может нормально читать исходные данные!

③ Если отключенный хост повторно подключен

在这里插入图片描述

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

④ Что делать, если ведомое устройство отключается и снова подключается?

在这里插入图片描述

在这里插入图片描述

在这里插入图片描述

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

⑤ Можете ли вы писать с машины?

在这里插入图片描述

Раб может только читать, но не писать!

  • 5. Принцип репликации:

    • После того, как ведомое устройство начнет успешно подключаться к ведущему, оно отправитsyncкоманда синхронизации

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

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

    • Инкрементная репликация:Мастер продолжает передавать все новые собранные команды модификации ведомому по очереди для завершения синхронизации, но пока мастер снова подключен, будет автоматически выполняться полная синхронизация (полная репликация)! Наши данные должны быть видны в рабе!

  • 6.Послойная ссылка

在这里插入图片描述

В это время мы также можем завершить репликацию master-slave!

  • 7. Заговор с целью узурпации престола

Если хост отключен, мы можем использовать

 SLAVEOF no one

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

在这里插入图片描述

Обращать внимание! !

老大没挂，也可以使用这个命令直接让自己变成老大！

4. Резюме

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

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

    • 2. С точки зрения емкости объем памяти одного сервера Redis ограничен.Даже если объем памяти сервера Redis составляет 256 ГБ, вся память не может использоваться в качестве памяти хранилища Redis.Вообще говоря, максимальная память, используемая одним Redis не должен быть 20G.

  • Репликация master-slave, разделение чтения и записи! В 80% случаев это операция чтения! Снизьте нагрузку на сервер! Часто используется в архитектуре! Один хозяин и два раба!

  • Пока это в компании, необходимо использовать master-slave репликацию, потому что использовать Redis на одной машине в реальном проекте невозможно!

Впереди долгий путь, и я обязательно буду его искать вдоль и поперёк~

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

Категории