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