Введение

Мало знаний, большой вызов! Эта статья участвует в "Необходимые знания для программистов«Творческая деятельность.

Эта статья участвовала в "Проект «Звезда раскопок»”, чтобы выиграть творческий подарочный пакет и бросить вызов творческим поощрительным деньгам.

всем привет. Месяц не писал в блог, не знаю что написать хахаха. Золотая девятка, серебряная десятка, конец года, различные компании открыли большое количество ХК, готовы ли вы сменить работу?

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

如果大家对面试相关的问题与技巧感兴趣的话，可以在本文或者公众号【柏炎大叔】给我留言，我可以出几篇文章专门为大家介绍一下。

Эта статья познакомит васраспределенная теориясоответствующие знания. Не сказать, что после прочтения этой статьи вы овладеете теорией распределенных вычислений, но, по крайней мере, сможете встретиться с интервьюером лицом к лицу.

Садись и заводи машину~

2.КАП

В распределенной теории протокол, с которым я чаще всего сталкивался, — это CAP. Возможность провести 10 интервью, минимум 3-4 интервьюера зададут такой вопрос: Вы понимаете теорию CAP?

2.1 Концепция

Принцип CAP, также известный как теорема CAP, относится к непротиворечивости, доступности и толерантности к разделам в распределенной системе.这三个基本需求，最多只能同时满足其中的2个。

опции	описывать
Последовательность	Относится к функции, при которой данные могут оставаться согласованными в нескольких копиях (строгая согласованность).
Доступность	Это означает, что услуга, предоставляемая системой, должна быть всегда доступна, и на каждый запрос может быть получен безошибочный ответ (не гарантируется, что полученные данные будут самыми последними данными).
Допуск перегородки	Когда распределенная система сталкивается с каким-либо сбоем сетевого раздела, она по-прежнему может предоставлять внешние службы, отвечающие требованиям согласованности и доступности, если не произойдет сбой всей сетевой среды.

2.2.Почему CAP не может быть удовлетворен одновременно

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

Предположим, теперь у нас есть веб-сайт электронной коммерции, который распространяется и развертывается в разных местах. Два сервера развернуты в Шанхае и Пекине, оба являются независимыми узлами данных. Запросы пользователей на доменные имена поступают в CDN для ускоренного разрешения и маршрутизируются в соответствии с регионами. Южный маршрут идет в Шанхай, а северный – в Пекин. И данные двух мест асинхронно синхронизируются в фоновом режиме.

Так в чем же проблема?

В распределенной теории обычно выполняется P, тогда только CP или AP могут быть удовлетворены, когда P является предпосылкой. Что Вы думаете об этом?

Пример:

Предположим, что в компьютерном зале, где находится шанхайский сервер, произошла необратимая геологическая катастрофа или отключение электроэнергии [например, ситуация с отключением станции Сяопо не так давно, ха-ха].

AP

В случае высокого параллелизма некоторые бизнес-данные шанхайского узла не были синхронизированы с базой данных в Пекине.В настоящее время для обеспечения характеристик высокой доступности A запрос перенаправляется в Пекин за счет согласованность данных С.

CP

Но для сильного финансового бизнеса, такого как банковский перевод, очень важна согласованность данных: сколько денег я перевожу, сколько денег должны получить другие. На этом этапе для обеспечения согласованности данных необходимо пожертвовать доступностью. Поскольку ваш узел передачи данных находится в Шанхае, если вы направите данные передачи на фоновый узел в это время, данные будут несогласованными.

2.3 Как выбрать CP и AP?

CAP не может быть удовлетворен одновременно, а P должно быть гарантировано, поэтому следует ли нам выбирать CP или AP?

Для большинства крупномасштабных сценариев интернет-приложений существует множество хостов и разбросанных развертываний. И теперь масштаб кластера становится все больше и больше, поэтому сбои узлов и сбои сети — это норма. Например, данные о просмотре веб-сайтов электронной коммерции, если некоторые узлы не работают, это определенно не говорит о том, что вам не разрешено просматривать продукты. Вы, очевидно, почувствуете, что загрузка данных замедлилась [Говорят, что вчера Taobao был отстранен от предварительной продажи Double Eleven, как поживают друзья Taobao? 3.25 Внимание! ], но окончательные данные еще можно загрузить.

Конечно, если задействована денежная система, С должно быть гарантировано. Поэтому при нормальных обстоятельствах финансовая система выберет выпуск посреди ночи, и будет добавлено сообщение о том, что система обновляется во время выпуска, что может привести к тому, что некоторые функции будут недоступны. Это необходимо для обеспечения согласованности данных за счет доступности системы.

Таким образом, нет абсолютного вывода о том, лучше ли CP или AP, необходимо решить, какую теорию использовать в соответствии с реальной сценой.

2.4 Какая теория используется различным промежуточным ПО

Mysql с одним узлом использует CA

База данных с одним узлом обычно использует принцип CA, отказывается от отказоустойчивости разделов и обеспечивает характеристики ACID. Согласованность данных гарантируется, пока база данных доступна.

смотритель зоопарка выбирает CP

zookeeper гарантирует CP, то есть запросы на доступ к zookeeper в любое время могут получить непротиворечивые результаты данных, а система отказоустойчива к сегментации сети, но не может гарантировать доступность каждого сервиса. Из реальной ситуации, при использовании zookeeper для получения списка сервисов, если zk выбирает или более половины машин в zk кластере недоступны, данные не будут получены. Поэтому zk не может гарантировать доступность услуги.

эврика выбрать AP

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

nacos поддерживает CP, а также AP

В отличие от zookeeper и eureka, nacos поддерживает как CP, так и AP.

nacos будет выбирать разные архитектуры на основе разных типов инстансов.

spring:
  cloud:
    nacos:
      discovery:
        server-addr: 127.0.0.1:8848
        group:  baiyan
        cluster-name: BAIYAN
        ephemeral: false   //持久化实例，使用 CP架构
        ephemeral: true    //临时实例，使用 AP架构

1. Временный экземпляр, выберитеAPархитектура с использованиемDistroПротокол, тип распределенного протокола, внутренний протокол Али, сервис размещается в памяти
2. постоянный экземпляр, выберитеCPархитектура с использованиемRaftСоглашение для достижения, нажмите, чтобы посмотретьRaftДетали соглашения! Сервисы размещаются на диске

кластер Redis

Благодаря автоматическому сегментированию и избыточным данным Redis обладает реальными распределенными возможностями.Если узел зависает из-за резервного копирования данных на других узлах, другие узлы могут продолжать предоставлять услуги, когда они появляются, обеспечивая доступность. Однако из-за этого Redis не может гарантировать высокую согласованность, которой он когда-то был. Этого также требует теория CAP, и можно выбрать только два из трех.

мастер-ведомый mysql

Подобно Redis, один ведущий и несколько подчиненных не гарантируют синхронизацию данных и узлов данных в реальном времени, используют AP для обеспечения пропускной способности данных и используют CP для обеспечения последовательной синхронизации ведущий-ведомый.

кафка кластер

Схема репликации данных Kafka близка к Master-Slave, разница в том, что Kafka не является ни полной синхронной репликацией, ни полной одношаговой репликацией, а является динамической схемой репликации на основе ISR.

Фиксируются только сообщения, синхронизированные всеми репликами в ISR, но когда производитель записывает данные, лидеру не нужно синхронизировать данные во всех репликах в ISR, чтобы подтвердить получение данных. Производитель может использовать параметр acks, чтобы указать минимальное количество реплик, необходимых для подтверждения получения сообщения, прежде чем сообщение будет считаться успешно отправленным. Значение по умолчанию для acks равно 1, то есть после того, как Лидер получит сообщение, он немедленно сообщает Продюсеру о получении сообщения.В это время, если Лидер выйдет из строя до того, как сообщение в ISR будет скопировано, сообщение будет потерянный. Рекомендуемая практика: установить acks на все или -1.В это время, только когда все реплики в ISR получили данные (и сообщение было зафиксировано), лидер сообщит производителю, что сообщение было отправлено успешно, что гарантирует, что не будет неизвестной потери данных.

Вы можете свободно использовать AP или CP в соответствии с требованиями к пропускной способности kafka.

2.5. Резюме

CAP — это чисто теоретический уровень концептуального знания. Однако многие промежуточное ПО или многие бизнес-системы строят системы распределенных приложений на основе этой теории. Лучшей разницы между CP и AP нет, подходит только сцена.

3. БАЗА

По моему мнению, я не встречал на собеседовании теорию BASE, но ее теоретический статус такой же, как и у CAP, что незаменимо для студентов, подвергающихся распределенной разработке.

3.1 Концепция

Теория BASE — это аббревиатура трех фраз: Basicly Available, Soft State и Ultimate Consistent.

BASE является результатом компромисса между согласованностью и доступностью в CAP, и он постепенно развивается на основе закона CAP. Основная идея состоит в том, что даже если не удается достичь строгой согласованности, каждое приложение может достичь окончательной согласованности надлежащим образом в соответствии со своими бизнес-характеристиками.

3.1.1 Доступны основные

Предположим, что в системе произошел непредсказуемый сбой, но ее все еще можно использовать по сравнению с обычной системой:

потеря времени отклика:

При нормальных обстоятельствах страница отображения продукта возвращает результат пользователю через 0,5 секунды, в то время как обычно доступная страница продукта может вернуть результат примерно за 2 секунды.

функциональная потеря:

【обычный】На веб-сайте электронной коммерции при нормальных обстоятельствах пользователи могут выполнять каждый заказ.

【Ограничение】Тем не менее, в период большой акции, чтобы защитить стабильность системы покупок, некоторые потребители могут быть перенаправлены на страницу понижения.

【Понижение】Или для того, чтобы обеспечить доступность основных функций системы, некоторые неосновные функции приостанавливаются.Например, во время акции Double 11 невозможно отследить платежные данные более ранних событий.

3.1.2 Мягкие состояния

Данные в системе могут находиться в промежуточном состоянии, и считается, что это состояние не влияет на общую доступность системы, то есть система может иметь задержки данных в копиях данных нескольких разных узлов. .

Пример

Например, репликация данных узла master-slave redis. В определенный момент данные ведущего и ведомого узлов синхронизируются, и возникает несогласованность данных.

3.1.3 Конечная согласованность

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

Пример

Это по-прежнему репликация данных master-slave, описанная выше redis.После прохождения пика трафика эффективность репликации master-slave повышается, и, наконец, данные узла master-slave становятся согласованными.

3.2 В чем польза теории BASE?

Принцип CAP состоит в том, чтобы выбрать два из трех, а принцип BASE является компромиссом CAP.Обязательны все три из C, A и P, но каждый принцип не гарантируется на 100%. Распределенные системы должны отдавать приоритет гарантии P, и в большинстве случаев это компромисс между C и A.

Можно также сказать, что система, удовлетворяющая AP, в определенной степени соответствует принципу BASE.Например, в кластере eurka ​​два из трех узлов зависают, а система все еще в основном доступна (BA) . Если в это время есть система для регистрации, из-за того, что два узла зависли, данные каждого узла во всей системе несовместимы, но когда два зависших узла будут восстановлены, данные будут синхронизированы для обеспечения окончательного согласованность (E), состояние, в котором промежуточные данные временно несогласованны, можно назвать мягким состоянием (S).

В целом, теория BASE ориентирована на крупномасштабные, высокодоступные и масштабируемые распределенные системы, в отличие от традиционных ACID-характеристик вещей.Она полностью отличается от модели строгой согласованности ACID, но обеспечивает доступность, жертвуя строгой согласованностью, и позволяет данным быть несогласованными в течение определенного периода времени, но в конечном итоге достигает согласованного состояния..

4. Вопросы для интервью

1. Расскажите мне о теории CAP?

2. Как nacos выбирает протокол, когда он действует как центр регистрации и центр настройки, и почему?

3. Какой распределенный протокол вы знаете [Paxos, Raft] и какое промежуточное ПО используется?

4. Каковы критерии выбора CP, AP и CA?

В тексте даны 1, 2, 4 ответа,Paxos，RaftО соглашении задают относительно немного вопросов, и те, кто заинтересован, могут самостоятельно использовать Baidu.

5. Резюме

Будь то CAP или BASE, конечной целью является обеспечение согласованности или доступности данных в распределенных ситуациях. Конечно, у вас не может быть и того, и другого.В соответствии с разным позиционированием разных систем в разных бизнес-сценариях вы можете выбирать разные способы реализации распределенной архитектуры.

6. Ссылка

Распределенная теория (1) - теорема CAP

Распределенная теория (2) - BASE Theory

Архитектура CP кластера Nacos, применение принципа CAP и принципа BASE

7. Свяжитесь со мной

Если есть неточности в тексте, поправьте меня, текст писать непросто, ставьте лайк, ладно~

Диндин: louyanfeng25

WeChat: baiyan_lou

Общественный номер: дядя Бай Ян