введение

Теория CAP, я думаю, многие о ней слышали, относится к:

Распределенная система может одновременно удовлетворять не более двух из трех требований согласованности (Consistency), доступности (Availability) и устойчивости к разделению (Partition Tolerance).

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

Например, есть такая задача, которая ставит перед вами три основные цели:

1. Необходимо улучшить доступность системы.
2. Также необходимо обеспечить видимость данных в режиме реального времени.
3. и повысить отказоустойчивость системы.

Когда видишь «и хочу, хочу и хочу», ты думаешь об Али...

Хорошо, если вы глубоко разбираетесь в CAP, вы обнаружите, что выполнить эту задачу невозможно. Однако, если вы не понимаете CAP, а затем похлопываете себя по груди, чтобы убедиться, что выполнили задание, извините, на рабочем месте не нужно слез и сожалений.

Я немного отвлекся, вернемся к основной истории. Теория CAP — самая основная и важная теория распределенного проектирования. Без ее понимания вы, возможно, даже не сможете проанализировать основные концепции проектирования распределенной системы.

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

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

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

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

Далее вы видите текст, я писал его 10 дней. Это уже третья версия этой статьи. Я отменил и переписал половину первых двух версий, потому что она меня не устроила.

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

С другой стороны, я недоволен тем, что мое письмо слишком неясно и слишком учебнико. Я надеюсь, что знания можно объяснить в простой для понимания форме.

Позвольте мне показать вам, как эта статья выглядела в прошлой жизни.

1. Происхождение CAP

Чтобы понять CAP, нам сначала нужно понять, почему кто-то предложил CAP? Какую проблему предлагается решить CAP?

Еще в 1985 году профессор Линч, позже доказавший теорию CAP, потряс тогдашний ИТ-мир:

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

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

По сути, это говорит всем, что в распределенной системе необходим компромисс.

Но как пойти на компромисс? Как следует взвешивать этот компромисс в распределенной системе?

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

Например, если при синхронизации данных между двумя узлами возникает ошибка, что нам делать? Если не существует единого стандарта и направления, вполне вероятно, что разные модули в распределенной системе будут иметь разные ситуации обработки.

Предположим, что система состоит из двух модулей A и B.

Идея проектирования модуля А такова: если между узлами возникла проблема, он может выбрать непрерывные повторные попытки до тех пор, пока связь между узлами не будет восстановлена.

Концепция конструкции B такова: если между узлами возникла проблема, просто отключите ее. В лучшем случае статус можно записать и устранить позже.

Но что нам делать, когда между А и Б есть связь? Затем A отправит запрос B, и если возникнет проблема, он продолжит попытку. Когда B отправляет запрос A, в случае возникновения проблемы он будет отключен напрямую.

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

Поэтому люди в ИТ-сообществе уже 15 лет ищут какие-то рекомендации по проектированию распределенных систем.

В 2000 году профессор Эрик Брюэр предложил теорию CAP на конференции PODC, но, поскольку она не была доказана, в то время ее можно было назвать только гипотезой CAP. Это предположение вызвало огромный резонанс, поскольку CAP соответствовал ожиданиям людей от описания проекта.

После 2002 года, после того как Сет Гилберт и Нэнси Линч теоретически доказали гипотезу CAP, теория CAP официально стала одним из краеугольных камней теории распределенных систем.

2. Что такое CAP?

Теорема CAP утверждает, что распределенная система не может одновременно удовлетворять следующим трем характеристикам:

2.1. C: Согласованность данных

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

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

Первый вопрос: когда данные изменятся вместе?

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

Тогда давайте ответим на второй вопрос: как можно сказать, что данные изменились вместе? То есть кто будет судить, изменились ли данные окончательно? Это результат, возвращаемый сервером для запроса на запись? Если вы успешно сообщите запрос на запись, данные должны были последовательно измениться?

НЕТ, согласованность изменений данных должна быть проверена с помощью запроса на чтение. Так что же является основой для оценки запросов на чтение?

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

Однако это не полная последовательность. Потому что система не может нормально работать вечно.

Что произойдет, если в системе возникнет проблема, которая препятствует последовательным изменениям в узлах системы? Когда мы это делаем, это означает, что запросы на чтение, которые хотят увидеть последние данные, скорее всего, увидят старые данные или получат другую версию данных. На данный момент, чтобы обеспечить согласованность внешних данных распределенной системы, мы решили не возвращать какие-либо данные.

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

2.2. А: Наличие

Овидий однажды сказал: «Действия забываются, но результаты останутся навсегда».

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

Условие 1. Возвращенный результат должен быть в пределах разумного времени. Это разумное время определяется в зависимости от бизнеса. В бизнесе написано, что его нужно вернуть в течение 100 миллисекунд. Разумное время — 100 миллисекунд. Его нужно вернуть в течение 1 секунды, что составляет 1 секунду. Если бизнес устанавливает 100 миллисекунд, но результат возвращается через 1 секунду, то. система не соответствует доступности.

Условие 2: Все узлы в системе, которые обычно могут получать запросы, должны возвращать результаты. Это имеет два значения:

1. Если узел не может нормально получать запросы, например, он не работает или система выходит из строя, но другие узлы по-прежнему могут нормально принимать запросы, то мы говорим, что система все еще доступна. Другими словами, частичный простой — это нормально и не влияет. индекс доступности.
2. Если узел может нормально принять запрос, но обнаруживается проблема с внутренними данными узла, результат должен быть возвращен, даже если возвращенный результат проблематичен. Например, в системе есть два узла, данные одного узла датированы тремя днями ранее, а данные другого узла — две минуты назад. Если запрос на чтение поступает к узлу, содержащему данные трехдневной давности, извините, этого узла не может быть. отклонено, и данные трехдневной давности должны быть возвращены, даже если это может быть неразумно.

2.3. P: Допуск раздела.

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

Например, наша распределенная система хранения имеет два узла A и B. Затем, когда возникает проблема со связью между A и B из-за возможного отказа основного сетевого оборудования, такого как маршрутизаторы и коммутаторы, A и B все еще работают и предоставляют услуги внешнему миру. В это время говорят, что A и B разделены.

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

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

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

3. Как выбрать КАП

Выше мы уже знаем, что при проектировании распределенной системы архитекторы могут выбрать только две из трех характеристик C, A и P.

Однако этот вопрос CAP с несколькими вариантами ответов похож на тот, как будто вас спрашивают: «У отца Сяо Мина трое детей. Старшего — Даланг, а второго — Эрланг. Как зовут третьего?» В мире CAP, где распределенные системы хранения являются ограничивающими условиями, P является давно признанным ответом, и P необходим.

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

В соответствии с различными вариантами согласованности и доступности распределенные системы с открытым исходным кодом часто делятся на системы CP и системы AP.

После того, как в системе происходит сбой раздела, любой запрос от клиента зависает или истекает по тайм-ауту, но каждый узел системы всегда возвращает согласованные данные. Тогда система является системой CP, такой как Zookeeper.

Если в системе произошел сбой раздела и клиент по-прежнему может получить доступ к системе, но часть полученных данных — это новые данные, а часть — старые данные, то система является системой AP, такой как Eureka.

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

Итак, давайте опишем CAP простым языком. CAP сообщает программистам, что при возникновении внутренней проблемы в распределенной системе вам нужно сделать два выбора:

• Или привлекать внешние услуги, например, аутсорсинговые компании.
• Или позвольте внешней службе удовлетворить вас, например банку.

Использование внешних сервисов означает, что мы не можем допустить, чтобы бизнес-операции внешних сервисов пострадали из-за наших собственных проблем, поэтому мы должны уделять приоритетное внимание доступности. Чтобы внешние сервисы могли приспособиться к нам, мы должны уделять приоритетное внимание согласованности.

4. Распространенные заблуждения о CAP

Недоразумение 1: Распределенные системы отказываются от одного из C или A из-за теоремы CAP.

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

Это понимание весьма проблематично. Поскольку вероятность возникновения этой проблемы очень мала, поэтому:

При отсутствии проблем с разделами система должна иметь идеальную согласованность и доступность данных.

Вы когда-нибудь видели систему, которая часто застревает на внешних запросах, хотя внутренних проблем нет? Или просто внезапно предоставить устаревшие старые данные? Можем ли мы по-прежнему называть это системой?

Недоразумение 2: Выбор между C и A касается всей распределенной системы. Только выбор между C и A можно рассматривать как единое целое.

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

Это может быть принятие каких-то решений в каких-то подсистемах или даже просто решение о согласованности и доступности определенного события или данных.

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

Работа распределенной системы, как и жизнь, заключается в том, чтобы делать выбор снова и снова. Как мы можем иметь одинаковый выбор, когда разные события происходят на разных этапах и в разные моменты?

Недоразумение 3: Три характеристики CAP имеют только два крайних варианта выбора: да и нет, а не диапазон.

Это дуалистическое понимание крайне ошибочно.

Три характеристики теории CAP не относятся к логическому типу и не представляют собой варианты с двумя вариантами выбора, такие как согласованность и несогласованность, доступность и недоступность, разделение и отсутствие разделения. Скорее, все три свойства являются типами диапазонов.

По доступности это как будто я снимаю деньги в банке. Когда моей целью является раздача новогодних денег, я, вероятно, хочу получить все новые билеты. Однако, вероятно, есть дополнительный шаг для получения новых билетов, а именно обмен старых билетов на новые. Я могу подождать еще немного. Было бы неплохо получить новые билеты позже. Но когда моя цель — покрыть расходы на жизнь, меня совершенно не волнует, новые или старые счета, я просто хочу получить деньги как можно скорее. Это одно из требований доступности, требование задержки.

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

5. Некоторые вопросы о теории CAP

Вопрос 1. Подходит ли он для произвольных запросов на запись в системе, подчиняющейся теореме CAP?

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

Итак, вопрос в том, есть ли какие-либо требования к записи данных, когда нам требуется видимость считываемых данных?

Например, в нашей системе есть три узла. Клиент отправляет в систему запрос на запись, прося систему записать данные со значением 20. Затем, если вы хотите обеспечить согласованность теоремы CAP, вам необходимо после записи данных 20, когда другие клиенты запрашивают чтение данных со значением 20, независимо от того, пересылается ли запрос на любой узел в системе. , это может быть возвращено значение.

Для этого требуется, чтобы запрос на запись со значением 20 был успешно записан на три узла. В это время система обеспечивает согласованность записи. Следовательно, мы можем сказать, что требование согласованности чтения также ограничивает согласованность записи.

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

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

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

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

Вопрос 2. Соответствуют ли распределенные системы шардинга и реплики данных теореме CAP?

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

Итак, если в распределенной системе есть только хранилище фрагментов данных или только хранилище копий данных, все ли они будут соответствовать теореме CAP?

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

Как поведет себя теория CAP, когда в распределенной системе имеется только сегментированное хранилище?

Например, у нас есть распределенная система, состоящая из трех узлов a, b и c. Среди них узел a хранит данные таблицы A, узел b хранит данные таблицы B, а узел c хранит данные таблицы C.

Если есть бизнес, целью которого является вставить новый фрагмент данных в таблицу A, удалить существующий фрагмент данных в таблице B и обновить старый фрагмент данных в таблице C, как эта распределенная система должна справиться с этим видом бизнеса? ?

Технически, когда мы хотим сделать несколько вещей с одним намерением, мы часто упаковываем их в одну транзакцию. Когда мы упаковываем его в транзакцию, мы можем сначала выполнить его на узле a, затем перейти к узлу b для выполнения и, наконец, перейти к узлу c для выполнения. Когда все будут успешными, будет возвращен успех.

Но что делать после того, как произошел раздел? Когда узлы a и b работают успешно, когда дело доходит до c, происходит сбой связи?

В это время, согласно теореме CAP, у вас есть два варианта: либо напрямую вернуть клиенту частично успешный результат, либо напрямую дождаться истечения времени ожидания клиента, либо вернуть клиенту ошибку. Если возвращается частичный успех, выбирается доступность (A). Когда клиенту возвращается зависание или сбой, выбирается согласованность (C).

Однако мы упаковываем запросы в транзакции, а транзакции должны либо завершиться успешно, либо провалиться... Чтобы соблюсти это требование, в случае только распределенного шардинга в силу объективных условий мы можем выбрать только C. Следовательно, шардированные распределенные системы часто представляют собой системы CP.

Необязательный, но не обязательный — это особое проявление теоремы CAP, когда в распределенной системе имеется только сегментированное хранилище данных.

и Когда распределенная система состоит из нескольких узлов,Каждый узел хранит полный набор данных,Когда другие узлы являются лишь резервными копиями полных данных,Даже если транзакция завершится успешно только на одной машине,Когда происходит сбой раздела,У нас также есть достаточно места для выбора,Откат отдельных транзакций or В связи с этим считается, что написание прошло успешно.。

Откат транзакции с одним компьютером может быть внешне отображен как выбор согласованности.

Если написание признано успешным, можно считать, что доступность выбрана.

Вопрос 3: Почему иногда так сложно отличить систему AP или CP?

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

6. Недостатки CAP

1. CAP Сама по себе проблема задержки в сети не рассматривается. Она считает, что согласованность вступает в силу немедленно. Однако поддержание согласованности требует временных затрат, что приводит к множественному выбору в Прошло Прошлораспределенной системе. AP Способ
2. В связи с развитием времени CAP Результата существует верно Все распределенные системы испытывали некоторую некомпетентность, что неоднократно приводило к тому, что ранее строгие математические определения менялись на более мягкие бизнес-определения, подобно тому, что мы видели в CAP. Теорема превращает согласованность, доступность и отказоустойчивость разделения в атрибуты диапазона, и это то же самое, что CAP Сама теорема, называемая математической теоремой, противоречива и не соответствует строгому определению математики.
3. на практике и позже CAP Автор теоремы также признал, что непротиворечивость и доступность — это не просто вопрос выбора одного из другого. Это просто различия по важности. Когда подчеркивается непротиворечивость, это не означает, что доступность — это полностью недоступное состояние. Например, Зоопарковщик Просто в master При возникновении проблемы она может быть недоступна в течение десятков секунд. В других случаях будут приняты различные меры для обеспечения доступности системы. Подчеркивая доступность, Прошлое Прошлое также будет использовать некоторые технические средства, чтобы гарантировать, что данные в конечном итоге непротиворечивы. КАП Теорема не дает конкретного описания этих ситуаций.
4. С инженерной точки зрения теория CAP — это всего лишь описание состояния.,Он сообщает всем, когда что-то не так,распределенный В каком состоянии может находиться система. но,Статус может быть изменен. Как переходить между состояниями,Как исправить,Никаких указаний о том, как восстановиться, не предусмотрено.

7. Производная БАЗА

Из-за вышеуказанных недостатков CAP Дэн Притчетт, архитектор epay, обобщил теорию BASE, основываясь на своем собственном практическом опыте работы с крупномасштабными распределенными системами. Теория BASE является расширением теории CAP. Основная идея заключается в том, что даже если строгая согласованность (сильная согласованность) не может быть достигнута, приложение может использовать соответствующие методы для достижения окончательной согласованности (Eventual Consistency).

Теория BASE — это теория практической инженерии. Она компенсирует чрезмерно абстрактную проблему теории CAP, а также решает общую инженерную практику системы AP. Это одна из основных теорий распределенных систем. Мы объясним это подробно. в следующей статье объясните эту теорию.

8. Вопросы на собеседовании от крупных производителей

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

• Что такое теория CAP?
• Что означает буква P в CAP?
• зачем говоритьраспределенныйсистема,может толькосуществовать C、A Выбрать один из двух?
• Как выбрать CP и AP на основе практического применения?