предисловие
Принцип CAP, также известный как теорема CAP, относится к тому факту, что в распределенной системе трем основным требованиям согласованности, доступности и устойчивости к разделам одновременно может удовлетворяться не более двух из них.
текст
1. Введение в принципы CAP
| Опции | описывать |
|---|---|
| Последовательность | Относится к функции, благодаря которой данные могут оставаться согласованными в нескольких копиях (строгая согласованность). |
| Доступность | Это означает, что услуга, предоставляемая системой, должна быть всегда доступна, и на каждый запрос может быть получен безошибочный ответ (не гарантируется, что полученные данные будут самыми последними данными). |
| Допуск перегородки | Когда распределенная система сталкивается с каким-либо сбоем сетевого раздела, она по-прежнему может предоставлять внешние службы, отвечающие требованиям согласованности и доступности, если не произойдет сбой всей сетевой среды. |
Что такое раздел?
В распределенной системе разные узлы распределены по разным подсетям, по каким-то особым причинам сеть между этими подузлами заблокирована, но их внутренние подсети нормальные. В результате среда всей системы делится на несколько изолированных областей, которые и являются перегородками.
2. Принципиальный аргумент CAP
Как показано на рисунке, это основной сценарий для нас, чтобы доказать CAP.В сети есть два узла N1 и N2.Можно легко понять, что N1 и N2 - это два компьютера соответственно, и сеть может быть соединена между ними. В N1 есть приложение A и база данных V, в N2 также есть приложение B и база данных V. Теперь A и B — две части распределенной системы, а V — две подбазы данных хранилища данных распределенной системы.
- Когда согласованность удовлетворена, данные в N1 и N2 одинаковы, V0=V0.
- Когда доступность удовлетворена, независимо от того, запрашивает ли пользователь N1 или N2, он получит немедленный ответ.
- В случае удовлетворительной отказоустойчивости раздела, когда одна из сторон N1 и N2 не работает или сеть заблокирована, нормальная работа N1 и N2 не пострадает.
Как показано на рисунке, это нормальный процесс работы распределенной системы: пользователь запрашивает обновление данных с машины N1, и программа А обновляет базу данных V0 до V1. Распределенная система выполняет операцию синхронизации М над данными и синхронизирует V0 в N2 с V1, так что данные V0 в N2 также обновляются до V1, а данные в N2 отвечают на запрос N2.
В соответствии с принципом CAP согласованность, доступность и устойчивость системы к разделам подразделяются следующим образом:
- Непротиворечивость: совпадают ли данные между базами данных V из N1 и N2.
- Доступность: Могут ли N1 и N2 нормально отвечать на внешние запросы.
- Отказоустойчивость раздела: совместима ли сеть между N1 и N2.
Это нормальный сценарий функционирования и идеальный сценарий. Как распределенная система, самая большая разница между ней и автономной системой — это сеть. Теперь предположим крайний случай, когда сеть между N1 и N2 отключена, и мы хотим поддерживать эту сетевую аномалию. Эквивалентно удовлетворению отказоустойчивости раздела, может ли он удовлетворить как согласованность, так и доступность? Или вы хотите выбрать между ними?
Если предположить, что пользователь отправляет запрос на обновление данных в N1, когда сеть между N1 и N2 отключена, данные V0 в N1 будут обновлены до V1. Поскольку сеть отключена, распределенная система работает M синхронно, поэтому данные в N2 по-прежнему V0. В это время пользователь отправляет запрос на чтение данных в N2.Поскольку данные не были синхронизированы, приложение не может немедленно вернуть пользователю последние данные V1.Что делать?
Здесь есть два варианта:
- Во-первых: пожертвуйте согласованностью данных, чтобы обеспечить доступность. Ответьте на старые данные V0 пользователю.
- Во-вторых: пожертвовать доступностью для обеспечения согласованности данных. Заблокируйте и подождите, пока сетевое соединение будет восстановлено и операция обновления данных M будет завершена, а затем пользователю будут отправлены последние данные V1.
Этот процесс доказывает, что для обеспечения отказоустойчивости разделов распределенной системы можно выбрать только один из параметров согласованности и доступности.
3. Компромиссы принципа CAP
Благодаря теории CAP мы знаем, что три характеристики согласованности, доступности и отказоустойчивости разделов не могут быть удовлетворены одновременно, так что же следует отбросить?
3.1. CA without P
Если P не требуется (разделение не разрешено), то гарантируется C (строгая согласованность) и A (доступность). Но на самом деле партиционирование - это не вопрос хотите вы этого или нет, а будет существовать всегда.Поэтому система CA больше для того, чтобы каждая подсистема после разделения оставалась CA.
3.2. CP without A
Если A (доступно) не требуется, это означает, что каждый запрос должен быть строго согласован между серверами, а P (раздел) приведет к неограниченному увеличению времени синхронизации, поэтому CP также может быть гарантировано. Многие традиционные распределенные транзакции баз данных подпадают под этот шаблон.
3.3. AP wihtout C
Чтобы обеспечить высокую доступность и разрешить разбиение на разделы, вам нужно отказаться от согласованности. После разделения узлы могут потерять связь.Для обеспечения высокой доступности каждый узел может предоставлять услуги только с локальными данными, что приведет к несогласованности глобальных данных. Многие NoSQL теперь попадают в эту категорию.
резюме
Для большинства крупномасштабных сценариев интернет-приложений существует множество хостов и разбросанных развертываний. И теперь масштаб кластера становится все больше и больше, поэтому сбои узлов и отказы сети — это норма. Такому типу приложений обычно необходимо обеспечить, чтобы доступность службы достигла N 9s, то есть гарантировать P и A, и только отказаться от C (следующий шаг — обеспечить конечную согласованность). В то время как некоторые места повлияют на качество обслуживания клиентов, но не до такой степени, что вызовут поток пользователей.
Для сценариев, в которых нет уступок, таких как деньги, C должен гарантировать. В случае сбоя в сети лучше остановить службу, чтобы убедиться, что ЦС и отбросить P. Кажется, за последние несколько лет в отечественной банковской отрасли произошло не менее 10 аварий, но их влияние невелико, регистраций не так много, и широкой публике известно очень мало. Другой заключается в обеспечении CP и отказе от A, например, только для чтения, а не только для записи в случае сбоя сети.
Что лучше или хуже, вывода нет, решать можно только по сцене, подходящий - лучший.
Ссылки по теме
- Распределенная теория (1) - теорема CAP
- Распределенная теория (2) - BASE Theory
- Распределенная теория (3) - протокол 2PC
- Распределенная теория (4) — протокол 3PC
- Распределенная теория (5) - Алгоритм согласованности Paxos
- Распределенная теория (6) — Плот протокола согласованности
Добро пожаловать, чтобы отсканировать код и подписаться на официальный аккаунт: Zero One Technology Stack.
Эта учетная запись будет продолжать делиться сухими товарами серверных технологий, включая основы виртуальных машин, многопоточное программирование, высокопроизводительные фреймворки, асинхронное ПО, промежуточное ПО для кэширования и обмена сообщениями, распределенные и микросервисы, материалы для обучения архитектуре и расширенные учебные материалы и статьи.