From 6d52584f953532e46c408b694e9919f4c09e3d38 Mon Sep 17 00:00:00 2001 From: Struchkov Mark Date: Fri, 17 Jan 2025 15:29:17 +0300 Subject: [PATCH] =?UTF-8?q?=D0=9E=D0=B1=D0=BD=D0=BE=D0=B2=D0=BB=D0=B5?= =?UTF-8?q?=D0=BD=D0=B8=D0=B5?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- dev/architecture/CAP теорема.md | 6 +- dev/architecture/Change Data Capture.md | 56 ++++++++++++++++ dev/architecture/Database per service.md | 2 +- dev/architecture/Event Sourcing.md | 2 +- dev/architecture/Transactional Outbox.md | 4 +- .../Горизонтальное масштабирование.md | 2 +- .../highload/Групповая репликация.md | 2 +- .../highload/Монотонное чтение.md | 4 +- dev/architecture/Архитектурный паттерн.md | 6 ++ dev/architecture/Еventual consistency.md | 22 +++++++ dev/architecture/Идемпотентность.md | 2 + dev/architecture/Избыточность данных.md | 2 +- .../Интеграция информационных систем.md | 24 +++++++ ...правка сообщений в Kafka из транзакции БД.md | 16 +++-- dev/architecture/Распределенная транзакция.md | 3 +- .../Событийно-ориентированная архитектура.md | 5 ++ dev/architecture/Согласованность данных.md | 55 ++++++++++++++++ dev/fundamental/Deadlock.md | 2 +- dev/fundamental/MESI.md | 2 +- dev/fundamental/Two-Phase Commit.md | 64 +++++++++++++++++++ dev/fundamental/Two-Phase Locking.md | 50 +++++++++++++++ dev/fundamental/Атомарная операция.md | 11 ++-- dev/fundamental/Блокировка.md | 2 +- dev/other/Race condition.md | 3 - meta/zero/00 HighLoad.md | 1 + meta/zero/00 Архитектура ИС.md | 2 + meta/zero/00 Реляционная база данных.md | 1 + 27 files changed, 323 insertions(+), 28 deletions(-) create mode 100644 dev/architecture/Change Data Capture.md create mode 100644 dev/architecture/Еventual consistency.md create mode 100644 dev/architecture/Интеграция информационных систем.md create mode 100644 dev/architecture/Согласованность данных.md create mode 100644 dev/fundamental/Two-Phase Commit.md create mode 100644 dev/fundamental/Two-Phase Locking.md diff --git a/dev/architecture/CAP теорема.md b/dev/architecture/CAP теорема.md index d37e1303..33ceb3b5 100644 --- a/dev/architecture/CAP теорема.md +++ b/dev/architecture/CAP теорема.md @@ -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 теорему. *** diff --git a/dev/architecture/Change Data Capture.md b/dev/architecture/Change Data Capture.md new file mode 100644 index 00000000..dde73866 --- /dev/null +++ b/dev/architecture/Change Data Capture.md @@ -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]] +**Автор**:: +### Дополнительные материалы +- + +### Дочерние заметки + + diff --git a/dev/architecture/Database per service.md b/dev/architecture/Database per service.md index b3f400ad..7b76bbcc 100644 --- a/dev/architecture/Database per service.md +++ b/dev/architecture/Database per service.md @@ -24,7 +24,7 @@ date: 2024-11-24 Лучшие практики - **Чёткие границы владения данными**. Определите чёткие границы владения данными для каждого сервиса, - [[Bounded Context|Ограниченный контекст]]. Это помогает избежать пересечений и зависимостей между сервисами, а также упрощает управление данными. - [[Событийно-ориентированная архитектура|Событийно-ориентированная архитектура]]. Для обеспечения согласованности данных между микросервисами можно использовать события. Например, при изменении данных в одном сервисе он отправляет событие, на которое подписаны другие сервисы, которым эти данные могут быть нужны. -- **Реализация паттернов для согласованности**. Используйте паттерны, такие как [Saga](Реализация%20повествования%20(Saga).md), чтобы координировать действия между несколькими микросервисами и гарантировать согласованность данных без использования глобальных транзакций. +- **Реализация паттернов для согласованности**. Используйте паттерны, такие как [Saga](Реализация%20повествования%20(Saga).md), чтобы координировать действия между несколькими микросервисами и гарантировать [[согласованность данных]] без использования глобальных транзакций. - **API вместо прямого доступа к данным**. Доступ к данным одного микросервиса другими должен осуществляться только через публичные API. Это помогает соблюдать [[Инкапсуляция|инкапсуляцию]] и обеспечивает безопасное взаимодействие между сервисами. *** ## Мета информация diff --git a/dev/architecture/Event Sourcing.md b/dev/architecture/Event Sourcing.md index 1906e22f..0bb9ed3f 100644 --- a/dev/architecture/Event Sourcing.md +++ b/dev/architecture/Event Sourcing.md @@ -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 Архитектура ИС]] diff --git a/dev/architecture/Transactional Outbox.md b/dev/architecture/Transactional Outbox.md index 6f40d7d8..fdac3068 100644 --- a/dev/architecture/Transactional Outbox.md +++ b/dev/architecture/Transactional Outbox.md @@ -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]]) значительно упрощает архитектуру и позволяет избежать сложных механизмов блокировки. **Недостатки:** - **Дополнительная задержка**: отправка сообщений через фоновый процесс может вызвать небольшую задержку в доставке сообщений, по сравнению с немедленной отправкой. diff --git a/dev/architecture/highload/Горизонтальное масштабирование.md b/dev/architecture/highload/Горизонтальное масштабирование.md index 35db53db..1b831f6b 100644 --- a/dev/architecture/highload/Горизонтальное масштабирование.md +++ b/dev/architecture/highload/Горизонтальное масштабирование.md @@ -17,7 +17,7 @@ date: **Проблемы:** 1. **Сложность управления**: Управление множеством узлов и их координация может быть значительно сложнее, чем управление одним мощным сервером. Нужно делать балансировку вызовов. 2. **Сложность разработки**: Разработка приложений, способных эффективно использовать ресурсы в распределенной среде, может быть более сложной, а значит программисты обходятся дороже. -3. **Согласованность данных**: Обеспечение согласованности данных между множеством узлов может представлять собой вызов, особенно в системах, где требуется высокий уровень согласованности. +3. [[../Согласованность данных|Согласованность данных]]: Обеспечение согласованности данных между множеством узлов может представлять собой вызов, особенно в системах, где требуется высокий уровень согласованности. 4. **Затраты на сеть**: Горизонтальное масштабирование может повлечь за собой увеличенные затраты на сетевое оборудование и управление сетью, особенно если узлы географически распределены. Частные проблемы: diff --git a/dev/architecture/highload/Групповая репликация.md b/dev/architecture/highload/Групповая репликация.md index bf9920ff..3ba4e008 100644 --- a/dev/architecture/highload/Групповая репликация.md +++ b/dev/architecture/highload/Групповая репликация.md @@ -14,7 +14,7 @@ linked: - Все транзакции чтения и записи фиксируются только после того, как они были одобрены группой. - Read-only транзакции не требуют координации внутри группы и фиксируются немедленно -- Групповая репликация - eventual consistency система +- Групповая репликация - [[../Еventual consistency|Еventual consistency]] система ![](../../../meta/files/images/Pasted%20image%2020240605091036.png) diff --git a/dev/architecture/highload/Монотонное чтение.md b/dev/architecture/highload/Монотонное чтение.md index b7aa1691..9fa594de 100644 --- a/dev/architecture/highload/Монотонное чтение.md +++ b/dev/architecture/highload/Монотонное чтение.md @@ -1,5 +1,7 @@ --- -aliases: +aliases: + - Monotonic Read Consistency + - Monotonic Read tags: - maturity/🌱 date: diff --git a/dev/architecture/Архитектурный паттерн.md b/dev/architecture/Архитектурный паттерн.md index 2da88e69..a9f511c2 100644 --- a/dev/architecture/Архитектурный паттерн.md +++ b/dev/architecture/Архитектурный паттерн.md @@ -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]] diff --git a/dev/architecture/Еventual consistency.md b/dev/architecture/Еventual consistency.md new file mode 100644 index 00000000..c3660e92 --- /dev/null +++ b/dev/architecture/Еventual consistency.md @@ -0,0 +1,22 @@ +--- +aliases: + - Конечная согласованность + - eventual consistency +tags: + - maturity/🌱 +date: 2025-01-15 +--- + +*** +## Мета информация +**Область**:: [[../../meta/zero/00 Архитектура ИС|00 Архитектура ИС]] +**Родитель**:: [[Согласованность данных|Согласованность данных]] +**Источник**:: +**Создана**:: [[2025-01-15]] +**Автор**:: +### Дополнительные материалы +- + +### Дочерние заметки + + diff --git a/dev/architecture/Идемпотентность.md b/dev/architecture/Идемпотентность.md index 5f92b052..0a19c8d8 100644 --- a/dev/architecture/Идемпотентность.md +++ b/dev/architecture/Идемпотентность.md @@ -5,6 +5,8 @@ aliases: - идемпотентности - идемпотентную - идемпотентные + - Идемпотентные операции + - Idempotence tags: - maturity/🌱 date: 2024-09-11 diff --git a/dev/architecture/Избыточность данных.md b/dev/architecture/Избыточность данных.md index 8028fc4a..5be400c2 100644 --- a/dev/architecture/Избыточность данных.md +++ b/dev/architecture/Избыточность данных.md @@ -26,7 +26,7 @@ date: 2024-11-24 2. **Увеличение объёма хранилища**. Хранение данных в нескольких формах требует больше места в хранилище. Для высоконагруженных систем с большими объёмами данных это может стать значительным фактором. Лучшие практики для работы с избыточностью данных -1. **Продуманная архитектура синхронизации**. Используйте [[Событийно-ориентированная архитектура|событийную архитектуру]], чтобы поддерживать согласованность данных. Например, при добавлении нового сообщения можно отправить событие, которое обновит индекс последних сообщений. +1. **Продуманная архитектура синхронизации**. Используйте [[Событийно-ориентированная архитектура|событийную архитектуру]], чтобы поддерживать [[согласованность данных]]. Например, при добавлении нового сообщения можно отправить событие, которое обновит индекс последних сообщений. 2. **Оценка необходимости избыточности**. Вводите избыточность только там, где это действительно необходимо для повышения производительности или удобства работы. Не стоит избыточно усложнять систему там, где этого можно избежать. 3. **Мониторинг консистентности**. Внедряйте механизмы проверки и восстановления консистентности данных между копиями. Это поможет вовремя обнаружить и устранить расхождения. diff --git a/dev/architecture/Интеграция информационных систем.md b/dev/architecture/Интеграция информационных систем.md new file mode 100644 index 00000000..9449c7a4 --- /dev/null +++ b/dev/architecture/Интеграция информационных систем.md @@ -0,0 +1,24 @@ +--- +aliases: +tags: + - maturity/🌱 +date: 2025-01-13 +--- +Подходы: +- [[Change Data Capture]] +*** +## Мета информация +**Область**:: [[../../meta/zero/00 Архитектура ИС|00 Архитектура ИС]] +**Родитель**:: +**Источник**:: +**Создана**:: [[2025-01-13]] +**Автор**:: +### Дополнительные материалы +- + +### Дочерние заметки + + +- [[Change Data Capture]] + + diff --git a/dev/architecture/Отправка сообщений в Kafka из транзакции БД.md b/dev/architecture/Отправка сообщений в Kafka из транзакции БД.md index 214b4043..cce3315f 100644 --- a/dev/architecture/Отправка сообщений в Kafka из транзакции БД.md +++ b/dev/architecture/Отправка сообщений в Kafka из транзакции БД.md @@ -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 Архитектура ПО]] diff --git a/dev/architecture/Распределенная транзакция.md b/dev/architecture/Распределенная транзакция.md index 26db970a..5ab36b83 100644 --- a/dev/architecture/Распределенная транзакция.md +++ b/dev/architecture/Распределенная транзакция.md @@ -1,5 +1,6 @@ --- -aliases: +aliases: + - распределённой транзакции tags: - maturity/🌱 date: 2024-12-02 diff --git a/dev/architecture/Событийно-ориентированная архитектура.md b/dev/architecture/Событийно-ориентированная архитектура.md index 8d70e683..64193658 100644 --- a/dev/architecture/Событийно-ориентированная архитектура.md +++ b/dev/architecture/Событийно-ориентированная архитектура.md @@ -6,6 +6,7 @@ aliases: - Событийно-ориентированная архитектура - событийную архитектуру - Событийная архитектура + - событийных архитектур tags: - maturity/🌱 date: @@ -44,6 +45,10 @@ date: - [[Отправка сообщений в Kafka из транзакции БД]] - Можно читать бинлог и отправлять в [[Брокер сообщений]] - [[Transactional Outbox]]. Сохраняем события в БД, из которой события отправляются в [[Брокер сообщений]]. + +**Тип отправляемых данных:** +- [[Event Sourcing]]. Отправлять только те данные, которые изменились. +- Отправлять целиком актуальные данные. *** ## Мета информация **Область**:: [[../../meta/zero/00 Архитектура ИС|00 Архитектура ИС]] diff --git a/dev/architecture/Согласованность данных.md b/dev/architecture/Согласованность данных.md new file mode 100644 index 00000000..e0077096 --- /dev/null +++ b/dev/architecture/Согласованность данных.md @@ -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]] +**Автор**:: +### Дополнительные материалы +- + +### Дочерние заметки + + +- [[Еventual consistency]] +- [[Согласованность транзакции БД (Сonsistency)]] + + diff --git a/dev/fundamental/Deadlock.md b/dev/fundamental/Deadlock.md index f9c4ce7b..1faa4e32 100644 --- 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) diff --git a/dev/fundamental/MESI.md b/dev/fundamental/MESI.md index 349c4eeb..b5fcbb91 100644 --- a/dev/fundamental/MESI.md +++ b/dev/fundamental/MESI.md @@ -14,7 +14,7 @@ linked: - **S (Shared)** — данные разделены между несколькими ядрами, и их копии синхронизированы с памятью. - **I (Invalid)** — данные в кэше недействительны, потому что они были изменены другим ядром или сброшены. -==Когда одно ядро изменяет данные в своем кэше, протокол MESI уведомляет другие ядра о том, что их копии этих данных больше не актуальны==. Это позволяет поддерживать согласованность данных между ядрами и предотвращает возможные ошибки. +==Когда одно ядро изменяет данные в своем кэше, протокол MESI уведомляет другие ядра о том, что их копии этих данных больше не актуальны==. Это позволяет поддерживать [[../architecture/Согласованность данных|согласованность данных]] между ядрами и предотвращает возможные ошибки. *** ## Мета информация diff --git a/dev/fundamental/Two-Phase Commit.md b/dev/fundamental/Two-Phase Commit.md new file mode 100644 index 00000000..e11ca53b --- /dev/null +++ b/dev/fundamental/Two-Phase Commit.md @@ -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]] +**Автор**:: +### Дополнительные материалы +- + +### Дочерние заметки + + diff --git a/dev/fundamental/Two-Phase Locking.md b/dev/fundamental/Two-Phase Locking.md new file mode 100644 index 00000000..ae7fdc65 --- /dev/null +++ b/dev/fundamental/Two-Phase Locking.md @@ -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) +### Дочерние заметки + diff --git a/dev/fundamental/Атомарная операция.md b/dev/fundamental/Атомарная операция.md index 3035d4ba..e2b4a345 100644 --- a/dev/fundamental/Атомарная операция.md +++ b/dev/fundamental/Атомарная операция.md @@ -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 Разработка]] diff --git a/dev/fundamental/Блокировка.md b/dev/fundamental/Блокировка.md index fa581d26..38b02d20 100644 --- a/dev/fundamental/Блокировка.md +++ b/dev/fundamental/Блокировка.md @@ -52,5 +52,5 @@ linked: ### Дочерние заметки -- [[Two Phase Lock]] +- [[Two-Phase Locking]] diff --git a/dev/other/Race condition.md b/dev/other/Race condition.md index 5d093053..34a52773 100644 --- a/dev/other/Race condition.md +++ b/dev/other/Race condition.md @@ -8,9 +8,6 @@ tags: - maturity/🌱 date: - - 2024-06-19 -zero-link: -parents: -linked: --- Состояние гонки возникает, когда два или более потока одновременно пытаются получить доступ к одному и тому же ресурсу (например, переменной), причём хотя бы один поток изменяет его значение. В таких случаях порядок выполнения потоков не гарантирован, что приводит к непредсказуемому поведению программы. Например, один поток может записывать данные, в то время как другой — читать, что вызывает некорректные результаты. diff --git a/meta/zero/00 HighLoad.md b/meta/zero/00 HighLoad.md index 5132bc48..84f28f24 100644 --- a/meta/zero/00 HighLoad.md +++ b/meta/zero/00 HighLoad.md @@ -10,6 +10,7 @@ aliases: - высоконагруженная система - высоконагруженных систем - систем с высокой нагрузкой + - высокой нагрузкой --- ## Что такое HighLoad? Например, один запрос в секунду – это нагрузка явно не highload, любой сервер, вроде бы, справится. Но, например, если он перекодирует видеоролики, то тут может наступить highload. diff --git a/meta/zero/00 Архитектура ИС.md b/meta/zero/00 Архитектура ИС.md index 074c4eba..6cfff5f1 100644 --- a/meta/zero/00 Архитектура ИС.md +++ b/meta/zero/00 Архитектура ИС.md @@ -27,6 +27,8 @@ aliases: - [[00 HighLoad|HighLoad]] - [[../../dev/architecture/Протоколы коммуникаций|Протоколы коммуникаций]] + +- [[../../dev/architecture/Интеграция информационных систем|Интеграция информационных систем]] ## Заметки - На проекте вести архитектурные карты, где указаны связи между сервисами ## Полезное diff --git a/meta/zero/00 Реляционная база данных.md b/meta/zero/00 Реляционная база данных.md index ee3f3caa..100d359b 100644 --- a/meta/zero/00 Реляционная база данных.md +++ b/meta/zero/00 Реляционная база данных.md @@ -9,6 +9,7 @@ aliases: - базу данных - Реляционная база данных - базами данных + - базы данных linked: - "[[../../../../_inbox/00 In-memory СуБД|00 In-memory СуБД]]" ---