> For the complete documentation index, see [llms.txt](https://folko.gitbook.io/podgotovka-k-sobesedovaniyu/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://folko.gitbook.io/podgotovka-k-sobesedovaniyu/arkhitekturnye-voprosy/raspredelennye-sistemy.md).

# Распределенные системы

В распределённых системах используется и распределённое состояние приложений. В соответствии с [теоремой CAP](https://ru.wikipedia.org/wiki/%D0%A2%D0%B5%D0%BE%D1%80%D0%B5%D0%BC%D0%B0_CAP) в любой реализации распределённых вычислений возможно обеспечить не более двух из трёх следующих свойств: [согласованность данных](https://ru.wikipedia.org/wiki/%D0%9C%D0%BE%D0%B4%D0%B5%D0%BB%D1%8C_%D1%81%D0%BE%D0%B3%D0%BB%D0%B0%D1%81%D0%BE%D0%B2%D0%B0%D0%BD%D0%BD%D0%BE%D1%81%D1%82%D0%B8) (consistency), [доступность информации](https://ru.wikipedia.org/wiki/%D0%94%D0%BE%D1%81%D1%82%D1%83%D0%BF%D0%BD%D0%BE%D1%81%D1%82%D1%8C_%D0%B8%D0%BD%D1%84%D0%BE%D1%80%D0%BC%D0%B0%D1%86%D0%B8%D0%B8) (availability) и [устойчивость к разделению](https://en.wikipedia.org/wiki/Network_partition) (partition tolerance) (первые буквы английских наименований этих свойств и сформировали акроним CAP). Получается, что для того чтобы сделать свою реализацию распределённой системы устойчивой к отказам, необходимо выбирать между доступностью информации и согласованностью данных. Если мы выберем доступность информации — то, в итоге, в нашем распоряжении окажется то, что называют «согласованностью в конечном счёте» (eventual consistency). То есть — данные будут согласованными, но лишь через некоторое время после последнего обновления. А если выбрать согласованность данных — это окажет воздействие на производительность, так как возникнет необходимость в синхронизации и изоляции операций записи данных во всей распределённой системе.\
\
 [Порождение событий](https://microservices.io/patterns/data/event-sourcing.html) (event sourcing) — это концепция, в соответствии с которой состояние бизнес-сущностей, таких, как заказ или клиент, хранится в виде последовательности событий, изменяющих состояние. Это обеспечивает доступность информации вместо согласованности данных. В результате можно применять очень просто устроенные операции записи, но выполнение операций чтения при этом усложняется, так как в том случае, если такие операции распространяются на несколько сервисов, для их выполнения может потребоваться использование особой модели чтения данных.\
\
 Для организации коммуникаций в распределённой системе может использоваться брокер, но можно обойтись и без него. Системы, в которых нет брокера, широко известны. Самая известная из них — это, пожалуй, система обмена данными, реализованная в рамках протокола HTTP. Системы, в которых используется брокер, как можно судить из их названия, обладают особой сущностью-брокером, находящейся между отправителем и получателем сообщения. Брокер разделяет отправителя и получателя, позволяя организовывать синхронный и асинхронный обмен данными. Это улучшает отказоустойчивость системы, так как потребитель сообщения не обязательно должен быть доступен в момент отправки сообщения. Коммуникации, основанные на использовании брокера, кроме того, позволяют независимо масштабировать системы, занимающиеся отправкой и получением сообщений. [Вот](https://redislabs.com/blog/what-to-choose-for-your-synchronous-and-asynchronous-communication-needs-redis-streams-redis-pub-sub-kafka-etc-best-approaches-synchronous-asynchronous-communication/) материал, содержащий некоторые сведения по вопросу выбора технологии для организации синхронного и асинхронного обмена данными в распределённых системах.