Оригинальная ссылка(с изменениями)
Если вы можете держаться за то, чего не могут удержать другие, вы можете получить то, чего у других нет.
обрати внимание напроспект программированияОфициальный аккаунт, давайте придерживаться того, что мы думаем, и расти вместе! !
«Нападение на интервью» — Глава Redis — Принцип Redis Sentinel и механизм сохраняемости
В этой серии я поделюсь с вами некоторыми вопросами для интервью, чтобы помочь студентам, которые хотят сменить работу на золото, серебро и серебро, закрепить и удивить некоторые вопросы, часто задаваемые интервьюерами. !
«[Интервью с нападением] — глава Redis» — тип данных Redis? К каким сценариям он применим?
Первые два интервью были временно приостановлены из-за нехватки времени. Интервьюер чувствовал, что вы хорошо разбираетесь в репликации redis master-slave и дозорном механизме. Поэтому сегодня интервьюер хотел узнать, насколько хорошо вы знаете Redis. наступление, вы готовы?
Последнее интервью закончилось в спешке из-за проблем со временем, сегодня у меня есть еще несколько дозорных вопросов. Прежде всего, как работает Redis Sentinel? Сосредоточьтесь на описании процесса отработки отказа
OK.
1) Каждый Sentinel отправляет команду PING главному, подчиненному и другим экземплярам Sentinel, о которых он знает, один раз в секунду.
2) Если экземпляр (экземпляр) превышает значение, указанное параметром down-after-milliseconds из последнего действительного ответа на команду PING, экземпляр будет помечен текущим Sentinel как субъективно отключенный.
3) Если Мастер помечен как субъективно отключенный, все Стражи, наблюдающие за Мастером, должны подтверждать, что Мастер действительно перешел в субъективное автономное состояние с частотой один раз в секунду.
4) Когда достаточное количество Стражей (большее или равное значению, указанному в файле конфигурации) подтвердит, что Мастер действительно перешел в субъективное автономное состояние в течение указанного диапазона времени, Мастер будет помечен как объективный в автономном режиме.
5) Когда Мастер помечен Sentinel как объективно отключенный, частота отправки команд INFO всем ведомым устройствам отключенного Мастера от Sentinel будет изменена с одного раза каждые 10 секунд на один раз в секунду (при нормальных обстоятельствах каждый Sentinel будет отправлять INFO). команды каждые 10 секунд. Частота один раз в секунду отправляет команды INFO всем известным ему Ведущим и Ведомым).
6) Если Стражей недостаточно, чтобы согласиться с тем, что Мастер был в автономном режиме, объективный статус Мастера в автономном режиме станет субъективным в автономном режиме. Если Мастер возвращает действительный ответ на команду PING Sentinel, субъективный статус Мастера в автономном режиме будет удален.
7) Сторожевые узлы будут «общаться» с другими дозорными узлами, голосовать за дозорный узел для обработки ошибок, выбирать главный узел из подчиненных узлов и монтировать другие подчиненные узлы к новому главному узлу для автоматического копирования данных нового главного узла. узел.
Во время аварийного переключения из оставшихся подчиненных будет выбран новый ведущий.Каковы критерии избрания ведущим?
Если ведущий считается отключенным, и большинство дозорных разрешают переключение ведущий-подчиненный, то дозорный выполнит операцию переключения ведущий-подчиненный.В это время ведомый должен быть выбран первым, и будет учитываться некоторая информация о ведомом.
(1) Продолжительность времени отключения от ведущего устройства.
Если ведомое устройство было отключено от ведущего более 10 раз после завершения миллисекунды плюс продолжительность времени, в течение которого ведущее устройство было отключено, ведомое устройство считается непригодным для избрания в качестве ведущего.( down-after-milliseconds * 10) + milliseconds_since_master_is_in_SDOWN_state
(2) Приоритет подчиненного устройства.
Сортировать по приоритету ведомого, чем ниже приоритет ведомого, тем выше приоритет
(3) Скопируйте смещение.
Если приоритет слейва одинаковый, то смотрим по смещению реплики, какой слейв реплицирует больше данных, чем позже смещение, тем выше приоритет
(4) идентификатор запуска
Если два вышеуказанных условия совпадают, выберите ведомое устройство с меньшим идентификатором запуска.
Что будет делать дозорный, выполнивший переключение, после завершения аварийного переключения?
Информация о конфигурации конфигурации будет распространена.
После того, как часовой завершит переключение, он локально обновит и сгенерирует последнюю основную конфигурацию, а затем синхронизирует ее с другими часовыми механизмами сообщений публикации/подписки.
При синхронизации конфигурации какие другие дозорные обновляют свою конфигурацию в соответствии с чем?
Sentinel, выполняющий переключение, получит от нового мастера (salve->master) эпоху конфигурации, которая является номером версии, и номер версии для каждого переключателя должен быть уникальным.
Если первый выбранный дозорный не удается переключиться, другие дозорные будут ждать времени ожидания аварийного переключения, а затем продолжат выполнять переключение.В это время новая эпоха конфигурации будет повторно получена как новый номер версии.
Этот номер версии очень важен, потому что различные сообщения публикуются и отслеживаются через канал, поэтому после того, как дозорный завершает новое переключение, за новой главной конфигурацией следует новый номер версии, а другие дозорные обновляют основную конфигурацию в соответствии с размер номера версии.
Хорошо, давайте остановимся здесь на последней проблеме часового, давайте поговорим о постоянстве Redis. Прежде всего, должен ли Redis быть постоянным в продакшене? Если да, то зачем вам это нужно, или каково значение постоянства для производственных систем?
хочу.
Постоянство Redis в основном предназначено для аварийного восстановления и восстановления данных, а также может быть отнесено к категории высокой доступности.
Например, Redis полностью отключен, что делает Redis недоступным.Первое, что нужно сделать в это время, — сделать Redis доступным как можно скорее. Затем он перезапустит Redis и позволит ему как можно скорее предоставлять услуги внешнему миру. Но если нет резервной копии данных без персистентности, в это время запускается Redis, и он тоже недоступен, и данные пропали!
В это время очень вероятно, что придет большое количество запросов, и все кэши не попадут.В это время он будет мертв, что может привести к лавинным проблемам с кэшем.Все запросы, если они не пораженные Redis, отправятся в базу данных, чтобы найти их, и база данных внезапно выполнит высокий параллелизм, а затем зависнет. Если база данных зависнет, вы не сможете найти данные и восстановить их в Redis.
Каковы механизмы сохранения Redis?
Redis имеет два механизма сохранения: AOF и RDB.
AOF, запишите команду каждого запроса на запись, добавьте ее в конец файла путем добавления и добавьте непосредственно в конец, что более эффективно.
Для операционной системы вместо того, чтобы каждый раз записывать непосредственно на диск, операционная система имеет свой собственный уровень кеша, данные, записанные на диск с помощью Redis, сначала будут кэшироваться в кеше ОС, а Redis вызывает операцию fsync для операционная система каждую 1 секунду Принудительно данные в кеше ОС должны быть сброшены в файл AOF.
При перезапуске redis достаточно повторно выполнить команды, записанные в AOF, но если файл большой, выполнение займет больше времени, и на восстановление данных уйдет чуть больше времени.
RDB, – это файл моментального снимка. Полный файл моментального снимка RDB создается из данных в памяти Redis через равные промежутки времени. При перезапуске Redis данные можно загрузить напрямую. Те же данные можно восстановить быстрее, чем AOF.
Давайте поговорим о характеристиках, преимуществах и недостатках этих двух механизмов персистентности.
OK.
RDB的优点
Первый момент заключается в том, что он будет генерировать несколько файлов данных, каждый из которых представляет данные в redis в определенное время, что очень подходит для холодного резервного копирования.
Второй момент заключается в том, что механизм сохраняемости RDB очень мало влияет на службы чтения и записи, предоставляемые Redis, что может поддерживать высокую производительность Redis, поскольку основному процессу Redis нужно только разветвить дочерний процесс и позволить дочернему процессу выполнять операции с диском. Операции ввода-вывода для сохраняемости RDB Вот и все.
Третий момент заключается в том, что по сравнению с механизмом сохраняемости AOF быстрее перезапустить и восстановить процесс redis непосредственно на основе файла данных RDB.
AOF, сохраненный журнал инструкций, при восстановлении данных фактически воспроизводит и выполняет все журналы инструкций для восстановления всех данных в памяти.
RDB — это файл данных, при восстановлении он может быть напрямую загружен в память.
RBD的缺点
1) В случае сбоя может быть больше потерь данных, чем AOF. Вообще говоря, файлы моментальных снимков данных RDB генерируются каждые 5 минут или чаще. В это время, как только процесс Redis выйдет из строя, данные за последние 5 минут будут потеряны.
Эта проблема также является самым большим недостатком rdb.Он не подходит для плана восстановления с первоочередным приоритетом.Если вы полагаетесь на RDB в качестве плана восстановления с первоочередным приоритетом, это приведет к большей потере данных.
2) Каждый раз, когда RDB разветвляет подпроцесс для создания файла данных моментального снимка RDB, если файл данных особенно велик, служба, предоставляемая клиенту, может быть приостановлена на несколько миллисекунд или даже несколько секунд.
Поэтому, как правило, не делайте интервал RDB слишком длинным, иначе файл RDB, создаваемый каждый раз, будет слишком большим, что может повлиять на производительность самого Redis.
AOF的优点
1) AOF может лучше защитить данные от потери
Как правило, AOF выполняет операцию fsync через фоновый поток каждую секунду и теряет до 1 секунды данных.
Каждую 1 секунду выполняется операция fsync, чтобы гарантировать, что данные из кеша ОС будут записаны на диск.
Процесс Redis зависает и теряет до 1 секунды данных.
2) AOF обладает высокой устойчивостью
Файлы журнала AOF записываются в режиме только добавления, поэтому нет дополнительных затрат на адресацию диска, производительность записи очень высока, и файл нелегко повредить, даже если конец файла поврежден, его легко восстановить. .
3) Даже если файл журнала AOF слишком велик, выполняется фоновая операция перезаписи, которая не повлияет на чтение и запись клиента.
Потому что при перезаписи лога инструкции в нем будут сжаты для создания минимального лога, необходимого для восстановления данных. При создании нового файла журнала старый файл журнала по-прежнему записывается как обычно. Когда новый объединенный файл журнала будет готов, можно будет обменяться новыми и старыми файлами журнала.
4) Команды лог-файла AOF записываются очень читабельно, что очень удобно для аварийного восстановления после катастрофического случайного удаления.
Например, если кто-то случайно использует команду flushall для очистки всех данных, если в это время не произошло фоновой перезаписи, файл AOF может быть скопирован немедленно, последняя команда flushall может быть удалена, а затем файл AOF может быть скопирован. быть возвращены.Через механизм восстановления, все данные автоматически восстанавливаются.
AOF的缺点
(1) Для одних и тех же данных файлы журнала AOF обычно больше, чем файлы моментальных снимков данных RDB.
(2) После включения AOF поддерживаемое количество запросов в секунду при записи будет ниже, чем количество запросов в секунду при записи, поддерживаемое RDB, поскольку AOF обычно настроен на синхронизацию файлов журнала один раз в секунду. второй.
Если вы хотите, чтобы часть данных не была потеряна, это также возможно, fsync AOF настроен на то, чтобы не записывать часть данных, и fsync выполняется один раз, но это приведет к значительному падению QPS. Редиса.
(3) Раньше в AOF была ошибка, то есть при восстановлении данных через лог, записанный AOF, точно такие же данные не восстанавливались.
Таким образом, более сложный метод, основанный на журнале команд/объединении/воспроизведении, такой как AOF, более хрупок и подвержен ошибкам, чем метод, основанный на RDB, который каждый раз сохраняет полный файл моментального снимка данных. Тем не менее, AOF предназначен для предотвращения ошибок, вызванных процессом перезаписи, поэтому каждая перезапись основана не на старом журнале инструкций для слияния, а на данных в памяти в то время для перестроения инструкции, поэтому надежность будет намного лучше. .
(4) Единственным существенным недостатком является то, что восстановление данных происходит относительно медленно и не подходит для холодного резервного копирования.
Вы только что упомянули холодный резерв, так почему же вы конкретно говорите, почему AOF не подходит для RDB?
На самом деле можно сделать и то, и другое, но больше подходит RDB.
RDB может выполнять холодное резервное копирование, поскольку генерирует несколько файлов, каждый из которых представляет собой полный снимок данных в определенный момент.Мы можем отправить этот полный файл данных в какое-либо удаленное безопасное хранилище, например в распределенное хранилище ODPS от Alibaba Cloud, данные в Redis регулярное резервное копирование с заранее определенной стратегией резервного копирования.
AOF также может делать холодное резервное копирование, но у него только один файл, но мы можем сами писать программы и копировать копию этого файла через равные промежутки времени.
Преимущество RDB в качестве холодного резервного копирования заключается в том, что redis удобнее контролировать создание файлов моментальных снимков в течение фиксированного времени.Однако AOF также требует от нас написания некоторых сценариев для этого.Разные тайминги вызывают больше проблем.
Данные RDB используются для холодного резервного копирования.В худшем случае, когда предусмотрено восстановление данных, скорость выше, чем AOF.
Столько всего было сказано об AOF и RDB, но как производственная система должна выбирать эти два механизма сохранения?
Что касается выбора между RDB и AOF, я думаю, что оба,
1) Не используйте только RDB, так как это приведет к потере большого количества данных.
2) Также не используйте AOF, потому что тогда есть две проблемы:
Во-первых, вы используете AOF в качестве холодного резервного копирования, без RDB в качестве холодного резервного копирования скорость восстановления выше;
Во-вторых, RDB просто и грубо создает моментальные снимки данных каждый раз, что является более надежным и позволяет избежать ошибок в сложном механизме резервного копирования и восстановления AOF.
3) Комплексное использование механизмов сохранения AOF и RDB, AOF используется для обеспечения того, чтобы данные не были потеряны, как первый выбор для восстановления данных; RDB используется для различных степеней холодного резервного копирования, когда файлы AOF потеряны или повреждены и недоступны, вы также можете использовать RDB для быстрого восстановления данных в качестве последней линии защиты для восстановления данных.
Ладно, на сегодня все, продолжим в следующий раз.
это наконец закончилось.
На самом деле, если в вашем резюме говорится, что вы освоили Redis, то, если интервьюер также владеет Redis, он схватит ваш Redis и будет продолжать спрашивать, как много вы знаете о Redis, да. Это не значит, что вы действительно накопили эти знания. сами. Знаете ли вы немного больше, чем другие? Копнув все глубже и глубже, посмотрите, сколько уровней вы сможете пройти. По сравнению с другими конкурентами, вы можете быть ошеломлены за несколько раундов, но если вы сможете бороться еще несколько раундов, интервьюер будет больше впечатлен вами, и ваши шансы возрастут.
Если Redis задает вам несколько основных вопросов, интервьюер либо мало что знает о Redis, либо его интересуют другие моменты в вашем резюме.
Небольшое предложение:Еще один момент, о котором следует сказать, заключается в том, что интервью — это не просто список технических терминов, но может относиться к техническим аспектам определенной технологии, например:熟悉redis线程模型、持久化机制(Конечно, вы должны действительно понять, прежде чем писать это). чем ты просто пишешь熟悉redisБудьте решительны, чтобы интервьюер знал, о чем вас спросить, и имел направление. В противном случае это просто список технических терминов, он слишком широк, и интервьюер не знает, что у вас спросить, если вы спросите небрежно, вам не будет стыдно. Если вы напишите определенный пункт знаний, с которым вы знакомы, вы не будете таким пассивным. Конечно, неизбежно будут интервьюеры, которые конкретно спросят вас, что вы не написали в своем резюме. . .
Этот цикл статей-интервью-штурм, а не туториал.Если копнуть внимательно, то можно много говорить.В интервью нужно только сказать этот принцип.Лучше бы вы говорили и рисовали картинки. Эта серия статей посвящена быстрому нападению, быстрому подбору и обзору.
Выглядит хорошо, пожалуйста, нажмитеХвала ~
Обратите внимание на публичный аккаунтпроспект программирования, в первый раз, чтобы получить толчок статьи.
выглядит хорошо, пожалуйстаНравится, подписывайтесь, делайте репостО~