CAP-теорема: Простое объяснение, примеры и ограничения
Автор — Владимир Балун
ex-TeamLead в Яндекс
Проектирование распределенной системы — это всегда игра компромиссов. Архитектор или разработчик сталкивается с необходимостью выбирать между согласованностью данных (C), доступностью сервисов (A) и устойчивостью к сетевым разделениям (P).
Опыт, знание технологий и понимание реальных нагрузок помогают принимать эти решения: где-то приходится жертвовать мгновенной доступностью ради строгой консистентности, где-то — наоборот, обеспечивать работу системы даже при частичных сбоях, позволяя данным временно расходиться между собой.
Опыт, знание технологий и понимание реальных нагрузок помогают принимать эти решения: где-то приходится жертвовать мгновенной доступностью ради строгой консистентности, где-то — наоборот, обеспечивать работу системы даже при частичных сбоях, позволяя данным временно расходиться между собой.
1. Что означает CAP-теорема
CAP-теорема — это утверждение о компромиссах в распределенных системах.
Впервые она была сформулирована Эриком Брюером в 2000 году, а затем формально доказана Сетом Гилбертом и Нэнси Линч в 2002 году.
Впервые она была сформулирована Эриком Брюером в 2000 году, а затем формально доказана Сетом Гилбертом и Нэнси Линч в 2002 году.
Что означает CAP-теорема: в распределенной системе невозможно одновременно обеспечить три свойства — согласованность, доступность и устойчивость к сетевым разделениям. Можно выбрать только два из трёх.
Поясню CAP-теорему простыми словами: представьте базу данных, работающую на нескольких серверах с репликацией данных между ними. Если между серверами пропадает связь, и система сталкивается с выбором:
- продолжать отвечать на запросы и рисковать рассинхронизацией данных, ведь пользователи будут продолжать добавлять данные в разные узлы без синхронизации этих узлов между собой;
- или приостановить работу, чтобы сохранить строгую согласованность и отвечать пользователям например ошибкой при добавлении новых данных, чтобы данные в узлах базы данных были согласованными.
Одновременно сделать и то, и другое невозможно.
2. Три свойства: Consistency (C), Availability (A), Partition Tolerance (P)
1
Согласованность (Consistency)
Согласованность означает, что данные во всех узлах системы остаются одинаковыми после выполнения изменяемой операции.
После успешной записи любой клиент, обратившийся к любой реплике, должен увидеть одно и то же значение. Другими словами, Когда мы, например, производим запись в любую из реплик и мгновенно идем в другую реплику, то должны получить добавленные данные.
Это и означает строгую согласованность, когда данные во всех узлах одинаковые. Она достигается за счет синхронной репликации: когда вы сделаете запись в один узел, то она не передается клиенту в статусе подтвержденной до тех пор, пока другие синхронные реплики не подтвердят эту запись. Подтверждение операции клиенту происходит только после того, как данные были записаны во все необходимые узлы.
Это и означает строгую согласованность, когда данные во всех узлах одинаковые. Она достигается за счет синхронной репликации: когда вы сделаете запись в один узел, то она не передается клиенту в статусе подтвержденной до тех пор, пока другие синхронные реплики не подтвердят эту запись. Подтверждение операции клиенту происходит только после того, как данные были записаны во все необходимые узлы.
2
Доступность (Availability)
Доступность означает, что любой запрос к узлу базы данных завершается откликом, однако без гарантии, что ответы всех узлов базы данных совпадают.
Если нода доступна, то значит, что она отвечает корректно за какое-то приемлемое время.
Доступная система — это система, которая продолжает отвечать на запросы пользователей, даже если часть инфраструктуры испытывает проблемы.
Доступная система — это система, которая продолжает отвечать на запросы пользователей, даже если часть инфраструктуры испытывает проблемы.
3
Устойчивость к разделению (Partition Tolerance)
Устойчивость к разделению означает способность системы продолжать работу при потере связи между узлами.
Представим, что у вас есть несколько реплик и между ними происходит обрыв сети. Такая ситуация может возникнуть по разным причинам, например, реплики находятся в разных дата-центрах, между дата-центрами проехал экскаватор и перерезал кабель. Либо обе реплики находятся в одном дата-центре, но между ними потерялась сетевая связность.
Устойчивость к разделению гласит, что система должна продолжать работать, несмотря на отсутствие связности между этими репликами.
Представим, что у вас есть несколько реплик и между ними происходит обрыв сети. Такая ситуация может возникнуть по разным причинам, например, реплики находятся в разных дата-центрах, между дата-центрами проехал экскаватор и перерезал кабель. Либо обе реплики находятся в одном дата-центре, но между ними потерялась сетевая связность.
Устойчивость к разделению гласит, что система должна продолжать работать, несмотря на отсутствие связности между этими репликами.
При этом важно понимать, что сетевые разделения — это нормальная часть работы распределенных систем. Наш мир не идеален, и мы не можем полагаться на то, что сеть будет всегда работать идеально. Поэтому устойчивость к разделению, или «P» должна быть в системе всегда.
3. Можно ли получить всё сразу (C, A, P)?
CAP-теорема утверждает, что в распределённой системе невозможно одновременно обеспечить все три свойства.
Если происходит сетевое разделение, система вынуждена выбирать:
- либо сохранять согласованность, блокируя часть операций;
- либо сохранять доступность, не блокирую операция, но позволяя данным временно расходиться.
Именно этот компромисс лежит в основе архитектуры большинства распределённых систем.
Треугольник показывает невозможность одновременного достижения всех трех свойств.
Когда происходит сетевое разделение, система должна выбрать между доступностью и согласованностью. Поэтому на практике возникают две основные архитектурные конфигурации.
Когда происходит сетевое разделение, система должна выбрать между доступностью и согласованностью. Поэтому на практике возникают две основные архитектурные конфигурации.
4. Двойные системы
1
CP-системы (Consistency + Partition tolerance)
CP-система сохраняет согласованность, но жертвует доступностью. В этом случае чтение из узлов может быть разрешено, но запись блокируется.
Если бы запись была разрешена, она могла бы попасть только в один из сегментов кластера. Из-за отсутствия связи между узлами данные не синхронизировались бы, и строгая согласованность была бы нарушена.
Если бы запись была разрешена, она могла бы попасть только в один из сегментов кластера. Из-за отсутствия связи между узлами данные не синхронизировались бы, и строгая согласованность была бы нарушена.
Поэтому система запрещает запись, и в результате:
- данные остаются одинаковыми во всех узлах;
- система становится недоступной для операций записи.
Таким образом, система сохраняет Consistency и Partition Tolerance, но теряет Availability.
2
AP-системы (Availability + Partition tolerance)
Такая система, наоборот, сохраняет доступность, но жертвует строгой согласованностью. В этом случае операции записи разрешены даже при сетевом разделении.
Если запись выполняется в разные сегменты кластера, данные между ними не синхронизируются, поскольку связь между узлами отсутствует.
Если запись выполняется в разные сегменты кластера, данные между ними не синхронизируются, поскольку связь между узлами отсутствует.
В результате данные на разных узлах могут различаться. Таким образом:
- система продолжает принимать чтения и записи;
- строгая согласованность временно нарушается.
5. CAP-теорема на практике
Теперь посмотрим, как теорема CAP проявляется в популярных системах.
1
MongoDB как пример модели CP
MongoDB в классической конфигурации Replica Set обычно относят к CP-системам. Если происходит сетевое разделение, MongoDB старается сохранить согласованность данных. В результате система сохраняет согласованность данных, но может временно потерять доступность для записи.
Поэтому в условиях сетевого разделения MongoDB жертвует Availability, чтобы сохранить Consistency, что соответствует модели CP.
Поэтому в условиях сетевого разделения MongoDB жертвует Availability, чтобы сохранить Consistency, что соответствует модели CP.
2
Cassandra — классический пример AP-системы
Apache Cassandra считается примером AP-системы благодаря своей masterless-архитектуре. Если происходит сетевое разделение, каждая часть кластера продолжает обслуживать запросы пользователей. Узлы продолжают принимать операции чтения и записи, даже если они временно не могут синхронизироваться с другими сегментами системы.
Это означает, что система сохраняет доступность, но данные могут временно расходиться между узлами. Таким образом, Cassandra предпочитает Availability и Partition Tolerance, допуская временную рассинхронизацию данных, что соответствует модели AP.
Это означает, что система сохраняет доступность, но данные могут временно расходиться между узлами. Таким образом, Cassandra предпочитает Availability и Partition Tolerance, допуская временную рассинхронизацию данных, что соответствует модели AP.
6. Проблемы и ограничения CAP
CAP-теорема полезна прежде всего как модель для размышления о компромиссах в распределённых системах, а не как строгая классификация архитектур. В реальных системах компромиссы обычно сложнее, чем выбор между CP и AP, поэтому CAP служит скорее концептуальным ориентиром, чем точным инструментом описания архитектуры.
Поэтому сейчас выделяют расширение CAP-теоремы — PACELC.
Поэтому сейчас выделяют расширение CAP-теоремы — PACELC.
7. PACELC как расширение CAP-теоремы
Позже появилось расширение CAP-теоремы — PACELC. Оно формулируется следующим образом:
- If Partition (P) — система выбирает между Consistency (C) и Availability (A);
- Else (E) — система выбирает между Consistency (C) и Latency (L).
Это означает, что даже если сетевого разделения нет, система всё равно вынуждена выбирать между задержками и согласованностью данных.
Причина в том, что разные модели репликации дают разные свойства:
- синхронная репликация обеспечивает строгую согласованность, но увеличивает задержки;
- асинхронная репликация быстрее работает, но допускает временную рассинхронизацию данных.
Таким образом, компромиссы в распределённых системах возникают даже в нормальном режиме работы, а не только во время сетевых сбоев.
Приведу пример: представим систему с несколькими дата-центрами
Если в них используется синхронная репликация, то при записи данных система должна дождаться подтверждения от всех реплик. Например, пользователь добавляет товар в корзину, и запись должна подтвердиться сразу в нескольких дата-центрах. Это гарантирует строгую согласованность данных, но увеличивает время ответа, потому что системе нужно дождаться подтверждений.
Если же используется асинхронная репликация, запись подтверждается сразу после сохранения в локальном узле, а на другие узлы она распространяется позже. Пользователь получает быстрый ответ, но в течение некоторого времени разные дата-центры могут содержать разные версии данных.
Таким образом, даже при полностью исправной сети система всё равно выбирает между задержкой ответа (Latency) и строгой согласованностью (Consistency). Именно это наблюдение и отражает модель PACELC, делая её более практичной для анализа архитектуры распределенных систем.
8. Заключение
При проектировании распределенных систем важно чётко понимать, какие свойства системы можно осознанно пожертвовать, а какие должны оставаться приоритетными. Если критична согласованность данных, придётся смириться с временной недоступностью сервиса. CAP-теорема помогает осознать эти неизбежные компромиссы и строить архитектуру с учетом реальных требований к системе.
еще про system design
Другие статьи