Теорема CAP простыми словами

Распределение данных по множеству серверов обеспечивает масштабируемость, но создает головную боль, связанную с распределенными системами: узлы должны приходить к согласию, даже когда в сети случаются сбои. Здесь на помощь приходит теорема CAP.

CAP-теорема гласит, что распределенное хранилище может гарантировать выполнение только двух из трех условий: согласованности, доступности и устойчивости к разделению. Подвох в том, что разделения случаются всегда.

Согласованность означает, что каждое чтение видит последнюю запись из любого узла. Вы вносите деньги и проверяете баланс в любом банкомате — вы увидите обновленную сумму. Это надежно, но требует жертв в скорости.

Доступность означает, что на каждый запрос приходит ответ — без ошибок, даже если данные немного устарели. Корзина интернет-магазина, которая всегда позволяет добавить товары, сделала выбор в пользу этого принципа.

Разделение — это ситуация, когда узлы не могут общаться друг с другом, и в реальных сетях это неизбежно. Поэтому реальный выбор всегда сводится к согласованию (Consistency) или доступности (Availability) во время такого разделения.

CP-системы выбирают согласованность: в случае сетевого разделения они предпочтут вернуть ошибку, а не устаревшие данные. Это подходит для бухгалтерских книг и учета запасов, где цена неверных ответов слишком высока.

AP-системы выбирают доступность: они отвечают всегда, даже при наличии несколько устаревших данных, а затем синхронизируются позже. Идеально подходят для лент социальных сетей, отзывов и корзин покупок.

MongoDB по умолчанию является CP-системой. Только первичный узел принимает записи, поэтому во время разделения сети он на короткое время приостанавливает запись, чтобы избежать риска возникновения конфликтов. В коде показаны параметры чтения.

Согласованность в конечном счете означает, что узлы могут на короткое время расходиться в данных, но через некоторое время все операции чтения будут возвращать актуальные значения. Ничего не теряется — просто требуется небольшая задержка.

CAP охватывает только разделение сети (partition), которое случается редко. PACELC дополняет это повседневным компромиссом: даже при отсутствии разделения вы выбираете между низкой задержкой и строгой согласованностью.

CAP помогает проектировать с умом: будьте готовы к немного устаревшим данным, корректно обрабатывайте повторные попытки (retries) и выбирайте гарантию записи «большинство» (majority) для критически важных операций. Код показывает, как это сделать.

Вы узнали о CAP-теореме, почему устойчивость к разделению (partition tolerance) не подлежит обсуждению, и что MongoDB по умолчанию является CP-системой. Далее: где именно MongoDB подходит лучше всего.