Изучение мира распределенных систем: теорема PACELC или почему CAP недостаточно
29 апреля 2023 г.Важное примечание. Эта статья во многом опирается на предыдущую статью о теореме CAP. Я не буду освещать затронутые там темы и моменты, поэтому, если вы мало что знаете о теореме CAP, я настоятельно рекомендую начать с этой статьи: https://hackernoon.com/exploring-the-world-of-distributed-systems-a-beginners -руководство к теореме о шапке
Предисловие
Как вы помните, теорема CAP была изобретена и введена еще в 2000 году, то есть относительно давно, и она повлияла на то, как разработчики начали подходить к ограничениям проектирования распределенных систем и справляться с ними.
Тем не менее может показаться, что CAP-теорема расставила все по своим местам, но возник ряд вопросов.
Во-первых, теорема CAP в основном охватывает случай, когда система разделена; в этом случае для продолжения работы он может быть либо доступным, либо непротиворечивым. Но что происходит, когда разделения нет? Является ли он последовательным и доступным?
Это поднимает второй вопрос; что на самом деле является «доступной» системой? Если он ответил, скажем, через 10 минут, доступен ли он?
Все эти моменты привели к мысли, что теоремы CAP недостаточно, а необходимо дополнить ограничения и наборы правил.
Необходимые определения
Задержка
С общей точки зрения латентность – это временная задержка между причиной и следствием наблюдаемого физического изменения в системе. (Википедия)
Это определение может быть слишком абстрактным и не очень практичным, поэтому в нашем случае, когда нас интересует какая-то распределенная система (например, какая-то многоузловая база данных), задержка будет временным интервалом между моментом отправки запроса и моментом получаем соответствующий ответ.
Под капотом он также состоит из нескольких дополнительных задержек, таких как задержка сети, задержка запроса и т. д.
Последовательность
Тем не менее, в предыдущей статье мы уже рассмотрели определение согласованности; нам нужно рассмотреть его поближе. Это связано с тем, что существует несколько типов согласованности: строгая согласованность и конечная согласованность.
В теореме CAP буква C означает сильную согласованность, которую мы полностью рассмотрели в этой статье, но что такое конечная согласованность?
Возможная согласованность означает гарантию того, что операция записи в конечном итоге вступит в силу для всех узлов в кластере, если система будет работать достаточно долго. Например, есть кластер из трех узлов: 1, 2 и 3. Пользователь вызывает узел 1 для выполнения операции записи.
В этом случае окончательная согласованность будет гарантией того, что в какой-то момент времени оба узла 2 и 3 также получат эти обновления записи.
Это означает две вещи:
- Возможны временные рамки, когда вызов чтения узлов 1, 2 и 3 может возвращать разные данные.
2. В конце концов, гарантируется, что 1, 2 и 3 вернут одни и те же данные при соответствующем вызове чтения (в случае, если до этого не будет выполняться новая запись).
Репликация данных
Мы уже упоминали идею о том, что распределенная система (база данных, согласно предыдущим примерам) должна распространять обновление на отдельные узлы, что делает эти данные реплицированными на разные узлы.
Это может потребоваться для распределения нагрузки чтения на разные узлы из-за объема трафика. Другие варианты использования также могут быть связаны с требованием размещать узлы физически ближе к конечным пользователям (тот же континент/страна/регион/город и т. д.), поэтому для достижения этого узла по сети потребуется меньше времени.
Кроме того, имеет смысл иметь несколько узлов для повышения надежности, что будет охватывать случаи, когда физическая машина/серверная стойка или центр обработки данных становятся недоступными из-за какой-либо неисправности. Позже мы рассмотрим примеры того, как такая репликация может происходить.
ПАСЕЛЦ
Во-первых, нам нужно начать с правильного произношения — «пасс-элк» (из-за официальной статьи ссылка).
Идея теоремы PACELC состоит в том, чтобы расширить теорему CAP, заявив, что если система в настоящее время находится в разделе (P), она приходится выбирать между доступностью (A) и согласованностью (C); В противном случае (E), если в данный момент в системе нет разделов, она должна выбрать компромисс между задержкой (L) и согласованностью (C). >).
Как я упоминал в начале статьи, мы не будем рассматривать часть PAC (которая по сути является теоремой CAP), а сосредоточимся на ELC. Давайте попробуем понять, почему необходим такой компромисс, рассмотрев несколько конкретных примеров.
Допустим, наша БД имеет три узла: 1, 2, и 3. Узел 1 является основным узлом, который принимает все запросы на запись, а узлы 2 и 3 являются вторичными узлами, что означает, что они принимают только запросы на чтение. .
Как мы помним, проблем с соединением между узлами нет; мы можем создать соединение между любым узлом, и все будет работать «нормально». Это приводит нас к вопросу о том, как именно выполнить запрос на запись.
Это может быть неочевидно, но в нашем случае у нас есть несколько вариантов выполнения записи, давайте проверим некоторые из них.
Настройка низкой задержки
Когда узел 1 принимает запрос на запись, он отвечает успешным ответом, после чего локально применяет эти изменения. После ответа узел 1 передаст эти изменения узлам 2 и 3.
Это делает эту настройку согласованной в конечном счете и делает ее наименее согласованной и наиболее эффективной в отношении задержки.
Наиболее последовательная настройка
Узел 1 принимает запрос на запись, применяет его локально, передает узлам 2 и 3 и только после этого отвечает успех. Как вы можете себе представить, эта настройка строго согласована и имеет самую большую задержку.
Гибридная установка
Есть также гибридная установка. Когда узел 1 примет запрос на запись, он применит это изменение локально, передаст это обновление узлу 2, ответит успешно и только после этого обновит узел < сильный>3.
Это сделает систему менее стабильной, чем в первом случае, но и задержка будет относительно меньше, чем во втором случае.
Я хотел бы остановиться более конкретно на этом случае. Кажется, что эта настройка является «золотой серединой», потому что мы идем на некий компромисс между согласованностью и задержкой. Однако есть ли способ сделать те же настройки еще более стабильными для операций чтения?
На самом деле, есть один подход, который мы еще не рассмотрели, пока не упомянули, как мы можем скорректировать показания. В этой настройке, после успешного ответа, 2 наши ноды будут иметь последние обновления, а 1 какое-то время будет устаревшей.
Это означает, что пользователи, которые будут переданы балансировщиком нагрузки на этот устаревший узел, не будут получать последние данные. А что, если запросы на чтение передаются не только на один узел, но и на два узла? Это фактически гарантирует, что пользователи смогут получать самые свежие данные.
Конечно, задача разобраться, какие данные самые свежие, — это отдельная задача и, собственно, тема для отдельной статьи, но физически ничто не мешает нам это сделать.
Глядя на этот пример, мы можем даже вывести следующую простую формулу. Дадим следующие определения:
R – количество узлов, до которых будет доходить вызов чтения.
W — количество узлов, к которым будет применена запись, прежде чем ответ будет успешным.
N — общее количество узлов в кластере.
Если R + W > N, то у нас есть гарантия, что чтения будут строго согласованными; если R + W <= N некоторая часть запросов на чтение не сможет прочитать последние данные.
Это также показывает нам, что мы можем контролировать не только задержку в целом, но и балансировать между read & задержку записи, изменив значение R и W.
Это, очевидно, не полный список возможных способов репликации данных, а те, что упоминались однажды, гораздо сложнее внутри.
Но общая идея, которая нас интересует, на самом деле является демонстрацией того факта, что так или иначе мы должны выбирать между степенью согласованности и задержкой.
Заключение
Тем не менее, теорема CAP долгое время казалась достаточным способом понять ограничения, связанные с проектированием распределенных систем; со временем стало очевидно, что этого недостаточно.
Чтобы также охватить ограничения, в неразделенном состоянии системы теорема PACELC была построена поверх теоремы CAP. Как мы рассмотрели в этой статье, мы должны выбрать баланс между задержкой и усилителем; непротиворечивость нашей системы.
Кроме того, мы увидели, что есть способ сбалансировать не только общую задержку, но и чтение & задержка записи. Все эти различные настройки имеют свои собственные варианты использования и механизмы, которые необходимо реализовать, о которых я расскажу в своей следующей статье. Оставайтесь с нами!
Оригинал