Ответ
Теорема CAP (Consistency, Availability, Partition Tolerance) — это фундаментальный принцип для распределенных систем, который гласит, что любая распределенная система может одновременно гарантировать только два из трех следующих свойств:
-
Consistency (Согласованность): Любое чтение возвращает самые актуальные данные (результат последней записи) или ошибку. Все узлы системы видят одни и те же данные в один и тот же момент времени.
-
Availability (Доступность): Любой запрос к системе получает корректный отклик (не ошибку), но без гарантии, что он содержит самые актуальные данные. Система всегда работоспособна.
-
Partition Tolerance (Устойчивость к разделению сети): Система продолжает функционировать, даже если связь между ее узлами (нодами) нарушена (произошел «разрыв сети»).
Практическое применение:
В реальных распределенных системах устойчивость к разделению сети (P) является обязательным требованием, так как сбои в сети неизбежны. Поэтому на практике выбор всегда стоит между согласованностью и доступностью:
-
CP (Consistency + Partition Tolerance): Система выбирает согласованность в ущерб доступности. При разрыве сети часть системы может стать недоступной для записи или даже для чтения, чтобы избежать риска отдать устаревшие данные.
- Примеры: MongoDB, Redis, etcd, CockroachDB.
-
AP (Availability + Partition Tolerance): Система выбирает доступность в ущерб согласованности. При разрыве сети все узлы остаются доступными, но некоторые из них могут возвращать устаревшие данные. Согласованность достигается позже (модель "eventual consistency").
- Примеры: Cassandra, CouchDB, Riak, Amazon DynamoDB.
-
CA (Consistency + Availability): Такая система не может быть распределенной. Этот выбор характерен для монолитных (одноузловых) баз данных, таких как PostgreSQL или MySQL в стандартной конфигурации.
Ответ 18+ 🔞
Ну вот, сидишь ты такой, проектируешь свою крутую распределённую систему, мечтаешь о бесконечной масштабируемости... И тут, блядь, вылезает эта ёбаная теорема CAP, как кирпич в ебальник, и нагло заявляет: "Нельзя всё сразу, мудила!".
Суть проста, как три рубля, но от этого не легче. Есть три штуки, а взять можно только две, как в столовой с гарниром. Выбирай, чё тебе дороже:
- Согласованность (Consistency). Это когда все узлы твоей системы поют с одного листа. Запросил данные — получил самые свежие, нихуя не устаревшие. Красота, да? Но за эту красоту придётся платить.
- Доступность (Availability). Это когда система всегда на связи, как дешёвая проститутка. Ткнул в неё — она сразу откликнулась. Правда, что она там тебе в ответ брякнула — хрен его знает, может, данные вчерашние. Но отвечает, сука, безотказно!
- Устойчивость к разделению (Partition Tolerance). А это, дружок, признание суровой правды жизни: сеть — она такая шлюха, она всегда может накрыться медным тазом. Ноды перестанут друг друга видеть, и это норма. Система должна это пережить.
И вот тут-то и начинается цирк. Потому что от устойчивости к разделению (P) на практике не отвертеться. Сети рвутся, это как закон подлости. Значит, выбор у тебя, по сути, хуёвый: либо CP, либо AP.
CP (Consistency + Partition Tolerance): Ты говоришь: "Согласованность — святое!". И тогда, когда сеть ложится, часть твоих серверов уходит в запой и становится недоступной, лишь бы не соврать. "Лучше молчать, чем пиздеть" — их девиз. Так живут, например, MongoDB или etcd. Надёжно, но если что-то пошло не так — хуй что получишь.
AP (Availability + Partition Tolerance): Ты кричишь: "Работать должно всегда, нахуй!". И твоя система, даже когда её разорвало на куски, продолжает улыбаться и что-то отвечать всем подряд. Правда, один узел может тебе сказать, что у тебя на счету миллион, а другой — что долг в три копейки. Потом, конечно, они между собой пошушукаются и договорятся (это называется eventual consistency), но момент ебалы ты уже получил. Такой путь выбрали Cassandra или DynamoDB.
А CA (Consistency + Availability) — это, извини, сказки для наивных. Это удел одиноких, нераспределённых баз вроде PostgreSQL на одном сервере. Пока с ним всё хорошо — он и согласованный, и доступный. Но тронь его сетевой интерфейс — и всё, пиздец этому благополучию. Не жилец он в суровом мире распределёнки.
Короче, проектируя систему, сразу решай: что для тебя страшнее — на время потерять часть данных или на время потерять часть сервиса? И не ори потом, что тебя не предупреждали.