Redis-это база данных ключей и значений с открытым исходным кодом, включенная в сеть, основанная на памяти и постоянном журнале, написанная на языке ANSI C и предоставляющая API на нескольких языках. С 15 марта 2010 года разработка Redis велась компанией VMware. С мая 2013 года разработка Redis спонсируется компанией Pivotal.
Резюме
На существующих предприятиях 80% компаний в основном используют сервис redis для одной машины. В реальном сценарии красный цвет одного узла легко подвержен рискам.
Сталкиваясь с проблемами
- Остановка машины. Мы развертываемся на сервере Redis, и когда происходит сбой компьютера, нам необходимо перейти на другой сервер и убедиться, что данные синхронизированы. И данные-это самое важное. Если вам все равно, вы в принципе не будете использовать Redis.
- Узкое место в пропускной способности. Когда нам нужно расширить память Redis с 16 г до 64 Г, один компьютер не может удовлетворить этот спрос. Конечно, вы можете купить новую машину 128G.
Условия урегулирования
Для достижения большей емкости хранилища и высокого параллельного доступа к распределенной базе данных мы будем хранить данные исходной централизованной базы данных на нескольких других узлах сети.
Чтобы решить проблему с одним узлом, Redis также развертывает несколько копий репликации данных на другие узлы для репликации, обеспечивая высокую доступность Redis и избыточное резервное копирование данных, обеспечивая тем самым высокую доступность данных и услуг.
Ведущая ведомая репликация
Что такое репликация “ведущий-ведомый”
Репликация Master-slave относится к репликации данных с одного сервера Redis на другие серверы Redis. Первый называется хозяином, а второй-рабом. Репликация данных является односторонней и может осуществляться только от ведущего устройства к ведомому.
По умолчанию каждый сервер Redis является главным узлом; и главный узел может иметь несколько подчиненных узлов (или не иметь подчиненных узлов), но подчиненный узел может иметь только один главный узел.
Роль репликации “ведущий-ведомый”
- Избыточность данных: Репликация Master-slave реализует горячее резервное копирование данных, что является способом избыточности данных помимо сохранения.
- Восстановление после сбоя: Когда у основного узла возникают проблемы, подчиненный узел может предоставлять услуги для быстрого восстановления после сбоя; фактически, это своего рода резервирование услуг.
- Балансировка нагрузки: На основе репликации ведущий-ведомый, с разделением чтения и записи, главный узел может предоставлять услуги записи, а ведомый узел может предоставлять услуги чтения (т. Е. Подключение ведущего узла при записи данных Redis и подключение ведомого узла при чтении данных Redis) для совместного использования нагрузки сервера; особенно в случае записи меньше и чтения больше, совместное использование нагрузки чтения через несколько подчиненных узлов может значительно улучшить обслуживание Redis. Одновременное количество серверов.
- Разделение чтения и записи: может использоваться для разделения чтения и записи, записи в главную библиотеку, чтения в подчиненную библиотеку, разделения чтения и записи может не только повысить пропускную способность сервера, но и изменить количество подчиненных библиотек в соответствии с изменениями спроса;
- Краеугольный камень высокой доступности: В дополнение к вышеуказанным функциям репликация “ведущий-ведомый” также является основой реализации Sentinel и кластера, поэтому репликация “ведущий-ведомый” является основой высокой доступности Redis.
Включена репликация ведущий-ведомый
Существует три способа открыть репликацию master-slave с подчиненных узлов:
- Файл конфигурации: Добавить: ведомый < главный IP > < главный порт > из файла конфигурации сервера
- Команда запуска: после команды запуска redis-сервера добавьте ведомое устройство < главный IP > < главный порт >
- Команда клиента: После запуска сервера Redis команда выполняется непосредственно через клиент: подчиненный < главный IP > <главный порт>, экземпляр Redis становится подчиненным узлом.
Часть реплицированной информации можно просмотреть с помощью команды репликации информации
Принцип репликации ведущий-ведомый
Процесс репликации ведущий-ведомый можно разделить на три этапа: этап установления соединения (т. е. этап подготовки), этап синхронизации данных и этап распространения команд.
После выполнения команды slaveof с узла процесс репликации начинает работать, как показано на следующем рисунке. Из рисунка видно, что процесс репликации можно примерно разделить на шесть процессов.
Этот процесс также можно увидеть в журнале после настройки ведущего устройства.
1) Храните основную информацию. После выполнения slaveof Redis печатает следующий журнал:
2) Подчиненный поддерживает и воспроизводит соответствующую логику с помощью задачи синхронизации, выполняемой каждую секунду. Когда задача синхронизации находит новый главный узел, она пытается установить сетевое соединение с подчиненным узлом. Установление сетевого соединения между подчиненным узлом и ведущим узлом
Подчиненный узел устанавливает сокет, а подчиненный узел устанавливает сокет с портом 5134, который используется для приема команд репликации, отправляемых ведущим узлом. Распечатайте следующий журнал после успешного подключения с узла:
Если подчиненный узел не может установить соединение, задача синхронизации будет повторяться бесконечно, пока соединение не завершится успешно или подчиненный узел не отменит репликацию.
Что касается сбоя соединения, вы можете просмотреть индикатор master_link_down_since_seconds с подчиненного узла, выполнив репликацию информации, которая записывает системное время сбоя соединения с основным узлом. Когда подчиненному узлу не удается подключиться к главному узлу, каждую секунду будет печататься следующий журнал, чтобы облегчить обнаружение проблем:
# Error condition on socket for SYNC: {socket_error_reason}
3) Отправьте команду Ping. После успешного установления соединения с узла отправляется запрос ping для первого обмена данными. Основные цели запроса Ping заключаются в следующем: · Проверьте, доступен ли сетевой сокет между ведущим и ведомым. · Проверьте, принимает ли главный узел в настоящее время команды обработки. Если отправлена команда ping, подчиненный узел не получает ответ Pong или тайм-аут от главного узла, например, тайм-аут сети, или главный узел блокируется и не может ответить на команду, подчиненный узел отключит соединение репликации, и следующая задача синхронизации инициирует повторное подключение.
Команда ping, отправленная с узла, успешно возвращается, повторно печатается следующий журнал и продолжается последующий процесс репликации:
4) Проверка подлинности привилегий. Если главный узел задает параметр require pass, требуется проверка пароля. Подчиненный узел должен настроить главный параметр аутентификации, чтобы обеспечить тот же пароль, что и главный узел, для прохождения проверки. Если проверка завершится неудачно, процесс репликации будет завершен, и подчиненный узел перезапустит процесс репликации.
5) Синхронизированные наборы данных. После того, как соединение репликации “ведущий-ведомый” нормально взаимодействует, для первого сценария репликации главный узел отправит все данные, которые он хранит, на подчиненный узел, что является самым длительным этапом, требующим много времени.
6) Непрерывная репликация команд. Когда главный узел синхронизирует текущие данные с подчиненным узлом, процесс создания репликации завершается. Затем главный узел продолжит отправлять команды записи на подчиненный узел, чтобы обеспечить согласованность данных между ведущим и подчиненным узлами.