Обновление

2025-01-17 15:29:17 +03:00 · 2025-01-17 15:29:17 +03:00 · 6d52584f95
commit 6d52584f95
parent 7678dd0440
27 changed files with 323 additions and 28 deletions
--- a/dev/architecture/CAP
+++ b/dev/architecture/CAP
@ -8,11 +8,11 @@ date:
 ![[../../meta/files/images/Pasted image 20241103022605.png]]

 CAP теорема — это принцип, описывающий фундаментальные ограничения, с которыми сталкиваются распределённые вычислительные системы в контексте обеспечения следующих трёх свойств:
- **Согласованность (Consistency)**: Каждый раз, когда данные читаются, возвращается самое последнее записанное значение или ошибка. С другими словами, операции с данными выглядят так, будто выполняются в некоторой строгой последовательности, одна за другой
- Доступность ([[../../../../_inbox/Availability|Availability]]): Каждый запрос на получение или запись данных получает ответ, независимо от состояния системы, даже если некоторые части системы вышли из строя.
+- **Согласованность** ([[Согласованность данных|Consistency]]): Каждый раз, когда данные читаются, возвращается самое последнее записанное значение или ошибка. С другими словами, операции с данными выглядят так, будто выполняются в некоторой строгой последовательности, одна за другой
+- **Доступность** ([[../../../../_inbox/Availability|Availability]]): Каждый запрос на получение или запись данных получает ответ, независимо от состояния системы, даже если некоторые части системы вышли из строя.
 - **Устойчивость к разделению (Partition Tolerance)**: Система продолжает функционировать, даже если произошло "разделение" — потеря связи между узлами в распределённой сети. То есть система способна переносить произвольное число сообщений, которые задерживаются или теряются в сети.

-==Согласно теореме CAP, в любой момент времени система может обеспечивать только два из этих трёх свойств.== Это означает, что при разработке системы приходится принимать компромисс между этими свойствами в зависимости от требований приложения и условий эксплуатации. Например, если для системы критически важна согласованность данных и её устойчивость к разделению, возможно придётся пожертвовать её доступностью в некоторых сценариях.
+==Согласно теореме CAP, в любой момент времени система может обеспечивать только два из этих трёх свойств.== Это означает, что при разработке системы приходится принимать компромисс между этими свойствами в зависимости от требований приложения и условий эксплуатации. Например, если для системы критически важна [[согласованность данных]] и её устойчивость к разделению, возможно придётся пожертвовать её доступностью в некоторых сценариях.
 ## Свободные заметки
 - Google заявляет, что их продукт Google Spanner якобы нарушает CAP теорему.
 ***
--- a/dev/architecture/Change
+++ b/dev/architecture/Change
@ -0,0 +1,56 @@
+---
+aliases:
+  - CDC
+tags:
+  - maturity/🌱
+date: 2025-01-13
+---
+**Change Data Capture (CDC)** — это технология для отслеживания изменений в данных [[../../meta/zero/00 Реляционная база данных|базы данных]] (вставка, обновление, удаление) и публикации этих изменений в виде событий для других систем. CDC играет ключевую роль в построении [[Событийно-ориентированная архитектура|событийных архитектур]] и интеграции данных между системами.
+
+**Применение CDC**
+- **Миграция данных**. Перенос данных между системами с минимальными простоями.
+- **Событийные системы**. Построение архитектур, где изменения в данных становятся триггерами для выполнения действий.
+- **Аналитика в реальном времени**. Передача данных в системы аналитики (например, ClickHouse, Elasticsearch).
+- **Интеграция приложений**. Связывание разнородных систем через обмен данными.
+
+**Преимущества CDC**
+- **Синхронизация данных в реальном времени**. Автоматическое обновление данных между системами.
+- **Снижение нагрузки на базу данных**. Обрабатываются только изменения, а не полные данные.
+- **Поддержка событийной архитектуры**. Преобразует изменения в события, которые могут обрабатываться асинхронно.
+- **Простота интеграции**. Позволяет связывать разные приложения и системы через единый механизм передачи данных.
+
+**Основные подходы к реализации CDC**
+- **Журнал транзакций (Transaction Logs)**. Изменения отслеживаются с помощью анализа журнала транзакций базы данных (логов WAL, redo, binlog).
+	- **Плюсы**: Высокая производительность, минимальная нагрузка на базу данных.
+	- **Минусы**: Требует доступа к журналу транзакций, ограниченная поддержка некоторых баз.
+- **Триггеры в базе данных**. Изменения фиксируются с помощью триггеров, которые вызываются при выполнении операций (вставка, обновление, удаление).
+	- **Плюсы**: Простота настройки.
+	- **Минусы**: Снижение производительности базы данных, сложность поддержки.
+- **Опрос данных (Polling)**. Система периодически проверяет таблицы базы данных на наличие изменений.
+	- **Плюсы**: Простая реализация.
+	- **Минусы**: Высокая нагрузка на базу данных, задержки между изменениями и их обработкой.
+
+**Инструменты для CDC**
+- **Debezium**
+	- Open-source решение для CDC.
+	- Поддерживает PostgreSQL, MySQL, MongoDB, Oracle и другие.
+	- Интегрируется с Kafka для публикации событий.
+- **Oracle GoldenGate**
+	- Коммерческий продукт для CDC.
+	- Высокая производительность, поддержка множества СУБД.
+- **Striim**
+	- Платформа для потоковой обработки данных с поддержкой CDC.
+	- Включает инструменты визуализации и настройки ETL.
+***
+## Мета информация
+**Область**:: [[Архитектурный паттерн]]
+**Родитель**:: [[Интеграция информационных систем|Интеграция информационных систем]]
+**Источник**:: 
+**Создана**:: [[2025-01-13]]
+**Автор**:: 
+### Дополнительные материалы
+- 
+
+### Дочерние заметки
+<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
+
--- a/dev/architecture/Database
+++ b/dev/architecture/Database
@ -24,7 +24,7 @@ date: 2024-11-24
 Лучшие практики
 - **Чёткие границы владения данными**. Определите чёткие границы владения данными для каждого сервиса, - [[Bounded Context|Ограниченный контекст]]. Это помогает избежать пересечений и зависимостей между сервисами, а также упрощает управление данными.
 - [[Событийно-ориентированная архитектура|Событийно-ориентированная архитектура]]. Для обеспечения согласованности данных между микросервисами можно использовать события. Например, при изменении данных в одном сервисе он отправляет событие, на которое подписаны другие сервисы, которым эти данные могут быть нужны.
- **Реализация паттернов для согласованности**. Используйте паттерны, такие как [Saga](Реализация%20повествования%20(Saga).md), чтобы координировать действия между несколькими микросервисами и гарантировать согласованность данных без использования глобальных транзакций.
+- **Реализация паттернов для согласованности**. Используйте паттерны, такие как [Saga](Реализация%20повествования%20(Saga).md), чтобы координировать действия между несколькими микросервисами и гарантировать [[согласованность данных]] без использования глобальных транзакций.
 - **API вместо прямого доступа к данным**. Доступ к данным одного микросервиса другими должен осуществляться только через публичные API. Это помогает соблюдать [[Инкапсуляция|инкапсуляцию]] и обеспечивает безопасное взаимодействие между сервисами.
 ***
 ## Мета информация
--- a/dev/architecture/Event
+++ b/dev/architecture/Event
@ -27,7 +27,7 @@ Event Sourcing — это [[архитектурный паттерн]], при
 1. **Финансовые системы**. Для учета транзакций и обеспечения полного логирования операций.
 2. **E-commerce**. Хранение всех изменений корзины пользователя или заказов.
 3. **IoT**. Сохранение событий от датчиков для анализа в реальном времени или ретроспективы.
-4. Паттерн [[../../../../knowledge/dev/архитектура/паттерн/CQRS|CQRS]]. Часто используется совместно с Event Sourcing для разделения операций чтения и записи.
+4. Паттерн [[../../../../knowledge/dev/архитектура/паттерн/Command Query Responsibility Segregation|Command Query Responsibility Segregation]]. Часто используется совместно с Event Sourcing для разделения операций чтения и записи.
 ***
 ## Мета информация
 **Область**:: [[../../meta/zero/00 Архитектура ИС|00 Архитектура ИС]]
--- a/dev/architecture/Transactional
+++ b/dev/architecture/Transactional
@ -2,6 +2,8 @@
 aliases:
  - transactional outbox
  - транзакционный аутбокс
+  - Outbox-паттерн
+  - Outbox Pattern
 tags:
  - maturity/🌱
 date: 2024-11-15
@ -16,7 +18,7 @@ Transactional Outbox — это [[Паттерн проектирования|ш

 **Преимущества:**
 - **Гарантированная доставка сообщений**: сообщения фиксируются вместе с бизнес-операциями, что предотвращает ситуацию, когда данные в базе данных обновлены, а сообщение не отправлено.
- **Упрощение архитектуры**: использование таблицы `outbox` вместо распределённых транзакций (2PC) значительно упрощает архитектуру и позволяет избежать сложных механизмов блокировки.
+- **Упрощение архитектуры**: использование таблицы `outbox` вместо распределённых транзакций ([[../fundamental/Two-Phase Commit|2PC]]) значительно упрощает архитектуру и позволяет избежать сложных механизмов блокировки.

 **Недостатки:**
 - **Дополнительная задержка**: отправка сообщений через фоновый процесс может вызвать небольшую задержку в доставке сообщений, по сравнению с немедленной отправкой.
--- a/dev/architecture/highload/Горизонтальное
+++ b/dev/architecture/highload/Горизонтальное
@ -17,7 +17,7 @@ date:
 **Проблемы:**
 1. **Сложность управления**: Управление множеством узлов и их координация может быть значительно сложнее, чем управление одним мощным сервером. Нужно делать балансировку вызовов.
 2. **Сложность разработки**: Разработка приложений, способных эффективно использовать ресурсы в распределенной среде, может быть более сложной, а значит программисты обходятся дороже.
-3. **Согласованность данных**: Обеспечение согласованности данных между множеством узлов может представлять собой вызов, особенно в системах, где требуется высокий уровень согласованности.
+3. [[../Согласованность данных|Согласованность данных]]: Обеспечение согласованности данных между множеством узлов может представлять собой вызов, особенно в системах, где требуется высокий уровень согласованности.
 4. **Затраты на сеть**: Горизонтальное масштабирование может повлечь за собой увеличенные затраты на сетевое оборудование и управление сетью, особенно если узлы географически распределены.

 Частные проблемы:
--- a/dev/architecture/highload/Групповая
+++ b/dev/architecture/highload/Групповая
@ -14,7 +14,7 @@ linked:

 - Все транзакции чтения и записи фиксируются только после того, как они были одобрены группой.
 - Read-only транзакции не требуют координации внутри группы и фиксируются немедленно
- Групповая репликация - eventual consistency система
+- Групповая репликация - [[../Еventual consistency|Еventual consistency]] система

 ![](../../../meta/files/images/Pasted%20image%2020240605091036.png)

--- a/dev/architecture/highload/Монотонное
+++ b/dev/architecture/highload/Монотонное
@ -1,5 +1,7 @@
 ---
-aliases: 
+aliases:
+  - Monotonic Read Consistency
+  - Monotonic Read
 tags:
  - maturity/🌱
 date:
--- a/dev/architecture/Архитектурный
+++ b/dev/architecture/Архитектурный
@ -14,6 +14,10 @@ date: 2024-12-02
 - [[Событийно-ориентированная архитектура]]

 - [[Event Sourcing]]
+- [[../../../../knowledge/dev/архитектура/паттерн/Command Query Responsibility Segregation|CQRS]]
+
+Миграция/синхронизация данных:
+- [[Change Data Capture|Change Data Capture]]
 ***
 ## Мета информация
 **Область**:: [[../../meta/zero/00 Архитектура ИС|00 Архитектура ИС]]
@ -30,6 +34,8 @@ date: 2024-12-02
 - [[Event Sourcing]]
 - [[Serverless]]
 - [[Монолитная архитектура]]
+- [[Событийно-ориентированная архитектура]]
 - [[00 Микросервисная архитектура]]
+- [[Command Query Responsibility Segregation]]
 <!-- SerializedQuery END -->

--- a/dev/architecture/Еventual
+++ b/dev/architecture/Еventual
@ -0,0 +1,22 @@
+---
+aliases:
+  - Конечная согласованность
+  - eventual consistency
+tags:
+  - maturity/🌱
+date: 2025-01-15
+---
+
+***
+## Мета информация
+**Область**:: [[../../meta/zero/00 Архитектура ИС|00 Архитектура ИС]]
+**Родитель**:: [[Согласованность данных|Согласованность данных]]
+**Источник**:: 
+**Создана**:: [[2025-01-15]]
+**Автор**:: 
+### Дополнительные материалы
+- 
+
+### Дочерние заметки
+<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
+
--- a/dev/architecture/Идемпотентность.md
+++ b/dev/architecture/Идемпотентность.md
@ -5,6 +5,8 @@ aliases:
  - идемпотентности
  - идемпотентную
  - идемпотентные
+  - Идемпотентные операции
+  - Idempotence
 tags:
  - maturity/🌱
 date: 2024-09-11
--- a/dev/architecture/Избыточность
+++ b/dev/architecture/Избыточность
@ -26,7 +26,7 @@ date: 2024-11-24
 2. **Увеличение объёма хранилища**. Хранение данных в нескольких формах требует больше места в хранилище. Для высоконагруженных систем с большими объёмами данных это может стать значительным фактором.

 Лучшие практики для работы с избыточностью данных
-1. **Продуманная архитектура синхронизации**. Используйте [[Событийно-ориентированная архитектура|событийную архитектуру]], чтобы поддерживать согласованность данных. Например, при добавлении нового сообщения можно отправить событие, которое обновит индекс последних сообщений.
+1. **Продуманная архитектура синхронизации**. Используйте [[Событийно-ориентированная архитектура|событийную архитектуру]], чтобы поддерживать [[согласованность данных]]. Например, при добавлении нового сообщения можно отправить событие, которое обновит индекс последних сообщений.
 2. **Оценка необходимости избыточности**. Вводите избыточность только там, где это действительно необходимо для повышения производительности или удобства работы. Не стоит избыточно усложнять систему там, где этого можно избежать.
 3. **Мониторинг консистентности**. Внедряйте механизмы проверки и восстановления консистентности данных между копиями. Это поможет вовремя обнаружить и устранить расхождения.

--- a/dev/architecture/Интеграция
+++ b/dev/architecture/Интеграция
@ -0,0 +1,24 @@
+---
+aliases: 
+tags:
+  - maturity/🌱
+date: 2025-01-13
+---
+Подходы:
+- [[Change Data Capture]]
+***
+## Мета информация
+**Область**:: [[../../meta/zero/00 Архитектура ИС|00 Архитектура ИС]]
+**Родитель**:: 
+**Источник**:: 
+**Создана**:: [[2025-01-13]]
+**Автор**:: 
+### Дополнительные материалы
+- 
+
+### Дочерние заметки
+<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
+<!-- SerializedQuery: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
+- [[Change Data Capture]]
+<!-- SerializedQuery END -->
+
--- a/dev/architecture/Отправка
+++ b/dev/architecture/Отправка
@ -2,18 +2,20 @@
 aliases: 
 tags:
  - maturity/🌱
+  - content/problem
 date: 2024-11-15
 ---
-Отправка сообщений в [[00 Kafka|Kafka]] из [[Транзакция БД|транзакций базы данных]] приводит к проблемам с согласованностью данных между системами, особенно в условиях распределённых систем. Если сначала происходит отправка сообщения в Kafka, а затем транзакция в БД откатывается, то сообщение останется в Kafka, но база данных не зафиксирует изменений, что приведёт к рассинхронизации данных.
+Взаимодействие между [[../../../../_inbox/Транзакция БД|транзакциями базы данных]] и отправкой сообщений в [[../../../../_inbox/00 Kafka|Kafka]] может приводить к несогласованности данных. Пример проблемы: если сообщение отправлено в Kafka, но транзакция базы данных откатывается, сообщение останется в Kafka, тогда как база данных не зафиксирует изменений. Это вызывает рассинхронизацию между системами.

-Для обеспечения согласованности данных между базой данных и Kafka необходимо использовать следующие подходы:
+Для решения проблемы используются следующие подходы:

- [[Transactional Outbox|Transactional Outbox]]. Этот подход позволяет отделить запись в базу данных от отправки сообщения в брокер. Изменения сначала фиксируются в основной таблице базы данных, а затем записываются в специальную таблицу "Outbox". Отдельный процесс или сервис асинхронно считывает из таблицы "Outbox" и отправляет сообщения в Kafka, что гарантирует согласованность данных.
- Change Data Capture (CDC). Использование CDC с инструментами вроде Debezium позволяет отслеживать изменения в базе данных и публиковать их в Kafka. Это решение подходит для случаев, когда необходимо обеспечить автоматическую синхронизацию изменений, но может потребовать дополнительных настроек и ресурсов.
- Распределённые транзакции (двухфазный коммит). Этот метод позволяет гарантировать согласованность между базой данных и Kafka за счёт координации транзакций между ними. Однако этот подход часто считается сложным и менее масштабируемым, особенно в распределённых системах.
+- [[Transactional Outbox|Transactional Outbox]]. Изменения фиксируются в основной таблице базы данных и одновременно записываются в отдельную таблицу “Outbox”. Асинхронный процесс или сервис считывает записи из “Outbox” и отправляет их в Kafka. Это позволяет отделить транзакцию базы данных от отправки сообщений и гарантировать [[Согласованность данных|согласованность]].
+- [[Change Data Capture]] (CDC). С помощью инструментов, таких как Debezium, отслеживаются изменения в базе данных. Эти изменения публикуются в Kafka в режиме реального времени. CDC подходит для автоматической синхронизации данных, но требует настройки и дополнительных ресурсов.
+- Распределённые транзакции (двухфазный коммит). Этот подход координирует транзакции между базой данных и Kafka, гарантируя [[Согласованность данных|согласованность]]. Однако он считается сложным в реализации и менее масштабируемым, особенно в распределённых системах.

-Другая серьёзная проблема связана с возможностью двойной обработки. В случае сбоя приложения или инфраструктуры транзакции могут повторяться, приводя к дублированию событий в Kafka. Дублирование событий может вызвать некорректное состояние системы, повторное выполнение операций. Чтобы предотвратить дублирование, можно использовать следующие подходы: 
- [[highload/Идемпотентность на базе уникального идентификатора|Идемпотентность на базе уникального идентификатора]]
+При сбоях системы возможна повторная обработка транзакций, что приводит к дублированию событий в Kafka. Это может вызвать повторное выполнение операций и привести к некорректному состоянию системы.
+
+Для предотвращения дублирования используется [[highload/Идемпотентность на базе уникального идентификатора|идемпотентность на базе уникального идентификатора]]. Пример: каждое сообщение или транзакция сопровождается уникальным идентификатором, который проверяется перед выполнением операции. Если идентификатор уже обработан, операция пропускается.
 ***
 ## Мета информация
 **Область**:: [[../../meta/zero/00 Архитектура ПО|00 Архитектура ПО]]
--- a/dev/architecture/Распределенная
+++ b/dev/architecture/Распределенная
@ -1,5 +1,6 @@
 ---
-aliases: 
+aliases:
+  - распределённой транзакции
 tags:
  - maturity/🌱
 date: 2024-12-02
--- a/dev/architecture/Событийно-ориентированная
+++ b/dev/architecture/Событийно-ориентированная
@ -6,6 +6,7 @@ aliases:
  - Событийно-ориентированная архитектура
  - событийную архитектуру
  - Событийная архитектура
+  - событийных архитектур
 tags:
  - maturity/🌱
 date:
@ -44,6 +45,10 @@ date:
 	- [[Отправка сообщений в Kafka из транзакции БД]]
 - Можно читать бинлог и отправлять в [[Брокер сообщений]]
 - [[Transactional Outbox]]. Сохраняем события в БД, из которой события отправляются в [[Брокер сообщений]].
+
+**Тип отправляемых данных:**
+- [[Event Sourcing]]. Отправлять только те данные, которые изменились.
+- Отправлять целиком актуальные данные.
 ***
 ## Мета информация
 **Область**:: [[../../meta/zero/00 Архитектура ИС|00 Архитектура ИС]]
--- a/dev/architecture/Согласованность
+++ b/dev/architecture/Согласованность
@ -0,0 +1,55 @@
+---
+aliases:
+  - Consistency
+  - согласованность
+tags:
+  - maturity/🌱
+date: 2025-01-15
+---
+**Согласованность данных** — это свойство, гарантирующее, что данные в [[../../../../_inbox/Информационная система|системе]] остаются правильными и соответствуют определённым правилам после выполнения операций. Это важно как для локальных баз данных, так и для распределённых систем.
+
+**Проблемы согласованности**
+- **Сетевые задержки**. [[Latency|Задержки]] или сбои в сети увеличивают сложность обеспечения согласованности.
+- **Конфликты данных**. При параллельных изменениях системы должны разрешать конфликты.
+- **Цена согласованности**. Чем выше уровень согласованности, тем больше задержки и ниже производительность.
+
+**Уровни согласованности**
+- **Строгая согласованность (Strong Consistency)**: Все узлы системы видят одно и то же состояние данных в любой момент времени.
+	- Пример: Системы банковских счетов.
+	- Недостаток: Высокие [[Latency|задержки]], так как требуется синхронизация между всеми узлами.
+- **Чтение после записи (Read-After-Write Consistency)**:
+	- После записи данных в систему любое последующее чтение возвращает обновлённое значение.
+	- Пример: Создание или обновление документа.
+- [[highload/Монотонное чтение|Монотонное чтение]] (Monotonic Read Consistency):
+	- Если пользователь прочитал определённое значение данных, последующие чтения не вернут более старое состояние.
+- [[Еventual consistency|Конечная согласованность]] (Eventual Consistency): Узлы системы со временем синхронизируются, но в краткосрочной перспективе данные могут быть несогласованными.
+	- Пример: Системы репликации данных, такие как [[../../../../knowledge/dev/network/DNS|DNS]].
+
+**Методы обеспечения согласованности**
+- **Консенсусные алгоритмы**:
+	- **Paxos, Raft**: Обеспечивают согласованность между узлами в условиях отказов.
+	- Применяются в распределённых базах данных и системах координаторов.
+- **Механизмы транзакций**:
+	- [[../fundamental/Two-Phase Commit|Двухфазный коммит]] (2PC): Обеспечивает атомарность и согласованность между участниками транзакции.
+	- **Согласованное журналирование**: Используется для [[highload/Disaster recovery|восстановления]] согласованности после сбоев.
+- **Паттерны согласованности**:
+	- [[Еventual consistency|Eventual Consistency]] + [[Идемпотентность|Idempotence]]: Для систем, допускающих временную рассогласованность.
+	- [[Transactional Outbox|Outbox Pattern]]: Для передачи данных между системами с гарантией доставки.
+
+***
+## Мета информация
+**Область**:: 
+**Родитель**:: 
+**Источник**:: 
+**Создана**:: [[2025-01-15]]
+**Автор**:: 
+### Дополнительные материалы
+- 
+
+### Дочерние заметки
+<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
+<!-- SerializedQuery: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
+- [[Еventual consistency]]
+- [[Согласованность транзакции БД (Сonsistency)]]
+<!-- SerializedQuery END -->
+
--- a/dev/fundamental/Deadlock.md
+++ b/dev/fundamental/Deadlock.md
@ -25,7 +25,7 @@ linked:
 - Выполнить повторно откатившуюся транзакцию

 **Что реально поможет:**
- Разделить потоки чтения и записи: [CQRS](CQRS.md)
+- Разделить потоки чтения и записи: [Command Query Responsibility Segregation](../../../../knowledge/dev/архитектура/паттерн/Command%20Query%20Responsibility%20Segregation.md)
 - Использовать материализованные view.
 - Изменить порядок блокировок ресурсов. Если в разных операциях блокируется определенный набор ресурсов, то блокироваться первым должен всегда один и тот же ресурс
 - Пересмотреть [Уровни изоляций транзакций БД](Уровни%20изоляций%20транзакций%20БД.md)
--- a/dev/fundamental/MESI.md
+++ b/dev/fundamental/MESI.md
@ -14,7 +14,7 @@ linked:
 - **S (Shared)** — данные разделены между несколькими ядрами, и их копии синхронизированы с памятью.
 - **I (Invalid)** — данные в кэше недействительны, потому что они были изменены другим ядром или сброшены.

-==Когда одно ядро изменяет данные в своем кэше, протокол MESI уведомляет другие ядра о том, что их копии этих данных больше не актуальны==. Это позволяет поддерживать согласованность данных между ядрами и предотвращает возможные ошибки.
+==Когда одно ядро изменяет данные в своем кэше, протокол MESI уведомляет другие ядра о том, что их копии этих данных больше не актуальны==. Это позволяет поддерживать [[../architecture/Согласованность данных|согласованность данных]] между ядрами и предотвращает возможные ошибки.

 ***
 ## Мета информация
--- a/dev/fundamental/Two-Phase
+++ b/dev/fundamental/Two-Phase
@ -0,0 +1,64 @@
+---
+aliases:
+  - 2PC
+  - двухфазный-коммит
+  - двухфазный коммит
+tags:
+  - maturity/🌱
+date: 2025-01-13
+---
+**Двухфазный коммит (Two-Phase Commit, 2PC)** — это протокол [[../architecture/Распределенная транзакция|распределённой транзакции]], который обеспечивает [[../architecture/Согласованность данных|согласованность данных]] между несколькими системами или узлами. Он используется для выполнения атомарных операций в распределённых системах, таких как базы данных и брокеры сообщений.
+
+**Преимущества двухфазного коммита**
+- **Гарантия согласованности**. Все участники либо фиксируют изменения, либо откатываются к исходному состоянию.
+- [[Атомарная операция|Атомарность операций]]. Транзакция выполняется полностью или не выполняется вообще.
+
+**Недостатки двухфазного коммита**
+- **Производительность**.
+	- Протокол увеличивает задержки из-за необходимости согласования между участниками.
+	- Блокировка ресурсов (например, записей в базе данных) может привести к снижению пропускной способности системы.
+- **Риск блокировок (Blocking)**. Если координатор выходит из строя, участники могут остаться в подвешенном состоянии, ожидая дальнейших команд.
+- **Сложность реализации**. Настройка двухфазного коммита в распределённых системах требует глубокого понимания протокола и особенностей инфраструктуры.
+- **Проблемы масштабирования**. Протокол плохо работает в системах с большим количеством участников из-за увеличения числа сообщений и времени согласования.
+
+Протокол состоит из двух этапов:
+- **Фаза подготовки (Prepare Phase)**:
+	- Координатор транзакции отправляет запрос всем участникам (например, базам данных или брокерам сообщений) с просьбой подготовиться к выполнению операции.
+	- Участники проверяют возможность выполнения операции и сообщают координатору о своём статусе:
+		- **“Готов” (Vote Yes)**, если операция может быть выполнена.
+		- **“Не готов” (Vote No)**, если операция невозможна. Если хотя бы один участник возвращает “Не готов”, координатор инициирует откат транзакции.
+- **Фаза фиксации (Commit Phase)**:
+	- Если все участники подтвердили готовность, координатор отправляет команду зафиксировать изменения (**Commit**).
+	- Участники фиксируют изменения и подтверждают выполнение операции.
+	- Если хотя бы один участник не может выполнить фиксацию, координатор отправляет команду отката (**Rollback**) всем участникам.
+
+**Двухфазный коммит применим, если:**
+- Критически важно обеспечить [[../architecture/Согласованность данных|согласованность данных]].
+- Количество участников в транзакции относительно небольшое.
+- Высокая задержка или снижение производительности являются допустимыми.
+
+**Применение двухфазного коммита**.
+- **Банковские транзакции**. Обеспечение согласованности при переводе средств между счетами.
+- **Обновление нескольких баз данных**. Когда данные в разных базах должны быть изменены синхронно.
+- **Интеграция с брокерами сообщений**. Обеспечение атомарности при отправке сообщений и обновлении базы данных.
+
+Однако, в большинстве современных распределённых систем предпочитают альтернативные подходы из-за их большей гибкости и масштабируемости.
+
+**Альтернативы двухфазному коммиту**
+- [[../architecture/Идемпотентность|Идемпотентные операции]]. Вместо сложных транзакций системы обрабатывают повторы операций без изменений состояния.
+- [[../architecture/Transactional Outbox|Outbox-паттерн]]. Использование промежуточного хранилища для согласования операций.
+- [[../architecture/Event Sourcing|Event Sourcing]]. Применение событийной модели, где изменения состояния записываются как события, а не как транзакции.
+- [[../../../../_inbox/Basically Available Soft state Eventual consistency|BASE]] вместо [[../database/Свойства транзакций БД|ACID]]. Принятие модели [[../../../../_inbox/Basically Available Soft state Eventual consistency|BASE]], которая допускает временную рассогласованность ради повышения производительности.
+***
+## Мета информация
+**Область**:: [[../../meta/zero/00 Разработка|00 Разработка]]
+**Родитель**:: 
+**Источник**:: 
+**Создана**:: [[2025-01-13]]
+**Автор**:: 
+### Дополнительные материалы
+- 
+
+### Дочерние заметки
+<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
+
--- a/dev/fundamental/Two-Phase
+++ b/dev/fundamental/Two-Phase
@ -0,0 +1,50 @@
+---
+aliases:
+  - 2-phase lock
+  - 2PL
+tags:
+  - maturity/🌱
+date:
+  - - 2024-06-20
+---
+Протокол **Two-Phase Locking (2PL)** управляет доступом к данным в базе данных, обеспечивая их корректность и изоляцию между транзакциями. 2PL работает по следующему алгоритму:
+
+- **Фаза установки блокировок**: Транзакция может запрашивать блокировки для данных, которые она намерена использовать (чтение или запись).
+- **Фаза снятия блокировок**: После начала снятия блокировок транзакция не может запрашивать новые блокировки.
+
+Эти две фазы предотвращают конфликты и обеспечивают согласованное выполнение операций.
+
+**Изменение данных (операция записи)**
+- Запрашивается **блокировка на запись** (exclusive lock).
+- Ожидается снятие всех блокировок, установленных до этой транзакции.
+- Данные изменяются.
+- Блокировка снимается.
+
+**Чтение данных**
+- Запрашивается **блокировка на чтение** (shared lock).
+- Ожидается снятие всех блокировок на запись, установленных до этой транзакции.
+- Данные считываются.
+- Блокировка снимается.
+
+**Важные особенности**
+- **Блокировка на запись**. Она запрещает одновременно читать или изменять данные другим транзакциям.
+- **Изоляция транзакций**. Согласно теореме 2PL, если все транзакции следуют этому протоколу, они будут изолированы друг от друга. Это значит, что каждая транзакция видит данные в состоянии, согласованном относительно её выполнения.
+
+**Преимущества 2PL**
+- **Сериализуемость транзакций**. Обеспечивает корректность выполнения операций.
+- **Гарантированная изоляция**. Исключаются конфликты между транзакциями.
+
+**Недостатки 2PL**
+- **Ожидание блокировок**. Транзакция может быть вынуждена ждать, пока другие транзакции освободят ресурсы.
+- Возможность [[deadlock]]. Две или более транзакции могут заблокировать друг друга, ожидая освобождения ресурсов.
+***
+## Мета информация
+**Область**:: [[../../meta/zero/00 Разработка|00 Разработка]]
+**Родитель**:: [[Блокировка]]
+**Источник**:: 
+**Автор**:: 
+**Создана**:: [[2024-06-20]]
+### Дополнительные материалы
+- [Two-phase locking - Wikipedia](https://en.wikipedia.org/wiki/Two-phase_locking)
+### Дочерние заметки
+<!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
--- a/dev/fundamental/Атомарная
+++ b/dev/fundamental/Атомарная
@ -1,11 +1,10 @@
 ---
-aliases: 
+aliases:
+  - атомарность операции
+  - атомарность операций
 tags:
  - maturity/🌱
 date: 2024-10-12
-zero-link: 
-parents: 
-linked:
 ---
 Операция атомарная, если невозможно наблюдать частичный результат ее выполнения. Любой наблюдатель видит либо состояние системы до атомарной операции, либо после

@ -13,6 +12,10 @@ linked:
 - Запись в поле типа boolean, byte, short, char, int, Object всегда атомарна
 - Запись в поле типа long/double: атомарна запись старших и младших 32 бит
 - Запись в поле типа long/double, объявленное volatile, атомарна
+
+**Подходы:**
+- [[Two-Phase Commit|Two-Phase Commit]]
+- [[../../../../_inbox/Transactional Inbox|Transactional Inbox]]
 ***
 ## Мета информация
 **Область**:: [[../../meta/zero/00 Разработка|00 Разработка]]
--- a/dev/fundamental/Блокировка.md
+++ b/dev/fundamental/Блокировка.md
@ -52,5 +52,5 @@ linked:
 ### Дочерние заметки
 <!-- QueryToSerialize: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
 <!-- SerializedQuery: LIST FROM [[]] WHERE contains(Родитель, this.file.link) or contains(parents, this.file.link) -->
- [[Two Phase Lock]]
+- [[Two-Phase Locking]]
 <!-- SerializedQuery END -->
--- a/dev/other/Race
+++ b/dev/other/Race
@ -8,9 +8,6 @@ tags:
  - maturity/🌱
 date:
  - - 2024-06-19
-zero-link: 
-parents: 
-linked:
 ---
 Состояние гонки возникает, когда два или более потока одновременно пытаются получить доступ к одному и тому же ресурсу (например, переменной), причём хотя бы один поток изменяет его значение. В таких случаях порядок выполнения потоков не гарантирован, что приводит к непредсказуемому поведению программы. Например, один поток может записывать данные, в то время как другой — читать, что вызывает некорректные результаты.

--- a/meta/zero/00
+++ b/meta/zero/00
@ -10,6 +10,7 @@ aliases:
  - высоконагруженная система
  - высоконагруженных систем
  - систем с высокой нагрузкой
+  - высокой нагрузкой
 ---
 ## Что такое HighLoad?
 Например, один запрос в секунду – это нагрузка явно не highload, любой сервер, вроде бы, справится. Но, например, если он перекодирует видеоролики, то тут может наступить highload.
--- a/meta/zero/00
+++ b/meta/zero/00
@ -27,6 +27,8 @@ aliases:
 - [[00 HighLoad|HighLoad]]

 - [[../../dev/architecture/Протоколы коммуникаций|Протоколы коммуникаций]]
+
+- [[../../dev/architecture/Интеграция информационных систем|Интеграция информационных систем]]
 ## Заметки
 - На проекте вести архитектурные карты, где указаны связи между сервисами
 ## Полезное
--- a/данных.md
+++ b/данных.md
@ -9,6 +9,7 @@ aliases:
  - базу данных
  - Реляционная база данных
  - базами данных
+  - базы данных
 linked:
  - "[[../../../../_inbox/00 In-memory СуБД|00 In-memory СуБД]]"
 ---