[Анализ и проектирование систем, Высокая производительность, Программирование, Промышленное программирование] Паттерн «сага» как способ обеспечения консистентности данных
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Всем привет. Уже сейчас в OTUS открывает набор в новую группу курса «Highload Architect». В связи с этим я продолжаю серию своих публикаций, написанных специально для этого курса, а также приглашаю вас на свой бесплатный демо урок по теме: «Индексы в MySQL: best practices и подводные камни». Записаться на вебинар можно тут.
Введение
Как известно, переход от монолита к микросервисной архитектуре вызывает ряд сложностей, связанных как с технической частью проекта, так и с человеческим фактором. Одной из самых сложных технических проблем вызывает обеспечение согласованности в распределенной системе.
В прошлый раз мы обсудили причины возникновения проблем с согласованностью в микросервисной архитектуре, оптимистичный подход в обеспечению согласованности и обеспечение согласованности с применением двухфазного коммита.
Паттерн «Сага»
Сага — это механизм, обеспечивающий согласованность данных в микросервисной архитектуры без применения распределенных транзакций.
Для каждой системной команды, которой надо обновлять данные в нескольких сервисах, создается некоторая сага. Сага представляет из себя некоторый «чек-лист», состоящий из последовательных локальных ACID-транзакций, каждая из которых обновляет данные в одном сервисе. Для обработки сбоев применяется компенсирующая транзакция. Такие транзакции выполняются в случае сбоя на всех сервисах, на которых локальные транзакции выполнились успешно.
Типов транзакций в саге несколько, целых четыре:
- Компенсирующая — отменяет изменение, сделанное локальной транзакцией.
- Компенсируемая — это транзакция, которую необходимо компенсировать (отменить) в случае, если последующие транзакции завершаются неудачей.
- Поворотная — транзакция, опеределяющая успешность всей саги. Если она выполняется успешно, то сага гарантированно дойдет до конца.
- Повторяемая — идет после поворотной и гарантированно завершается успехом.
Организовывать сагу можно с помощью хореографии или оркестрации.
В случае с хореографической саги выделенный оркестратор отсутствует. На примере сервиса заказов и пользователей она может выглядеть так: сервис заказов получает запрос и создает заказ в состоянии PENDING, а затем публикует событие «Заказ создан». Обработчик событий в сервисе пользователей обрабатывает данное событие, пытается зарезервировать товар и публикует результат в виде события. Сервис заказов обрабывает данное событие, подтверждая или отменяя заказ в зависимости от прочитанного результата.
Сага с оркестрацией выглядит чуть более интересно. На примере указанных выше сервисов может получиться так: сервис заказов получает запрос, создает сагу, которая создает заказ в состоянии PENDING, а затем отправляет команду резервирования товара для сервиса пользователей. Сервис пользователей пытается зарезервировать товар и отправляет ответное сообщение с указанием результата. Сага одобряет или отменяет заказ.
Паттерн «сага» позволяет приложению поддерживать согласованность данных между нескольких сервисов без использования распределенных транзакций (двухфазных коммитов) и с избежанием проблем, обсужденных в предыдущей статье. Но с другой стороны, сильно осложняется модель программирования: например, разработчик для каждой транзакции должен писать компенсирующую транзакцию, которая отменяет изменения, сделанные внутри саги ранее.
Сага позволяет добиться ACD-модели (Atomicity + Consistency + Durability в терминах ACID), но одну букву мы потеряли. Недостаток буквы I приводит к известным проблемам недостатка изолированности. К ним относятся: потерянные обновления (lost updates) — одна сага перезаписывает изменения, внесенные другой, не читая их при этом, «грязное чтение» (dirty reads) — транзакция или сага читают незавершенные обновления другой саги, нечеткое/неповторяемое чтение (fuzzy/nonrepeatable reads) — два разных этапа саги читают одни и те же данные, но получают разные результаты, потому что другая сага внесла изменения. Существует ряд паттернов, позволяющих пофиксить те или иные аномалии: семантическая блокировка, коммутативные обновления, пессимистическое представление, повторное чтение значения, файл изменений и по значению. Вопрос обеспечения изоляции остается открытым.
Еще одна интересная проблема заключается в невозможности атомарных обновления базы данных и публикации сообщения в брокер сообщений для запуска дальнейших шагов саги.
Заключение
Мы поговорили о способах организации саги с применением хореографии и оркестрации, а также о проблемах, которые влечет применения данного паттерна. Далее мы поговорим о способах исправления некоторых аномалий и транзакционной отправки сообщений в брокер сообщений.
оригинал
===========
Источник:
habr.com
===========
Похожие новости:
- [Ненормальное программирование, Ruby, Программирование] Программирование только классами (перевод)
- [Высокая производительность, Венчурные инвестиции, Распределённые системы, Криптовалюты] Взгляд изнутри на строительство компании в Кремниевой долине
- [Высокая производительность, Компьютерное железо, Настольные компьютеры, Процессоры] Объем или частота, сколько нужно оперативной памяти в 2020 году?
- [C++, Программирование] C++20. Coroutines
- [Python, Анализ и проектирование систем] Многоканальные массовые рассылки на Redis
- [Программирование, Конференции, Научно-популярное] Core Dump — видео канал о компьютерной науке
- [Карьера в IT-индустрии, Программирование] Украденное резюме, человек, который ушел в Кемерово, призыв кандидата и другие «увлекательные» истории трэш-собеседовани
- [Swift, Программирование, Разработка мобильных приложений, Разработка под iOS] Виджеты в iOS 14 – возможности и ограничения
- [Программирование, Разработка под iOS, Разработка мобильных приложений] Формальные грамматики на службе мобильного клиента
- [Анализ и проектирование систем, Высокая производительность, Промышленное программирование, Распределённые системы] Выбор архитектурного стиля (часть 2)
Теги для поиска: #_analiz_i_proektirovanie_sistem (Анализ и проектирование систем), #_vysokaja_proizvoditelnost (Высокая производительность), #_programmirovanie (Программирование), #_promyshlennoe_programmirovanie (Промышленное программирование), #_bazy (базы), #_dannyh (данных), #_2pl, #_dvuhfaznye (двухфазные), #_blokirovki (блокировки), #_xa, #_cassandra, #_mongo, #_mongodb, #_kafka, #_rabbit, #_rabbitmq, #_acid, #_atomicity, #_saga (сага), #_2pc, #_service, #_based, #_mikroservisy (микросервисы), #_soglasovannost (согласованность), #_consistency, #_isolation, #_durability, #_izoljatsija (изоляция), #_tranzaktsii (транзакции), #_arhitektura (архитектура), #_proizvoditelnost (производительность), #_vysokaja (высокая), #_nagruzka (нагрузка), #_highload, #_rollback, #_commit, #_phase, #_lock, #_raspredelennye (распределенные), #_blog_kompanii_otus._onlajnobrazovanie (
Блог компании OTUS. Онлайн-образование
), #_analiz_i_proektirovanie_sistem (
Анализ и проектирование систем
), #_vysokaja_proizvoditelnost (
Высокая производительность
), #_programmirovanie (
Программирование
), #_promyshlennoe_programmirovanie (
Промышленное программирование
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 06:21
Часовой пояс: UTC + 5
Автор | Сообщение |
---|---|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
Всем привет. Уже сейчас в OTUS открывает набор в новую группу курса «Highload Architect». В связи с этим я продолжаю серию своих публикаций, написанных специально для этого курса, а также приглашаю вас на свой бесплатный демо урок по теме: «Индексы в MySQL: best practices и подводные камни». Записаться на вебинар можно тут. Введение Как известно, переход от монолита к микросервисной архитектуре вызывает ряд сложностей, связанных как с технической частью проекта, так и с человеческим фактором. Одной из самых сложных технических проблем вызывает обеспечение согласованности в распределенной системе. В прошлый раз мы обсудили причины возникновения проблем с согласованностью в микросервисной архитектуре, оптимистичный подход в обеспечению согласованности и обеспечение согласованности с применением двухфазного коммита. Паттерн «Сага» Сага — это механизм, обеспечивающий согласованность данных в микросервисной архитектуры без применения распределенных транзакций. Для каждой системной команды, которой надо обновлять данные в нескольких сервисах, создается некоторая сага. Сага представляет из себя некоторый «чек-лист», состоящий из последовательных локальных ACID-транзакций, каждая из которых обновляет данные в одном сервисе. Для обработки сбоев применяется компенсирующая транзакция. Такие транзакции выполняются в случае сбоя на всех сервисах, на которых локальные транзакции выполнились успешно. Типов транзакций в саге несколько, целых четыре:
Организовывать сагу можно с помощью хореографии или оркестрации. В случае с хореографической саги выделенный оркестратор отсутствует. На примере сервиса заказов и пользователей она может выглядеть так: сервис заказов получает запрос и создает заказ в состоянии PENDING, а затем публикует событие «Заказ создан». Обработчик событий в сервисе пользователей обрабатывает данное событие, пытается зарезервировать товар и публикует результат в виде события. Сервис заказов обрабывает данное событие, подтверждая или отменяя заказ в зависимости от прочитанного результата. Сага с оркестрацией выглядит чуть более интересно. На примере указанных выше сервисов может получиться так: сервис заказов получает запрос, создает сагу, которая создает заказ в состоянии PENDING, а затем отправляет команду резервирования товара для сервиса пользователей. Сервис пользователей пытается зарезервировать товар и отправляет ответное сообщение с указанием результата. Сага одобряет или отменяет заказ. Паттерн «сага» позволяет приложению поддерживать согласованность данных между нескольких сервисов без использования распределенных транзакций (двухфазных коммитов) и с избежанием проблем, обсужденных в предыдущей статье. Но с другой стороны, сильно осложняется модель программирования: например, разработчик для каждой транзакции должен писать компенсирующую транзакцию, которая отменяет изменения, сделанные внутри саги ранее. Сага позволяет добиться ACD-модели (Atomicity + Consistency + Durability в терминах ACID), но одну букву мы потеряли. Недостаток буквы I приводит к известным проблемам недостатка изолированности. К ним относятся: потерянные обновления (lost updates) — одна сага перезаписывает изменения, внесенные другой, не читая их при этом, «грязное чтение» (dirty reads) — транзакция или сага читают незавершенные обновления другой саги, нечеткое/неповторяемое чтение (fuzzy/nonrepeatable reads) — два разных этапа саги читают одни и те же данные, но получают разные результаты, потому что другая сага внесла изменения. Существует ряд паттернов, позволяющих пофиксить те или иные аномалии: семантическая блокировка, коммутативные обновления, пессимистическое представление, повторное чтение значения, файл изменений и по значению. Вопрос обеспечения изоляции остается открытым. Еще одна интересная проблема заключается в невозможности атомарных обновления базы данных и публикации сообщения в брокер сообщений для запуска дальнейших шагов саги. Заключение Мы поговорили о способах организации саги с применением хореографии и оркестрации, а также о проблемах, которые влечет применения данного паттерна. Далее мы поговорим о способах исправления некоторых аномалий и транзакционной отправки сообщений в брокер сообщений. оригинал =========== Источник: habr.com =========== Похожие новости:
Блог компании OTUS. Онлайн-образование ), #_analiz_i_proektirovanie_sistem ( Анализ и проектирование систем ), #_vysokaja_proizvoditelnost ( Высокая производительность ), #_programmirovanie ( Программирование ), #_promyshlennoe_programmirovanie ( Промышленное программирование ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 06:21
Часовой пояс: UTC + 5