Что такое теорема CAP и как ее расширяет PACELC?

В распределенных системах могут возникать различные типы сбоев, например, серверы могут выйти из строя или выйти из строя навсегда, диски могут выйти из строя, что приведет к потере данных, или сетевое соединение может быть потеряно, что сделает часть системы недоступной. Как можно смоделировать распределенную систему, чтобы получить максимальную выгоду от различных доступных ресурсов? Какие руководящие принципы помогают распределенным системам выбрать желаемый баланс между различными распределенными характеристиками?

Отметьте Проведение собеседования по проектированию системы, чтобы узнать о важных концепциях распределенных систем.

Теорема CAP спешит на помощь

Теорема CAP утверждает, что для распределенной системы невозможно одновременно обеспечить все три из следующих желаемых свойств:

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

Доступность (A): Доступность означает, что каждый запрос, полученный исправным узлом в системе, должен приводить к ответу. Даже при серьезных сбоях сети все запросы должны завершаться. Проще говоря, доступность означает способность системы оставаться доступной, даже если один или несколько узлов в системе выходят из строя.

Допуск на разделение (P): раздел - это разрыв связи (или сетевой сбой) между любыми двумя узлами в системе, т. е. оба узла работают, но не могут связываться друг с другом. Система, терпимая к разделам, продолжает работать, даже если в системе есть разделы. Такая система может выдержать любой сетевой сбой, который не приведет к отказу всей сети. Данные достаточно реплицируются между комбинациями узлов и сетей, чтобы поддерживать систему в рабочем состоянии при периодических отключениях.

Согласно теореме CAP, любая распределенная система должна выбрать два из трех свойств. Три варианта: CA, CP и AP. Однако CA на самом деле не является согласованным вариантом, поскольку система, не терпимая к разделам, будет вынуждена отказаться от согласованности или доступности в случае сетевого раздела. Следовательно, теорема действительно может быть сформулирована следующим образом: При наличии сетевого раздела распределенная система должна выбрать либо согласованность, либо доступность.

Обоснование теоремы CAP

Мы не можем создать общее хранилище данных, которое было бы постоянно доступным, последовательно согласованным и устойчивым к любым сбоям разделов. Мы можем построить систему только с любыми двумя из этих трех свойств. Потому что для согласованности все узлы должны видеть один и тот же набор обновлений в одном порядке. Но если сеть теряет раздел, обновления в одном разделе могут не попасть в другие разделы до того, как клиент выполнит чтение из устаревшего раздела после чтения из последнего. Единственное, что можно сделать, чтобы справиться с этой возможностью, - это прекратить обслуживание запросов из устаревшего раздела, но тогда услуга становится недоступной на 100%.

Чего не хватает в теореме CAP?

Мы не можем избежать разделения в распределенной системе; следовательно, как указано выше, согласно теореме CAP, распределенная система должна выбирать между согласованностью или доступностью. Базы данных ACID (атомарность, согласованность, изоляция, надежность), такие как СУБД, такие как MySQL, Oracle и Microsoft SQL Server, выберите согласованность (откажитесь от ответа, если он не может проверить с одноранговыми узлами). Напротив, базы данных BASE (в основном доступные, с мягким состоянием, согласованные в конечном итоге), такие как базы данных NoSQL, такие как MongoDB, Cassandra и Redis, выберите доступность (ответьте локальными данными, не проверяя, чтобы они были самыми последними для своих сверстников).

Одно место, где умалчивается теорема CAP, - это то, что происходит, когда нет сетевого раздела? Какие варианты есть у распределенной системы, когда нет раздела?

Теорема PACELC спешит на помощь

Теорема PACELC утверждает, что в системе, которая реплицирует данные:

  • если есть раздел («P»), распределенная система может выбирать между доступностью и согласованностью (то есть «A» и «C»);
  • else («E»), когда система работает нормально при отсутствии разделов, система может найти компромисс между задержкой («L») и согласованностью («C»).

Первая часть теоремы (PAC) совпадает с теоремой CAP, а ELC является расширением. Весь тезис предполагает, что мы поддерживаем высокую доступность путем репликации. Итак, когда происходит сбой, преобладает теорема CAP. Но если нет, мы все равно должны рассмотреть компромисс между согласованностью и задержкой реплицируемой системы.

Примеры

  • Dynamo и Cassandra - это системы PA / EL: они предпочитают доступность согласованности при возникновении раздела; в противном случае они выбирают меньшую задержку.
  • BigTable »и HBase - это системы PC / EC: они всегда выбирают согласованность, отказываясь от доступности и меньшей задержки.
  • MongoDB можно рассматривать как PA / EC (конфигурация по умолчанию): MongoDB работает в первичной / вторичной конфигурации. В конфигурации по умолчанию все операции записи и чтения выполняются на основном сервере. Поскольку вся репликация выполняется асинхронно (от первичного к вторичному), когда есть сетевой раздел, в котором первичный потерян или становится изолированным на стороне меньшинства, существует вероятность потери данных, которые не реплицируются на вторичные, следовательно, есть потеря. согласованности во время перегородок. Таким образом, можно сделать вывод, что в случае сетевого раздела MongoDB выбирает доступность, но в остальном гарантирует согласованность. В качестве альтернативы, когда MongoDB настроен для записи на большинство реплик и чтения с основного, его можно отнести к категории PC / EC.

Заключение

Теоремы CAP и PACELC помогают распределенным системам выбирать желаемый баланс между различными распределенными характеристиками, такими как согласованность, доступность, устойчивость к разделам и задержка. Пожалуйста, прочтите Интервью по проектированию системы и Интервью по проектированию системы для продвинутых пользователей, где вы найдете несколько хороших примеров основ проектирования системы.