«Быстро, качественно, дёшево» — выберите любые два.
Теорема CAP звучит почти так же. В CAP говорится, что в распределенной системе можно выбрать только 2 из 3-х свойств:
🔤 (consistency) — согласованность. Каждое чтение даст вам самую последнюю запись.
🔤 (availability) — доступность. Каждый живой узел всегда успешно выполняет запросы (на чтение и запись).
🔤 (partition tolerance) — устойчивость к разделению. Даже если между узлами нет связи, система продолжает работать.
Однако потеря связи между узлами — это не что-то, что мы можем «выбрать» или «не выбрать». Распределенная система на то и распределенная, что ее узлы связаны по сети, а сети ненадежны, могут возникать “разрывы”. Поэтому распределенная система по-умолчанию «выбирает» partition tolerance.
Пока сеть работает исправно, система может обеспечить и согласованность и доступность. Все узлы будут отвечать и содержать актуальные данные. Тип системы определяется тем, какое свойство она выберет при возникновении сбоя в сети: согласованность или доступность.
Представим, что у нас есть два узла, оба выступают как лидеры и могут принимать запросы как на чтение, так и на запись.
Как должна вести себя наша система, если между узлами пропадет связь?
Если в этом случае оба узла перестанут принимать запросы на запись, чтобы данные на них не разъехались в отсутствии связи, то это CP-система.
✔️ Мы сохранили согласованность: каждый запрос на чтение возвращает актуальные данные (мы же запретили их менять по-отдельности 🤪, значит они остаются актуальными на обоих узлах).
✖️ Но при этом отказались от доступности: запросы на запись мы не выполняем.
Подходит, например, для систем, связанных с деньгами. Условно чтобы не потратили баланс дважды — по разу с каждого узла 🤨
Если же в случае потери связи оба узла продолжат принимать запросы как на чтение, так и на запись, то это AP-система.
✖️ Согласованность мы потеряли: оба узла запишут новые данные, которые не смогут пока сообщить друг другу.
✔️ Но сохранили доступность: все запросы обрабатываются успешно.
Подходит, например, для соцсетей. Пользователи первого узла не увидят свежих новостей от пользователей второго узла, но приложение по-прежнему будет показывать пользователям каждого узла имеющиеся посты, позволит создавать новые посты и ставить лайки 😘
👀 PACELC-теорема
Ее можно назвать расширением CAP-теоремы. Звучит она так:
Если присутствует
🔤 Partition Tolerance, то выбираем между
🔤 Availability и
🔤 Consistency (это как в CAP)
🔤 Иначе (else), когда нет сетевого сбоя, выбираем между
🔤 Latency (скорость ответа) и
🔤 Consistency.
😱 Google сломал CAP-теорему
В 2017 году Google выпустили в публичный доступ на своей платформе базу данных Google Spanner. Как они сами писали, в терминах CAP Spanner обеспечивает и согласованность и доступность, хотя является географически распределенной.
Секрет в том, что Spanner использует не этот наш ненадежный интернет, а внутреннюю сеть Гугла, в которой Гугл обещает отсутствие проблем. С оговоркой, что кабели всё же могут перерезать.
Если кабель перережут, то Spanner выберет согласованность, то есть технически это CP система.
Еще в Spanner интересно реализована синхронизация времени операций с помощью доверительных интервалов, но об этом в другой раз.