Теория CAP — это тема, о которой говорили и слышали плохо, но я все же предпочитаю потратить некоторое время на ее разбор, горизонтальное расширение, добавление своих собственных чувств и серьезное обсуждение.
увидеть раньшеСтатья написана учителем Руань Ифэн.Да, раньше я думал, что это всегда было немного сложно понять, но теперь я думаю, что это немного проблематично.
Я думаю, что доступность, которую сказал г-н Руан, не правильно понимается, и распределение не имеет ничего общего с конкретным «каким». Объяснение терпимости разбиения не заставило меня осознать.
Введение в CAP
В 1998 году приятель предложил три индикатора распределенных систем:
CAP (согласованность, доступность, допуск к разделению), где:
Consistency
- последовательность
Этот приятель сказал, что все резервные копии данных в распределенной системе должны быть «одинаковыми» в «один и тот же момент».
Например, на фиг. Служба отключения. Запрос Там не может упасть на А, потом он сказал: независимо от падения B, C на какую машину картина должна присутствовать и вернуть ее, в противном случае это не «последовательно»
Если имеется несколько разделов для выполнения операций записи, если синхронизация «осколка» распределенной системы хранения или синхронизация «главный-подчиненный» кластерной системы всегда будет иметь последовательность, в этой последовательности возникнут несоответствия. :
-
Либо принять «временные» несоответствия в синхронизации одних и тех же данных между точками хранения.
-
Либо вы хотите «строгую согласованность», тогда синхронизация повлияет на вашу «доступность».
Организован общий уровень согласованности, можете посмотреть, если хотите его увидеть
Availability
- Доступность
Этот приятель сказал: После отказа некоторых узлов в кластере, может ли кластер в целом отвечать на запросы клиента на чтение и запись, даже если узел в кластере выйдет из строя, это все равно не повлияет ни на один из ваших запросов.
Это очень легко понять, буквально
Partition tolerance
- Допуск перегородки
Этот товарищ сказал: Если машины в кластере разделены на две части и две части не могут общаться друг с другом, может ли система продолжать нормально работать?
Буква P в этом CAP больше всего вводит меня в заблуждение, так что я до сих пор не могу говорить о CAP сегодня, поэтому здесь я организую причины.
Мои вопросы о толерантности к зонированию
Многие говорят «непротиворечивость, доступность, устойчивость к разбиению, только два из них могут быть выбраны произвольно», что на первый взгляд верно, но удовлетворяет ли AC?
Обычно это написано оригинальными словами «Энциклопедии Baidu»:
CAP原则的精髓就是要么AP，要么CP，要么AC，但是不存在CAP。
Мой вопрос: если AC гарантировано, то P не может гарантировать, Только подумайте: если между машинами нет связи, а сеть разбита на разделы, как обеспечить согласованность данных? Как синхронизировать данные?
Я могу понять AP CP, и я могу видеть тени в своей повседневной работе:
Например, AP (Eureka) выбирает доступность, а CP (Zookeeper, HDFS) выбирает согласованность, но где модель AC? Как это сделать без потери связи?
Некоторые говорят: Автор теории CAP слишком догматичен! Пока распределенные машины в разных местах поддерживают порядок, а машины, которые не могут общаться, выгоняются, это CAP!
Другой человек сказал: Это нехорошо, если сеть дергается, вы слишком сильно пинаетесь, а фрагментация данных не соответствует требованиям!
Ссылки 👇
исходный текст cloudera facebook (истек срок действия исходного текста официального сайта cloudera)
Обратитесь к приведенному выше переводу
Автор имеет в виду, что только CP или AP могут изолировать членов системы на две области из-за сетевых проблем, и друг друга не могут знать о состоянии друг друга, что очень часто встречается в распределенной среде. Таким образом, мы можем выбрать только один из C и A. Так что P обязателен. Для распределенных систем нецелесообразно строить сеть, которая никогда не дает сбоев при множественных корреляциях. Таким образом, разработчик должен выбирать между согласованностью (C) и доступностью (A).
Конечно, все вышеизложенное — догматические рассуждения, основанные на теории CAP, на самом деле незачем так запутываться в реальности.
Суммировать
В распределенной среде P определенно существует, то есть, пока у нас есть несколько машин, сетевая изоляция и разделение должны быть неизбежны, поэтому при проектировании системы мы должны выбрать, разрабатывать ли систему AP или систему CP. на самом деле, пока у нас есть глубокое понимание CAP, мы обнаружим, что иногда нет необходимости так запутываться в проектировании системы, в основном в:
Хотя вероятность раздела сети существует на рынке, мы можем воспринимать сердцебиение, чтобы принудительно исключить офлайн и распределить трафик равномерно по другим узлам, ведь никто не может гарантировать, что сеть будет на 100% стабильна и не будет никакого раздела сети. Естественно, нет необходимости сознательно выбирать что-то одно из A и C, но вы можете хорошо делать и то, и другое. То есть система переменного тока, упомянутая в «Энциклопедии Baidu».
В CAP прописано, что А - это 100% доступность, но по факту нам нужно обеспечить только высокую доступность, то есть, как и шлюз, круглый год быть неработоспособным нельзя, а достаточно для выполнения 99,99% или 99,999% и другие 9s.
награда
У меня есть дальнейшая концепция Р CAP, и у меня есть некоторые новые понимания. Я снова читаю Paxos. Это действительно сложно. Я хотел написать это, но я плохо понимаю, и я боюсь, что я не пишите хорошо.
Скажи это в следующий раз.
использованная литература
Учитель Жуань Ифэн:Уууу. Руань Ифэн.com/blog/2018/0…
кепка облачера:Обычные - такие как. Facebook.com / Notes / Cloud ...
облачная шапка перевод:Очень внимательно GitHub.IO/blogs/cap - From…
Общие уровни согласованности:GitHub.com/Вопросы и ответы в сторону/B…