Хотя я пытаюсь понять «Доступность» (A) и «Допуск разделения» (P) в CAP, мне было трудно понять объяснения из различных статей.
У меня такое чувство, что A и P могут идти вместе (я знаю, что это не так, и поэтому не понимаю!).
Объясняя простым языком, что такое A и P и чем они отличаются?
Согласованность означает, что данные одинаковы во всем кластере, поэтому вы можете читать или записывать с / на любой узел и получать одни и те же данные.
Доступность означает возможность доступа к кластеру, даже если узел в кластере выходит из строя.
Допуск на разделение означает, что кластер продолжает функционировать, даже если существует «раздел» (разрыв связи) между двумя узлами (оба узла работают, но не могут общаться).
Чтобы получить как доступность, так и устойчивость к разделам, вы должны отказаться от согласованности. Подумайте, есть ли у вас два узла, X и Y, в настройке мастер-мастер. Теперь существует разрыв между сетевым взаимодействием между X и Y, поэтому они не могут синхронизировать обновления. На этом этапе вы можете:
A) Разрешите узлам выйти из синхронизации (отказ от согласованности) или
Б) Считайте кластер "неработающим" (отказ от доступности)
Все доступные комбинации:
Обратите внимание, что систем CA практически не существует (даже если некоторые системы утверждают, что так).
Рассмотрение P в равных условиях с C и A - это небольшая ошибка, скорее, понятие «2 из 3» среди C, A, P вводит в заблуждение. Я бы кратко объяснил теорему CAP: «В распределенном хранилище данных во время разделения сети вы должны выбрать либо согласованность, либо доступность и не можете получить и то, и другое». Новые системы NoSQL пытаются сосредоточиться на доступности, в то время как традиционные базы данных ACID уделяют больше внимания согласованности.
Вы действительно не можете выбрать CA, сетевой раздел - это не то, что кто-то хотел бы иметь, это просто нежелательная реальность распределенной системы, сети могут выходить из строя. Вопрос в том, какой компромисс вы выберете для своего приложения, когда это произойдет. Эта статья от мужчины кто первым сформулировал этот термин, кажется, очень ясно это объясняет.
Вот как я обсуждаю CAP, особенно в отношении P.
CA возможен только в том случае, если у вас все в порядке с монолитной базой данных с одним сервером (возможно, с репликацией, но все данные в одном «блоке сбоя» - серверы не считаются частично отказавшими).
Если ваша проблема требует масштабирования, распределения и работы с несколькими серверами - могут возникнуть сетевые разделы. Вам уже требуется P. Некоторые проблемы, которые я подхожу, поддаются парадигме «всегда один сервер» (или, как сказал Стоунбрейкер, «распределение - это ставки стола»). Если вы можете найти проблему CA, такие решения, как традиционная немасштабируемая СУБД, предоставляют множество преимуществ.
Для меня это редкость: поэтому мы переходим к обсуждению AP vs CP.
Вы выбираете только между AP и CP, когда у вас есть раздел. Если сеть и оборудование работают правильно, вы получите свой пирог и тоже его съедите.
Давайте обсудим различие AP / CP.
AP - когда есть сетевой раздел, пусть независимые части работают свободно.
CP - при наличии сетевого раздела выключите узлы или запретите чтение и запись, чтобы возникли детерминированные сбои.
Мне нравятся архитектуры, которые могут делать и то, и другое, потому что некоторые проблемы связаны с AP, а некоторые с CP, а некоторые базы данных могут справиться и с тем, и с другим. Среди решений CP и AP тоже есть свои тонкости.
Например, в наборе данных AP у вас есть возможность как несогласованного чтения, так и возникновения конфликтов записи - это два разных возможных режима AP. Можно ли настроить вашу систему для точки доступа с высокой доступностью для чтения, но не допускать конфликтов записи? Или ваша AP-система может принимать конфликты записи с сильной и гибкой системой разрешения? В конечном итоге вам понадобятся и то, и другое, или вы можете выбрать систему, которая выполняет только одну?
В системе CP, насколько недоступны небольшие разделы (один сервер), если таковые имеются? Большая репликация может увеличить недоступность в CP-системе, как система справляется с этими компромиссами?
Это все вопросы, которые следует задать при выборе CP vs AP.
Отличное чтение в этой области сейчас - это пост Брюера «12 лет спустя». Я считаю, что это продвигает обсуждение CAP с ясностью, и настоятельно рекомендую это сделать.
http://www.infoq.com/articles/cap-twelve-years-later-how-the-rules-have-changed
При чтении гарантируется возврат самой последней записи (например, ACID) для данного клиента. Если в это время поступает какой-либо запрос, он должен дождаться завершения синхронизации данных между узлами и узлами.
каждый узел (если он не отказал) всегда выполняет запросы и всегда должен отвечать на запросы. Не имеет значения, вернет он последнюю копию или нет.
Система продолжит функционировать при возникновении сетевых разделов.
Что касается AP, доступность (всегда доступная) может существовать с (Cassendra) или без (RDBMS) допуска раздела.
Я просмотрел много ссылок, но ни одна из них не смогла дать мне удовлетворительного ответа, кроме одной.
Поэтому я описываю CAP очень простыми формулировками.
Согласованность: должны возвращать одни и те же данные, независимо от того, с какого узла они поступают.
Доступность: узел должен ответить (должен быть доступен).
Допуск раздела: Кластер должен отвечать (должен быть доступен), даже если между узлами существует раздел (например, сбой сети).
(Также одна из основных причин, по которой это больше сбивает с толку, - это неправильное соглашение об именах. Если бы я был прав, я мог бы вместо этого дать теорему DNC: Согласованность данных, Доступность узла , Доступность кластера, где каждому соответствует Согласованность, Доступность и Допуск раздела соответственно)
База данных CP. База данных CP обеспечивает согласованность и устойчивость к разделам за счет доступности. Когда между любыми двумя узлами происходит разделение, система должна выключить несогласованный узел (т.е. сделать его недоступным) до тех пор, пока раздел не будет разрешен.
База данных AP: База данных AP обеспечивает доступность и устойчивость к разделам за счет согласованности. Когда возникает раздел, все узлы остаются доступными, но те, которые находятся не на том конце раздела, могут вернуть более старую версию данных, чем другие. (Когда раздел разрешен, базы данных AP обычно повторно синхронизируют узлы для устранения всех несоответствий в системе.)
База данных CA. База данных CA обеспечивает согласованность и доступность на всех узлах. Однако он не может этого сделать, если между любыми двумя узлами в системе есть раздел, и, следовательно, не может обеспечить отказоустойчивость. В распределенной системе нельзя избежать разделов. Итак, хотя мы можем обсуждать распределенную базу данных CA теоретически, для всех практических целей распределенная база данных CA может существовать, но не должна существовать.
Следовательно, это не означает, что у вас не может быть базы данных CA для вашего распределенного приложения, если она вам нужна. Многие реляционные базы данных, такие как PostgreSQL, обеспечивают согласованность и доступность и могут быть развернуты на нескольких узлах с помощью репликации.
Источник: https://www.ibm.com/cloud/learn/cap-theorem
Я чувствую, что толерантность к разделению не объясняется хорошо ни в одном из ответов, поэтому более подробное объяснение теоремы CAP означает:
C: (линеаризуемость или сильная согласованность) примерно означает
Если операция B началась после успешного завершения операции A, то операция B должна видеть систему в том же состоянии, в котором она была при завершении операции A, или в более новом состоянии (но никогда в старом состоянии).
A:
«Каждый запрос, полученный исправным узлом [база данных] в системе, должен приводить к ответу [без ошибок]». Недостаточно, чтобы какой-то узел мог обработать запрос: любой исправный узел должен уметь его обрабатывать. Многие так называемые «высокодоступные» (т.е. с низким временем простоя) системы фактически не соответствуют этому определению доступности.
P:
Терпимость раздела (ужасно неверное название) в основном означает, что вы общаетесь по асинхронной сети, которая может задерживать или отбрасывать сообщения. Интернет и все наши центры обработки данных обладают этим свойством, поэтому у вас действительно нет выбора в этом вопросе.
Источник: удивительный Мартин Клеппманн.
Просто возьмем некоторый пример: Cassandra может быть максимальной системой AP. Но если вы сконфигурируете его для чтения или записи на основе кворума, тогда он не останется CAP-доступным (доступным согласно определению теоремы CAP) и будет только системой P.
Простой способ понять теорему CAP:
В случае разделения сети нужно выбирать между идеальной доступностью и идеальной согласованностью.
Выбор последовательности означает невозможность ответить на запрос клиента, поскольку система не может гарантировать возврат самой последней записи. Это приносит в жертву доступность.
Выбор доступности означает возможность ответить на запрос клиента, но система не может гарантировать согласованность, т. е. самое последнее записанное значение. Доступные системы дают наилучший ответ в данных обстоятельствах.
Это объяснение взято из этой замечательной статьи. Надеюсь, это поможет.
В простой теореме CAP говорится, что распределенная система не может одновременно предоставить все три гарантии:
Последовательность
Каждый узел содержит одни и те же данные одновременно
Доступность
По крайней мере, один узел должен быть доступен для обслуживания данных каждый раз.
Допуск на разделение
Выход из строя системы очень редок
В большинстве случаев каждая система может гарантировать минимум две функции: CA, AP или CP.
Согласованность - когда мы отправляем запрос на чтение, если он возвращает результат, он должен возвращать самую последнюю запись, полученную по запросу клиента. Доступность - ваш запрос на чтение / запись всегда должен выполняться. Устойчивость к разделению - когда есть сетевой раздел (проблема для некоторых машин, чтобы разговаривать друг с другом), система по-прежнему должна работать.
В распределенном есть вероятность того, что произойдет разделение сети, и мы не сможем избежать «P» CAP. Поэтому мы выбираем между «Последовательность» и «Доступность».
http://bigdatadose.com/understanding-cap-theorem/
В лейтмотиве Брюера, в статье Гилберта и во многих других трактовках C, A и P приравниваются к желаемым свойствам реализации и фактически говорится «выберите два!». Однако это часто считается вводящей в заблуждение презентацией, поскольку вы не можете строить - или выбирать! - «Допуск на разделы»: в вашей системе либо могут быть разделы, либо нет.
CAP лучше понимать как описание компромиссов, которые вы должны сделать при построении системы, которая может иметь разделы. На практике это любая распределенная система: не бывает 100% надежной сети. Итак (по крайней мере, в распределенном контексте) реалистичной системы CA не существует. Вы потенциально можете столкнуться с разделами, поэтому в какой-то момент вам придется скомпрометировать C или A.
