Теоремы CAP и PACELC — ограничения в распределённых системах

Распределённые системы — это набор независимых серверов, взаимодействующих через сеть для достижения общей цели. Они используются в основе практически всех популярных современных сервисов. Однако проектирование таких систем сопряжено с неизбежными компромиссами, которые описывают теоремы CAP и PACELC.

CAP‑теорема

CAP‑теорема утверждает, что в системе можно одновременно обеспечить не более двух из трёх свойств:

  • Согласованность (Consistency)
  • Доступность (Availability)
  • Устойчивость к разделению (Partition Tolerance)

Типы систем по CAP‑теореме

CP‑системы (Consistency + Partition Tolerance) — жертвуют доступностью ради согласованности, применяются там, где критична точность данных (например, в финансовой сфере).

AP‑системы (Availability + Partition Tolerance) — жертвуют согласованностью ради доступности, применяются там, где временная несогласованность данных вполне допустима (например, в развлекательной сфере).

CA‑системы (Consistency + Availability) — возможны только при исключении возможности сетевого разделения, то это системы, которые не являются распределёнными.

Распределённые системы по определению должны быть устойчивы к возможному разделению — исключить сетевые сбои невозможно, поэтому при разрывах связи между узлами эти системы должны продолжать работать, пусть и с ожидаемыми ограничениями.

Согласованность или доступность при сетевых сбоях

Трактовка CAP‑теоремы для распределённых систем формулируется в следующем виде: при возникновении сетевого разделения распределённая система может гарантировать либо согласованность (C+P), либо доступность (A+P).

Важно понимать, что этот компромисс актуален только при сетевом разделении, а в нормальных условиях работы (без сетевых сбоев) распределённая система вполне может одновременно обеспечивать и согласованность, и доступность.

Однако, всё несколько сложнее — обеспечение согласованности в условиях штатной работы (при отсутствии сетевых разделений) всё же требует дополнительного компромисса в быстродействии, который не следует из CAP‑теоремы, но вполне объясняется теоремой PACELC.

PACELC‑теорема

Теорема PACELC является логическим развитием CAP‑теоремы и устраняет её ключевое ограничение — игнорирование компромиссов в условиях отсутствия сетевых разделений. Первые 3 буквы в аббревиатуре PACELC идентичны по значению CAP (их порядок просто другой), а вот следующие 3 буквы (ELC) добавляют ещё один аспект: в нормальных условиях (E, Else) выбор между низкими задержками (L, Latency) и согласованностью (C, Consistency).

PAC: Partition → Availability (A) OR Consistency (C) — в условиях разделения выбираем или доступность, или согласованность.

ELC: Else → [Low] Latency (L) OR Consistency (C) — в штатном режиме выбираем или согласованность, или высокую скорость работы (снижение задержек).

Если рассматривать в качестве примера репликацию в СУБД, то высокая согласованность потребует синхронной репликации, что увеличит задержки; а применение асинхронной репликации снизит задержки, но допустит временную несогласованность.

Eventual Consistency

На самом деле, когда при сбоях мы жертвуем согласованностью ради доступности (AP-системы) или когда в штатном режим выбираем низкие задержки в ущерб согласованности, то мы вовсе не должны терять согласованность полностью и навсегда. Мы не имеем гарантии постоянной согласованности, но вполне можем получить согласованность «в конечном счёте» (Eventual Consistency) — согласованность в случае разделения настанет после устранения сбоя, а в случае штатной работы с низкими задержками — просто через какое‑то время.

Зачем нужны теоремы CAP и PACELC?

Это теоремы стоит воспринимать как руководство для проектировщиков распределённых систем. Понимание компромиссов позволяет выбирать оптимальную архитектуру, создавая распределённые системы, адаптирующиеся не только к сбоям, но и к повседневным нагрузкам.

Тематические статьи

Масштабирование баз данных — партиционирование, репликация и шардирование

СУБД — это очень часто «узкое место» в производительности веб‑приложений. В момент, когда сервер баз данных не может справится с нагрузками, производится масштабирование. В современных высоконагруженных системах эффективное управление данными невозможно без использования методов масштабирования и обеспечения отказоустойчивости. Репликация, партиционирование и шардирование — ключевые подходы, которые позволяют распределять данные, повышать производительность и гарантировать доступность. Разберем каждый из них подробно.

Статья обновлена в 2025 году
Реляционные базы данных и NoSQL‑хранилища

Базы данных служат для хранения и обработки данных. Бывают реляционные (SQL) и нереляционные (NoSQL) системы управления базами данных. Реляционные системы управления базами данных (SQL) хранят данные в таблицах и наиболее часто используются в качестве основного хранилища для веб‑приложений. Они очень стабильны и их надёжность проверена временем. Нереляционные СУБД (NoSQL) заметно отличаются по структуре хранения данных и работе с ними. Большинство нереляционных хранилищ превосходят классические SQL СУБД по скорости доступа или при работе со специфическими типами данных, но обычно эта скорость достигается за счёт снижения надёжности хранения.

Статья обновлена в 2021 году
PostgreSQL — система управления базами данных

PostgreSQL — это популярная объектно-реляционная система управления базами данных. PostgreSQL базируется на языке SQL, отличается высокой надёжность и имеет широкие возможности. В PostgreSQL нет ограничений на максимальный размер базы данных, количество записей и индексов таблицах. В СУБД встроены мощные и надёжные механизмы транзакций, есть возможности для репликации, шардинга и партиционирования. СУБД отличает легкая расширяемость и возможность тонкой настройки.

Статья обновлена в 2025 году
MySQL — система управления базами данных

MySQL — это реляционная система управления базами данных с открытым исходным кодом. В настоящее время эта СУБД одна из наиболее популярных в веб‑приложениях — подавляющее большинство CMS использует именно MySQL (часто только её, без альтернатив), а почти все веб‑фреймворки поддерживают MySQL уже на уровне базовой конфигурации (без дополнительных модулей).

Статья опубликована в 2014 году
MariaDB — система управления реляционными базами данных

MariaDB — ответвление реляционной СУБД MySQL, разрабатываемое сообществом под лицензией GPL. MariaDB полностью совместима с приложениями, использующими MySQL, а переход на эту СУБД оправдан тем, что MySQL уже не так активно развивается.

Статья опубликована в 2014 году
MongoDB — документо-ориентированная база данных (NoSQL)

MongoDB — это NoSQL хранилище данных, крайне удобное для хранения информации, которая не может быть нормально структурирована в рамках реляционных баз данных. MongoDB — это СУБД с открытым исходным кодом, не требующая описания схемы таблиц. Документы в MongoDB хранятся в JSON или BSON, работа с такой моделью проще кодируется и проще управляется, а внутренняя группировка релевантных данных обеспечивает дополнительный выигрыш в быстродействии.

Статья опубликована в 2019 году