интервьюер: Почему бы тебе не рассказать мне, что ты смотрел в последнее время? Можете вытащить и вместе обсудить (не знаю, что спросить сегодня)
Кандидат: Недавно я смотрел контент, связанный с Redis.
интервьюер: Ну, я помню, спрашивал про базы Redis и постоянство
интервьюер:Почему бы вам не рассказать об архитектуре Redis вашей компании?
Кандидат: Архитектура Redis моей бывшей компании представляет собой «сегментированный кластер», который использует слой «Прокси» для разгрузки ключей на разные серверы Redis.
Кандидат: Поддержка динамического расширения, восстановления после сбоев и т. д.
интервьюерТогда вы можете поговорить о архитектуре и основных принципах реализации прокси-слоя?
Кандидат: Извините, это ответственность команды промежуточного программного обеспечения, я невнимательно прочитал.
Кандидат:…
интервьюер: ...
Кандидат: Тем не менее, я могу рассказать вам о существующей общей архитектуре Redis с открытым исходным кодом (:
интервьюер: На этом все, ну давайте приступим
Кандидат: Итак, позвольте мне начать с основ, хорошо?
Кандидат: Как упоминалось ранее, в Redis есть механизм сохраняемости.Даже если Redis перезапускается, данные можно перезагрузить, полагаясь на файлы RDB или AOF.
КандидатОднако в настоящее время только один сервер Redis хранит все данные.В настоящее время, если сервер Redis «временно» не может это исправить, он будет полагаться на службу Redis.
Кандидат: Следовательно, для «высокой доступности» Redis Redis в основном будет «резервным копированием» сейчас: запустить еще один сервер Redis, чтобы сформировать «архитектуру Master-Plave»
Кандидат: данные «подчиненного сервера» копируются «главным сервером», а данные главного и подчиненного серверов согласованы.
Кандидат: Если основной сервер завис, то можно "вручную" обновить "с сервера" до "мастера", чтобы сократить время недоступности
интервьюер:Как «главный сервер» «копирует» свои данные на «подчиненный сервер»?
Кандидат: «Репликация» также называется «синхронизацией». В Redis для синхронизации используется команда «PSYNC». Эта команда имеет две модели: полная ресинхронизация и частичная ресинхронизация.
Кандидат: Это может быть просто понято так: если это первая «синхронизация», подчиненный сервер не реплицировал какой-либо главный сервер или главный сервер, который будет реплицирован подчиненным сервером, отличается от последнего реплицированного главного сервера, то « будет использоваться режим «Синхронизация» для репликации
Кандидат: Если это происходит только из-за прерывания сети, только "кратковременного" отключения, то для репликации будет использоваться режим "частичной ресинхронизации"
Кандидат: (Если разрыв данных между главным и подчиненным серверами слишком велик, для репликации все равно будет использоваться режим «полной ресинхронизации»)
интервьюер:Не могли бы вы немного рассказать о принципе и процессе «синхронизации»?
Кандидат: А, нет проблем
Кандидат: Если главный сервер хочет скопировать данные на подчиненный сервер, первым шагом будет установление "соединения" через сокет.Этот процесс будет выполнять некоторую проверку информации, проверку личности и т. д.
Кандидат: Затем подчиненный сервер отправит команду "PSYNC" на главный сервер для запроса синхронизации (в это время он принесет параметры смещения "идентификатор сервера" RUNID и "прогресс репликации", если подчиненный сервер новый, то там нет)
Кандидат: Главный сервер обнаруживает, что это новый подчиненный сервер (поскольку параметры не подняты), он будет использовать режим «полной повторной синхронизации» и отправлять «идентификатор сервера» (runId) и «прогресс репликации» (смещение) на подчиненный сервер. , подчиненный сервер запишет эту информацию.
интервьюер:В порядке…
Кандидат: Затем главный сервер в фоновом режиме сгенерирует файл RDB и отправит его на подчиненный сервер через ранее установленное соединение.
Кандидат: После получения RDB-файла с сервера сначала очистите его собственные данные, а затем загрузите и восстановите RDB-файл.
Кандидат: Этот процесс, главный сервер не простаивает (продолжать получение запроса клиента)
интервьюер:В порядке…
Кандидат: главный сервер будет использовать «буфер» для записи «измененных команд» после создания файла RDB.После того, как подчиненный сервер загрузит RDB, главный сервер отправит все команды, записанные в «буфере», на подчиненный сервер.
Кандидат: Таким образом, главный и подчиненный серверы достигают согласованности данных (процесс репликации является асинхронным, поэтому данные «в конечном итоге непротиворечивы»).
интервьюер:В порядке…
интервьюер:Как насчет процесса «частичной повторной синхронизации»?
Кандидат: Ну, это вообще-то полагается на "смещение" для частичной ресинхронизации. Каждый раз, когда главный сервер распространяет команду, он передает «смещение» подчиненному серверу.
Кандидат: И главный сервер, и подчиненный сервер сохранят «смещение» (если есть разница между смещениями с обеих сторон, это означает, что данные главного и подчиненного серверов не полностью синхронизированы)
Кандидат: После того, как подчиненный сервер будет отключен, он отправит команду «PSYNC» на главный сервер, который также будет содержать RUNID и смещение (после повторного подключения эта информация все еще существует)
интервьюер:В порядке…
Кандидат: После того, как мастер-сервер получит команду, проверьте, совпадает ли RUNID, если совпадает, значит, он мог быть скопирован ранее.
Кандидат: Затем проверьте, существует ли «смещение» в смещении, записанном главным сервером.
Кандидат: (Объясните здесь, потому что основной сервер записывает смещение с помощью кольцевого буфера, если буфер заполнен, он будет перезаписать предыдущую запись)
Кандидат: Если найдено, начать с недостающей части предложения и отправить соответствующую команду модификации на подчиненный сервер
Кандидат: Если подчиненный кольцевой буфер не найден, вы можете использовать режим «полной повторной синхронизации» только для повторного выполнения репликации ведущий-ведомый.
интервьюер:Я знаю это из мастер-копии, а потом вы сказали, что если основная библиотека Redis зависнет, вам все равно придется «вручную» обновить базу данных основной библиотеки, ах
интервьюер:Знаете ли вы какой-нибудь способ сделать "автоматический" отказоустойчивый?
Кандидат: Это обязательно Далее идет "Страж".
интервьюер: Давайте начнем ваше шоу.
Кандидат: Основными задачами "Sentinel" являются: мониторинг (наблюдение за состоянием главного сервера), выбор главного (главный сервер зависает, и выбор подчиненного сервера в качестве главного), оповещение (отправка сообщения о неисправности на администратор) и конфигурации (как центр конфигурации, предоставляющий информацию о текущем главном сервере)
Кандидат: "Sentry" можно рассматривать как сервер Redis, работающий в "специальном" режиме. Для "высокой доступности" Sentry также представляет собой кластерную архитектуру.
Кандидат: Сначала необходимо создать соответствующее соединение с мастер-подчиненным сервером Redis (получить их информацию).
Кандидат: каждый дозорный постоянно использует команду ping, чтобы узнать, находится ли главный сервер в автономном режиме.Если главный сервер не отвечает нормально в течение «настроенного времени», текущий дозорный «субъективно» будет думать, что главный сервер находится в автономном режиме.
Кандидат: Другие "дозорные" также будут пинговать главный сервер. Если "достаточно" (в зависимости от конфигурации) дозорных считают, что главный сервер был в офлайне, он будет считаться "объективно оффлайн", и тогда главный сервер должен быть выполнен. Отказоустойчивая операция.
интервьюер:В порядке…
Кандидат: «Лидер» будет выбран среди «часовых», и существует много правил выбора лидера.Вообще говоря, это в порядке очереди (что быстрее, то и выбирать).
Кандидат: Аварийное переключение главного сервера в автономном режиме «ведущим часовым».
интервьюер:В порядке…
Кандидат: Сначала выберите один из «подчиненных серверов» в качестве главного сервера.
Кандидат:( Это также выбирается, например: из приоритета конфигурации библиотеки, чтобы определить, какой из OFFSET репликации сервера является самым большим, размер RunID, время, долгое время, отключено MASTER ...)
Кандидат: Затем предыдущие подчиненные серверы должны выполнить «репликацию ведущий-подчиненный» с новым главным сервером.
Кандидат: Главный сервер, который был в автономном режиме, при повторном подключении необходимо сделать его подчиненным сервером нового главного сервера.
интервьюер:Хм... Я хочу спросить, приведет ли Redis к потере данных при репликации master-slave и аварийном переключении?
Кандидат: Очевидно да, из приведенного выше процесса "мастер-слейв репликация" этот процесс асинхронный (в процессе репликации: главный сервер всегда будет получать запрос, а затем отправлять команду модификации на подчиненный сервер)
Кандидат: Если команда главного сервера не была отправлена подчиненному серверу, он зависнет. В это время я хочу, чтобы подчиненный сервер был выше главного сервера, но данные подчиненного сервера неполные (:
Кандидат: Возможна другая ситуация: возможно, часовой сервер думает, что главный сервер не работает, но на самом деле главный сервер не выключен (джиттер сети), и часовой выбрал подчиненный сервер в качестве главного сервера. клиент" еще не ответил и продолжает записывать данные на старый главный сервер
Кандидат: Когда старый главный сервер повторно подключается, он включается в состав подчиненного сервера нового главного сервера... Следовательно, в течение этого времени данные, записанные клиентом на старый главный сервер, будут потеряны.
Кандидат: Вышеупомянутые два случая (мастер с задержкой копирования и мозг) могут быть "насколько это возможно", чтобы избежать потери данных при настройке
Кандидат: (При достижении определенного порога главному серверу напрямую запрещается получать запросы на запись в попытке снизить риск потери данных)
интервьюер:Вы хотите перестать говорить о сегментированных кластерах Redis?
Кандидат:Ну... Split Cluster белый, просто для хранения части данных, добавляются все данные сервера REDIS, а полные данные (распределяются)
Кандидат: Чтобы сформировать сегментированный кластер, вам необходимо «маршрутизировать» (шардировать) разные ключи.
Кандидат: Теперь есть две общие схемы маршрутизации: "Клиентская маршрутизация" (SDK) и "Серверная маршрутизация" (Прокси)
Кандидат: Представитель клиентской маршрутизации (Redis Cluster), представитель серверной маршрутизации (Codis)
интервьюер:Хотите подробно объяснить разницу между ними?
Кандидат: Я сегодня немного сонный, как насчет следующего раза?
Резюме этой статьи:
-
Redis обеспечивает высокую доступность:
- Механизм сохранения AOF/RDB
- Архитектура «ведущий-ведомый» (главный сервер зависает, вручную завершается подчиненным сервером)
- Внедрить дозорный механизм для автоматического отказа от побега
-
Принцип репликации master-slave:
- Два режима команды PSYNC: полная ресинхронизация, частичная ресинхронизация
- Полная ресинхронизация: ведущие и ведомые серверы устанавливают соединение, главный сервер генерирует файл RDB и отправляет его на ведомый сервер, главный сервер не блокирует (соответствующие команды модификации записываются в буфере), а команда модификации отправляется на ведомый сервер.
- Частичная повторная синхронизация: подчиненный сервер отключается и снова подключается, а также отправляет RunId и смещение на главный сервер.Главный сервер оценивает смещение и runId и отправляет связанные со смещением команды, которые не были синхронизированы, на подчиненный сервер.
-
Сторожевой механизм:
- Sentinels можно понимать как специальные серверы Redis, которые обычно формируют кластеры Sentinel.
- Основная работа часового заключается в мониторинге, оповещении, настройке и выборе мастера.
- Когда главный сервер выйдет из строя, подчиненный сервер будет «выбран», чтобы возглавить «объективно отключенный» сервер, а «ведущий часовой» переключится.
-
данные потеряны:
- Потеря данных может произойти как на этапах репликации master-slave, так и на этапах аварийного переключения Redis (путем максимально возможной настройки, чтобы избежать этого).
Добро пожаловать в мой публичный аккаунт WeChat【Java3y] Давайте поговорим о Java-интервью, серия онлайн-интервьюеров постоянно обновляется!
Серия [Онлайн-интервьюер-Мобильный терминал]Продолжаем обновлять два раза в неделю!
【Онлайн-интервьюер-компьютер】СерияПродолжаем обновлять два раза в неделю!
Оригинал это не просто! ! Проси три! !