Теорема CAP - Доступность и Допуск Разделения

В то время как я пытаюсь понять «Доступность» (A) и «Допуск разделения» (P) в CAP, мне было трудно понять объяснения из различных статей.

У меня возникает ощущение, что А и Р могут идти вместе (я знаю, что это не так, и поэтому я не понимаю!).

Объясняя простыми словами, что такое А и Р и чем они отличаются?

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

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

Допуск раздела означает, что кластер продолжает функционировать, даже если существует «разделение» (обрыв связи) между двумя узлами (оба узла работают, но не могут обмениваться данными).

Чтобы получить доступность и допуск на разделы, вы должны отказаться от согласованности. Подумайте, есть ли у вас два узла, X и Y, в настройке мастер-мастер. Теперь между сетями X и Y есть разрыв, поэтому они не могут синхронизировать обновления. На данный момент вы можете:

A) Разрешить узлам выходить из синхронизации (отказ от согласованности), или

Б) Считать кластер «выключенным» (отказавшись от доступности).

Все доступные комбинации:

• CA - данные согласованы между всеми узлами - до тех пор, пока все узлы подключены к сети - и вы можете читать / записывать с любого узла и быть уверенным, что данные одинаковы, но если вы когда-нибудь создадите разделение между узлами, данные будут несинхронизировано (и не будет повторно синхронизироваться после разрешения раздела).
• CP - данные согласованы между всеми узлами и поддерживают допуск раздела (предотвращая рассинхронизацию данных), становясь недоступными при выходе из строя узла.
• AP - узлы остаются подключенными, даже если они не могут общаться друг с другом, и будут повторно синхронизировать данные после разрешения раздела, но вы не гарантированы, что все узлы будут иметь одинаковые данные (во время или после раздела)

Следует отметить, что системы CA практически не существуют (даже если некоторые системы утверждают, что таковыми являются).

Рассматривать P в равных терминах с C и A немного ошибочно, скорее, понятие «2 из 3» среди C, A, P вводит в заблуждение. Я бы кратко объяснил теорему CAP: «В распределенном хранилище данных во время сетевого раздела вы должны выбрать либо« Согласованность », либо« Доступность »и не можете получить оба». Более новые системы NoSQL пытаются сосредоточиться на доступности, в то время как традиционные базы данных ACID уделяют больше внимания согласованности.

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

Вот как я обсуждаю CAP, особенно в отношении P.

CA возможен только в том случае, если у вас все в порядке с монолитной базой данных с одним сервером (возможно, с репликацией, но все данные в одном «блоке сбоев» - серверы не считаются частично сбоев).

Если ваша проблема требует масштабирования, могут возникнуть распределенные и многосерверные --- сетевые разделы. Вы уже требуете P. Немногие проблемы, к которым я подхожу, поддаются парадигмам, всегда ориентированным на один сервер (или, как сказал Стоунбрейкер, «распределенные ставки - это столы»). Если вы можете обнаружить проблему с CA, такие решения, как традиционная не масштабируемая СУБД, дают много преимуществ.

Для меня редкость: поэтому мы переходим к обсуждению AP против CP.

Вы можете выбирать между операциями AP и CP только при наличии раздела. Если сеть и оборудование работают правильно, вы получите свой торт и съедите его тоже.

Давайте обсудим различие AP / CP.

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

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

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

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

В системе CP, сколько недоступности вы получаете с небольшими разделами (один сервер), если таковые имеются? Большая репликация может увеличить недоступность в системе CP, как система справляется с этими компромиссами?

Все эти вопросы нужно задать с помощью CP против AP.

В этой области сейчас отлично читается пост Брюера «12 лет спустя». Я считаю, что это продвигает дебаты в CAP с ясностью, и очень рекомендую это.

http://www.infoq.com/articles/cap-twelve-years-later-how-the-rules-have-changed

Последовательность:

При чтении гарантированно возвращается самая последняя запись (например, ACID) для данного клиента. Если какой-либо запрос приходит в течение этого времени, он должен ждать, пока синхронизация данных не будет завершена через / в узлах.

Доступность:

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

Раздел толерантности:

Система продолжит функционировать при возникновении сетевых разделов.

Что касается AP , доступность (всегда доступная) может существовать с ( Cassendra ) или без ( RDBMS ) допусков раздела

источник изображения

Я чувствую, что толерантность к разделам плохо объясняется ни в одном из ответов, поэтому просто объяснить вещи более подробно теорема CAP означает:

C : (Линеаризуемость или сильная согласованность) примерно означает

Если операция B началась после успешного завершения операции A, то операция B должна видеть систему в том же состоянии, в котором она была при завершении операции A, или в более новом состоянии (но никогда не в старом состоянии).

A :

«Каждый запрос, полученный не исправным узлом [базы данных] в системе, должен приводить к ответу [без ошибок]». Недостаточно, чтобы какой-то узел мог обработать запрос: любой исправный узел должен быть в состоянии обработать его. Многие так называемые «высокодоступные» (то есть с низким временем простоя) системы фактически не соответствуют этому определению доступности.

P :

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

Источник: Высокий Мартин kleppmann в работе

Просто для примера: Кассандра может в максимальной степени быть системой AP. Но если вы сконфигурируете его для чтения или записи на основе кворума, то он не останется доступным CAP (доступным в соответствии с определением теоремы CAP) и будет только P-системой.

В простой теореме CAP говорится, что распределенной системе невозможно одновременно обеспечить все три гарантии:

консистенция

Каждый узел содержит одни и те же данные одновременно

Доступность

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

Допуск раздела

Отказ системы очень редко

В большинстве случаев каждая система может гарантировать только две функции: CA, AP или CP .

Согласованность. Когда мы отправляем запрос на чтение, если он возвращает результат, он должен возвращать самую последнюю запись, данную клиентским запросом. Доступность - Ваш запрос на чтение / запись всегда должен быть успешным. Допуск на разделы - когда существует сетевой раздел (проблема, с которой некоторые машины общаются друг с другом), система все равно должна работать.

В распределенном есть вероятность, что сетевой раздел произойдет, и мы не можем избежать «P» CAP. Поэтому мы выбираем между «Последовательность» и «Доступность».

http://bigdatadose.com/understanding-cap-theorem/

Простой способ понять теорему CAP:

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

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

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

Это объяснение из этой прекрасной статьи . Надеюсь, это поможет.

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

Поэтому я описываю CAP в очень простых формулировках.

• Согласованность : должны возвращать одни и те же данные независимо от того, с какого узла они поступают.

• Доступность : узел должен ответить (должен быть доступен).

• Допуск раздела : Кластер должен отвечать (должен быть доступен), даже если между узлами существует раздел (т.е. сбой сети).

(Также одной из основных причин, по которой это смущает больше, является плохое соглашение об именах. Если бы я имел право, я бы дал DNC теоремы вместо: Data Консистенция , доступность узла , доступность кластера , где каждый из которых соответствует Консистенции , доступность и Partition Tolerance соответственно)

База данных CP: база данных CP обеспечивает согласованность и допуск раздела за счет доступности. Когда разделение происходит между любыми двумя узлами, система должна завершить работу несогласованного узла (то есть сделать его недоступным), пока раздел не будет разрешен.

База данных AP. База данных AP обеспечивает доступность и допуск раздела за счет согласованности. Когда возникает раздел, все узлы остаются доступными, но те, которые находятся не в том конце раздела, могут вернуть более старую версию данных, чем другие. (Когда раздел разрешен, базы данных AP обычно повторно синхронизируют узлы, чтобы устранить все несоответствия в системе.)

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

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

Источник: https://www.ibm.com/cloud/learn/cap-theorem