Всем привет!
Разработка распределенных систем — это искусство искать компромиссы между теми свойствами или требованиями, которыми мы хотим, чтобы система обладала, и теми свойствами, которые мы можем реализовать.
В общем случае принято разделять свойства (требования) системы на функциональные и нефункциональные.
Функциональные свойства — это то, что система делает с точки зрения пользователя.
Нефункциональные свойства — это то, как система работает: различные характеристики, ограничения и требования - доступность системы, время ответа, устойчивость к сбоям и т. п.
Если говорить о нефункциональных свойствах, то их можно отнести к трем основным группам:
- Consistency (C / Согласованность): каждое обращение к системе всегда отдаст актуальные данные. То есть все клиенты видят одни и те же данные в каждый конкретный момент.
- Availability (A / Доступность): каждый запрос к системе всегда вернет данные, даже если они устаревшие или неполные. Другими словами, клиент всегда получает данные, даже если часть узлов системы не доступны.
- Partition Tolerance (P / Устойчивость к разделению): система должна работать, даже когда потеряна связь между 2 и более узлами.
CAP теорема
Теорема CAP, известная также как теорема Брюера, говорит о том, что в распределенной системе возможно добиться удовлетворения лишь 2 из 3 основных свойств системы. Поэтому существует 3 комбинации этих характеристик: CA, AP и CP.
Почему не получится удовлетворить сразу 3 свойствам? Представим систему, состоящую из 2 узлов — M (master) и S (slave), в системе осуществляется репликация данных с использованием подхода master-slave (то есть один узел главный, а другой постоянно обновляет свое состояние в соответствии с главным). Представим, что нарушается связь между узлами и нам необходимо сохранить работоспособность системы (P), в этом случае мы можем удовлетворить только 1 свойству:
- Согласованности (С) — тогда нужно запретить запись в M, иначе данные, которые мы получим с S, будут отличаться (отказываемся от A).
- Доступности (A) — мы допускаем, что данные с узла S будут некоторое время неактуальны (отказываемся от C).
Таким образом, в условиях нарушения связи между узлами (P) мы не можем одновременно удовлетворить и согласованности (С) и доступности (A).
Ограничения CAP теоремы
Важно понимать, что CAP теорема — это попытка классифицировать абстрактные свойства системы. В реальности, как и у любой теории, у нее есть ограничения, к таким ограничениям можно отнести следующие:
- CAP подразумевает, хотя явно не говорит об этом, что все характеристики бинарны (либо есть, либо нет). Но в реальности свойства могут проявляться лишь частично.
- Не учитывает фактор задержки — если запросы долгие (не удовлетворяют требованиям), то доступность вроде бы присутствует, но можно ли называть такую систему доступной?
- Фокус только на 2 свойствах ограничивает разработчиков системы, но в реальности можно спроектировать систему так, чтобы все характеристики более-менее удовлетворяли всем трем ограничениям.
- Сетевое разделение — не единственный фактор, который нужно учитывать при проектировании, могут появляться множество других ошибок и сбоев.
В дополнение к CAP теореме существует теорема PACEL, которая расширяет ее и добавляет дополнительные свойства и является более приближенной к реальности.
Как применять CAP теорему
При проектировании систем нужно понимать, чем система может пожертвовать, а чем жертвовать не должна. Если вам необходима согласованность данных, то придется мириться с недоступностью системы в некоторые моменты времени. CAP теорема помогает осознать неизбежные компромиссы и выбирать архитектуру исходя из требований.
При формировании требований и согласовании их с заказчиком учитывайте ограничения используя CAP. Это позволит сразу убрать недопонимания и сформировать правильные ожидания от системы.
Участвую в конкурсе «Продолжи мысль» от @systems_education
#продолжи_мысль_SE
Разработка распределенных систем — это искусство искать компромиссы между теми свойствами или требованиями, которыми мы хотим, чтобы система обладала, и теми свойствами, которые мы можем реализовать.
В общем случае принято разделять свойства (требования) системы на функциональные и нефункциональные.
Функциональные свойства — это то, что система делает с точки зрения пользователя.
Нефункциональные свойства — это то, как система работает: различные характеристики, ограничения и требования - доступность системы, время ответа, устойчивость к сбоям и т. п.
Если говорить о нефункциональных свойствах, то их можно отнести к трем основным группам:
- Consistency (C / Согласованность): каждое обращение к системе всегда отдаст актуальные данные. То есть все клиенты видят одни и те же данные в каждый конкретный момент.
- Availability (A / Доступность): каждый запрос к системе всегда вернет данные, даже если они устаревшие или неполные. Другими словами, клиент всегда получает данные, даже если часть узлов системы не доступны.
- Partition Tolerance (P / Устойчивость к разделению): система должна работать, даже когда потеряна связь между 2 и более узлами.
CAP теорема
Теорема CAP, известная также как теорема Брюера, говорит о том, что в распределенной системе возможно добиться удовлетворения лишь 2 из 3 основных свойств системы. Поэтому существует 3 комбинации этих характеристик: CA, AP и CP.
Почему не получится удовлетворить сразу 3 свойствам? Представим систему, состоящую из 2 узлов — M (master) и S (slave), в системе осуществляется репликация данных с использованием подхода master-slave (то есть один узел главный, а другой постоянно обновляет свое состояние в соответствии с главным). Представим, что нарушается связь между узлами и нам необходимо сохранить работоспособность системы (P), в этом случае мы можем удовлетворить только 1 свойству:
- Согласованности (С) — тогда нужно запретить запись в M, иначе данные, которые мы получим с S, будут отличаться (отказываемся от A).
- Доступности (A) — мы допускаем, что данные с узла S будут некоторое время неактуальны (отказываемся от C).
Таким образом, в условиях нарушения связи между узлами (P) мы не можем одновременно удовлетворить и согласованности (С) и доступности (A).
Ограничения CAP теоремы
Важно понимать, что CAP теорема — это попытка классифицировать абстрактные свойства системы. В реальности, как и у любой теории, у нее есть ограничения, к таким ограничениям можно отнести следующие:
- CAP подразумевает, хотя явно не говорит об этом, что все характеристики бинарны (либо есть, либо нет). Но в реальности свойства могут проявляться лишь частично.
- Не учитывает фактор задержки — если запросы долгие (не удовлетворяют требованиям), то доступность вроде бы присутствует, но можно ли называть такую систему доступной?
- Фокус только на 2 свойствах ограничивает разработчиков системы, но в реальности можно спроектировать систему так, чтобы все характеристики более-менее удовлетворяли всем трем ограничениям.
- Сетевое разделение — не единственный фактор, который нужно учитывать при проектировании, могут появляться множество других ошибок и сбоев.
В дополнение к CAP теореме существует теорема PACEL, которая расширяет ее и добавляет дополнительные свойства и является более приближенной к реальности.
Как применять CAP теорему
При проектировании систем нужно понимать, чем система может пожертвовать, а чем жертвовать не должна. Если вам необходима согласованность данных, то придется мириться с недоступностью системы в некоторые моменты времени. CAP теорема помогает осознать неизбежные компромиссы и выбирать архитектуру исходя из требований.
При формировании требований и согласовании их с заказчиком учитывайте ограничения используя CAP. Это позволит сразу убрать недопонимания и сформировать правильные ожидания от системы.
Участвую в конкурсе «Продолжи мысль» от @systems_education
#продолжи_мысль_SE