Мы сейчас живем в эру микросервисов, а это значит, что так или иначе разработчику приходится сталкиваться с распределенными системами. Понимание теории и принципов построения распределенных систем поможет вам не только на собеседовании, но и при решение рабочих задач. Итак, начнем!
👀Дисклеймер:
Понятие согласованности — одно из самых неоднозначных в ИТ.
❗️Важно: значение термина меняется, если речь идет о БД или распределенных системах. В CAP, ACID и модели согласованности данных - термин согласованность имеет разные оттенки смысла.
CAP - теорема (теорем Брюера)
В CAP говорится, что в распределенной системе возможно выбрать только 2 из 3-х свойств:
-🔠 Consistency — согласованность данных. На всех не отказавших узлах одновременно одинаковые (с точки зрения пользователя) данные.
-🔠 Availability — доступность. Каждый не отказавший узел всегда успешно отвечает (на чтение и запись).
-🔠 Partition tolerance — устойчивость к фрагментации. Даже если между узлами нет связи, они продолжают работать независимо друг от друга.
Следствие из этой теоремы: распределённые системы делятся на три класса в зависимости от поддерживаемых свойств — CA, CP, AP.
🟧CA
В системах класса CA во всех узлах данные согласованы и обеспечена доступность, при этом она жертвует устойчивостью к распаду на части. Другими словами, мы можем достичь высокой степени согласованности при относительно небольшом времени простоя, но мы рискуем, что проблемы с сетью приведут к сбою всей системы или, по крайней мере, вызовут сбои.
Системы CA обычно основаны на традиционных реляционных базах данных, таких как MySQL👩💻, PostgreSQL👩💻, MSSQL👩💻 или Oracle.
🟧CP
Система вычислений класса CP в каждый момент обеспечивает целостный результат и способна функционировать в условиях распада, но достигает этого в ущерб доступности: может не отвечать на запрос. Самый популярный пример CP системы — MongoDB👩💻.
🟧AP
В системе вычислений класса AP не гарантируется свойство согласованности данных, но при этом выполнены условия доступности и устойчивости к разделению. Большинство NoSQL-систем принципиально не гарантируют целостности данных, и ссылаются на теорему CAP как на мотив такого ограничения. Яркий пример AP системы — CouchDB, Cassandra, ScyllaDB.
Поскольку в AP системах мы не можем добиться очень важного свойства - согласованности данных (а, если быть точнее, в терминах моделей согласованности - строгой согласованности), то главной задачей при построении AP-систем становится обеспечение некоторого практически целесообразного уровня целостности данных (т.е. понижения требования к свойству согласованности). В этом случае про AP-систем, как правило, говорят, либо как о «согласованных в конечном итоге» (eventually consistent) или как о «слабо согласованных» (weak consistent).
💫 В следующей части рассмотрим модель согласованности данных.