Ответ
Partition Tolerance (P) — это свойство распределённой системы продолжать функционировать и обрабатывать запросы, несмотря на произошедший сетевой раздел (network partition), то есть потерю связи между некоторыми её узлами.
Контекст CAP-теоремы: Система может гарантировать только два из трёх свойств одновременно:
- C (Consistency) — согласованность: все узлы видят одни и те же данные в один момент времени.
- A (Availability) — доступность: каждый запрос получает ответ (успешный или ошибочный).
- P (Partition Tolerance) — устойчивость к разделению.
Практический выбор при разделе:
- CP-система (Consistency + Partition Tolerance): Жертвует доступностью (A). При разделе узлы, не способные гарантировать согласованность, перестают отвечать на запросы.
- Пример: ZooKeeper, etcd, традиционные RDBMS с репликацией.
- AP-система (Availability + Partition Tolerance): Жертвует строгой согласованностью (C). При разделе все узлы остаются доступными, но данные в разных сегментах могут расходиться (eventual consistency).
- Пример: Cassandra, DynamoDB, Riak.
Пример AP-подхода (Cassandra):
// Запись в Cassandra продолжится даже при сетевом разделе,
// но данные могут временно быть несогласованными между узлами.
session.execute(
"INSERT INTO users (user_id, name) VALUES (?, ?)",
userId, userName
);Важно: На практике P считается обязательным в распределённых системах, поэтому выбор сводится к CP vs AP.
Ответ 18+ 🔞
Да ты посмотри, какая интересная хуйня получается! Вот сидишь ты, такой весь из себя архитектор, проектируешь свою супер-систему, а тут бац — и сеть взяла и накрылась медным тазом. Одни сервера в одном дата-центре, другие — в другом, и они друг про друга нихуя не знают. Это и есть тот самый сетевой раздел (network partition), ёпта.
А Partition Tolerance (P) — это как раз про то, чтобы твоя система, даже когда её на части порвало, не легла и не сдохла, а продолжала как-то работать. Хоть и с приключениями.
Теперь вспоминаем эту самую CAP-теорему, про которую все так любят умничать. Говорит она, сука, простую вещь: ты можешь выбрать только два из трёх пунктов, как в столовой. Третий, блядь, всегда будет в жопе.
- C (Consistency) — Согласованность. Чтоб все узлы видели одно и то же. Записал данные — и на всех серваках они тут как тут.
- A (Availability) — Доступность. Чтоб на любой запрос был ответ. Даже если это ответ «иди нахуй», но был!
- P (Partition Tolerance) — Устойчивость к разделу. Чтоб при разрыве сети система не превращалась в тыкву.
И вот наступает этот самый пиздец — раздел. И система стоит перед выбором, как герой на распутье:
-
Выбрать CP (Consistency + Partition Tolerance). Жертвуем доступностью (A). Система такая: «Ребят, раз мы потеряли связь и не можем гарантировать, что данные у всех одинаковые — мы лучше вообще не будем отвечать, пока не починимся». Честно, но грустно. Пользователь стучится, а ему: «Занято, блядь, жди».
- Кто так делает: ZooKeeper, etcd. Ну и всякие занудные традиционные базы с репликацией, которые предпочтут умереть, но не солгать.
-
Выбрать AP (Availability + Partition Tolerance). Жертвуем строгой согласованностью (C). Тут философия другая: «Хуй с ним, с разделом! Главное — работать! Пиши и читай в любой узел, а данные мы как-нибудь потом между собой порешаем, может быть». Данные могут временно расходиться — это называется eventual consistency (согласованность в конечном счёте, то есть «когда-нибудь, наверное»).
- Кто так делает: Cassandra, DynamoDB. Ребята, которые считают, что лучше дать хоть какие-то данные, чем не дать никаких.
Вот, смотри, как в Кассандре это выглядит. Ей похуй на раздел, она пишет:
// Запись в Cassandra продолжится даже при сетевом разделе,
// но данные могут временно быть несогласованными между узлами.
session.execute(
"INSERT INTO users (user_id, name) VALUES (?, ?)",
userId, userName
);Записал и пошёл дальше. А что там у других узлов — это уже их личные проблемы, разберутся как-нибудь.
А самый главный прикол, который все забывают: в нашем ебучем мире, где сети рвутся чаще, чем мои носки, P (устойчивость к разделу) — это не выбор, а обязаловка. Поэтому на самом деле вся эта болтовня про CAP сводится к одному-единственному, ебать, вопросу: «Когда сеть накроется, что для тебя важнее — чтобы данные везде были одинаковые (CP) или чтобы система хоть что-то отвечала (AP)?».
Вот и вся магия, блядь. Выбирай, но помни — бесплатного сыра не бывает.