Шаблон распределенных транзакций Saga

Azure

Обеспечение согласованности данных в распределенных системах путем координации последовательности локальных транзакций в нескольких службах. Каждая служба выполняет свою операцию и запускает следующий шаг через события или сообщения. Если шаг завершается сбоем, ряд компенсирующих транзакций отменяет внесенные изменения.

Контекст и проблема

транзакция представляет единицу работы, которая может включать несколько операций. В рамках транзакции событие ссылается на изменение состояния, которое влияет на сущность. Команда инкапсулирует все сведения, необходимые для выполнения действия или запуска последующего события.

Транзакции должны соответствовать принципам атомарности, согласованности, изоляции и устойчивости (ACID).

• Атомарность: либо все операции выполняются успешно, либо ни одна не выполняется.
• Согласованность: Данные переходят из одного допустимого состояния в другое допустимое состояние.
• Изоляция: Параллельные транзакции дают те же результаты, что и последовательные транзакции.
• Долговечность: Изменения сохраняются после их фиксации даже при возникновении сбоев.

В одной службе транзакции следуют принципам ACID, так как они работают в одной базе данных. Однако обеспечить соответствие требованиям ACID в нескольких сервисах может быть сложнее.

Проблемы в архитектуре микрослужб

Архитектуры микрослужб обычно назначают выделенную базу данных каждой микрослужбе. Этот подход обеспечивает несколько преимуществ:

• Каждая служба инкапсулирует собственные данные.
• Каждая служба может использовать наиболее подходящую технологию базы данных и схему для конкретных потребностей.
• Базы данных для каждой службы можно масштабировать независимо.
• Сбои в одной службе изолированы от других служб.

Несмотря на эти преимущества, эта архитектура усложняет согласованность данных между службами. Традиционные гарантии базы данных, такие как ACID, напрямую не применимы к нескольким независимым управляемым хранилищам данных. Из-за этих ограничений для шаблона Saga часто лучше подходят архитектуры, которые опираются на межпроцессное взаимодействие или традиционные модели транзакций, такие как протокол двухфазной фиксации.

Решение

Шаблон Saga управляет транзакциями, разбив их в последовательность локальных транзакций.

Каждая локальная транзакция:

1. Выполняет свою работу атомарно в рамках одной службы.
2. Обновляет базу данных службы.
3. Инициирует следующую транзакцию через событие или сообщение.

Если локальная транзакция завершается ошибкой, сага выполняет ряд компенсирующих транзакций, чтобы отменить изменения, внесенные предыдущими локальными транзакциями.

Основные понятия в шаблоне Saga

• компенсируемые транзакции могут быть отменены или компенсируются другими транзакциями с противоположным эффектом. Если шаг саги завершается с ошибкой, компенсирующие транзакции отменяют изменения, внесенные компенсируемыми транзакциями.

• Поворотные транзакции служат точкой невозврата в саге. После успешного завершения опорной транзакции компенсирующие транзакции больше не имеют значения. Все последующие действия необходимо выполнить для того, чтобы система достигла согласованного окончательного состояния. Опорная транзакция может выполнять разные роли, в зависимости от хода саги:

  • Необратимые транзакции или транзакции, не подлежащие компенсации, нельзя отменить или повторно выполнить.

  • Граница между обратимой и подтверждённой означает, что опорная транзакция может быть последней транзакцией, которую можно отменить или компенсировать. Или это может быть первой операцией в саге, допускающей повторную попытку.

• Повторные транзакции следуют за опорной транзакцией. Повторные транзакции являются идемпотентными и помогают гарантировать, что сага может достичь окончательного состояния, даже если возникают временные сбои. Они помогают саге в конечном итоге достичь согласованного состояния.

Подходы к реализации Saga

Два типичных подхода к реализации саги — это хореография и оркестрация. Каждый подход имеет собственный набор проблем и технологий для координации рабочего процесса.

Хореография

В подходе к хореографии службы обмениваются событиями без централизованного контроллера. При использовании хореографии каждая локальная транзакция публикует события домена, которые активируют локальные транзакции в других службах.

Преимущества хореографии	Недостатки хореографии
Хорошо подходит для простых рабочих процессов, имеющих несколько служб и не нуждающихся в логике координации.	Рабочий процесс может быть запутан при добавлении новых шагов. Трудно отслеживать, на какие команды отвечает каждый участник саги.
Для координации не требуется никакой другой службы.	Существует риск циклической зависимости между участниками саги, так как они должны обрабатывать команды друг друга.
Не создает единую точку отказа, так как обязанности распределены между участниками саги.	Тестирование интеграции сложно, так как все службы должны выполняться для имитации транзакции.

Оркестровка

В оркестрации централизованный контроллер или оркестратор, обрабатывает все транзакции и сообщает участникам, какие операции выполнять на основе событий. Оркестратор выполняет запросы saga, хранит и интерпретирует состояния каждой задачи и обрабатывает восстановление сбоев с помощью компенсирующих транзакций.

Преимущества оркестрации	Недостатки оркестрации
Лучше подходит для сложных рабочих процессов или при добавлении новых служб.	Для другой сложности проектирования требуется реализация логики координации.
Избегает циклических зависимостей, так как оркестратор управляет потоком.	Представляет точку сбоя, так как оркестратор управляет полным рабочим процессом.
Четкое разделение обязанностей упрощает логику службы.

Проблемы и рекомендации

При принятии решения о том, как реализовать этот шаблон, учитывайте следующие моменты:

• Изменение подхода к проектированию: внедрение паттерна Saga требует иного образа мышления. Для этого необходимо сосредоточиться на координации транзакций и согласованности данных в нескольких микрослужбах.

• Сложность отладки саг: Отладка саг может быть сложной, особенно по мере роста числа участвующих служб.

• необратимые изменения локальной базы данных: невозможно откатить данные, так как участники saga фиксируют изменения в соответствующих базах данных.

• Обработка временных сбоев и идемпотентность: Система должна эффективно обрабатывать временные сбои и обеспечивать идемпотентность, когда повторение одной и той же операции не изменяет результат. Дополнительные сведения см. в разделе Идемпотентная обработка сообщений.

• Необходимость мониторинга и отслеживания саг: Мониторинг и отслеживание процесса выполнения саги — важнейшие задачи для поддержания операционного контроля.

• Ограничения компенсирующих транзакций: компенсирующие транзакции могут не всегда выполняться успешно, что может оставить систему в несогласованном состоянии.

Потенциальные аномалии данных в сагах

Аномалии данных — это несоответствия, которые могут возникать, когда саги работают в нескольких сервисах. Так как каждая служба управляет собственными данными, называемыми данными участников, встроенная изоляция между службами отсутствует. Эта настройка может привести к несоответствиям данных или проблемам устойчивости, таким как частично примененные обновления или конфликты между службами. К типичным проблемам относятся:

• Потерянные обновления: Когда одна сага изменяет данные без учета изменений, внесенных другой сага, это приводит к перезаписи или отсутствующим обновлениям.

• Грязные считывания: Когда сага или транзакция считывает данные, измененные другой сагой, но эти изменения еще не завершены.

• Нечёткие или неповторяемые чтения: Когда разные шаги в саге считывают несогласованные данные, поскольку обновления происходят между чтениями.

Стратегии устранения аномалий данных

Чтобы уменьшить или предотвратить эти аномалии, рассмотрите следующие контрмеры:

• Семантическая блокировка: Используйте блокировки уровня приложения, когда компенсационная транзакция саги использует семафор, чтобы указать, что обновление находится в процессе.

• Коммутативные обновления: разрабатывайте обновления так, чтобы их можно было применять в любом порядке, получая один и тот же результат. Такой подход помогает уменьшить конфликты между сагами.

• Пессимистичный вариант: Измените порядок шагов саги так, чтобы обновления данных выполнялись в транзакциях с возможностью повтора, чтобы исключить грязное чтение. В противном случае одна сага может считывать грязные данные или незафиксированные изменения, в то время как другая сага одновременно выполняет компенсируемую транзакцию, чтобы откатить внесённые ею обновления.

• перечитанные значения: Убедитесь, что данные остаются неизменными перед обновлением. Если данные изменились, остановите текущий шаг и при необходимости перезапустите сагу.

• файлы версий: сохранить журнал всех операций, выполняемых в записи, и убедитесь, что они выполняются в правильной последовательности, чтобы предотвратить конфликты.

• Параллелизм на основе ценности с учётом риска: Динамически выбирайте подходящий механизм параллелизма исходя из потенциального бизнес-риска. Например, используйте sagas для обновлений с низким риском и распределенных транзакций для обновлений высокого риска.

Когда следует использовать этот шаблон

Используйте этот шаблон, когда:

• Необходимо обеспечить согласованность данных в распределенной системе без жесткой связи.
• Если не удаётся выполнить одну из операций в этой последовательности, необходимо выполнить откат или компенсацию.

Этот шаблон может быть не подходит, если:

• Транзакции тесно связаны.
• Компенсационные транзакции происходят у предыдущих участников.
• Существуют циклические зависимости.

Следующий шаг

• Облачные шаблоны данных

Связанные ресурсы

При реализации этого шаблона могут быть важны следующие шаблоны:

• В шаблоне «Хореография» каждый компонент системы участвует в процессе принятия решений о ходе бизнес-транзакции вместо того, чтобы полагаться на центральную точку управления.

• Шаблон компенсирующих транзакций отменяет работу, выполняемую рядом шагов, и в конечном итоге определяет согласованную операцию, если один или несколько шагов завершается ошибкой. Облачные приложения, реализующие сложные бизнес-процессы и рабочие процессы, часто следуют этому конечной модели согласованности.

• Шаблон повторных попыток позволяет приложению обрабатывать временные сбои при попытке подключиться к службе или сетевому ресурсу путем прозрачного повторения неудачной операции. Этот шаблон может повысить стабильность приложения.

• Шаблон Circuit Breaker pattern обрабатывает сбои, восстановление после которых может занимать разное время, при подключении к удалённой службе или ресурсу. Этот шаблон может повысить стабильность и устойчивость приложения.

• Шаблон мониторинга конечных точек работоспособности реализует в приложении функциональные проверки, к которым внешние средства могут обращаться через опубликованные конечные точки через регулярные промежутки времени. Этот шаблон поможет проверить правильность работы приложений и служб.

Обеспечение согласованности данных в распределенных системах путем координации последовательности локальных транзакций в нескольких службах. Каждая служба выполняет свою операцию и запускает следующий шаг через события или сообщения. Если шаг завершается сбоем, ряд компенсирующих транзакций отменяет внесенные изменения.

Контекст и проблема

транзакция представляет единицу работы, которая может включать несколько операций. В рамках транзакции событие ссылается на изменение состояния, которое влияет на сущность. Команда инкапсулирует все сведения, необходимые для выполнения действия или запуска последующего события.

Транзакции должны соответствовать принципам атомарности, согласованности, изоляции и устойчивости (ACID).

• Атомарность: либо все операции выполняются успешно, либо ни одна не выполняется.
• Согласованность: Данные переходят из одного допустимого состояния в другое допустимое состояние.
• Изоляция: Параллельные транзакции дают те же результаты, что и последовательные транзакции.
• Долговечность: Изменения сохраняются после их фиксации даже при возникновении сбоев.

В одной службе транзакции следуют принципам ACID, так как они работают в одной базе данных. Однако обеспечить соответствие требованиям ACID в нескольких сервисах может быть сложнее.

Проблемы в архитектуре микрослужб

Архитектуры микрослужб обычно назначают выделенную базу данных каждой микрослужбе. Этот подход обеспечивает несколько преимуществ:

• Каждая служба инкапсулирует собственные данные.
• Каждая служба может использовать наиболее подходящую технологию базы данных и схему для конкретных потребностей.
• Базы данных для каждой службы можно масштабировать независимо.
• Сбои в одной службе изолированы от других служб.

Несмотря на эти преимущества, эта архитектура усложняет согласованность данных между службами. Традиционные гарантии базы данных, такие как ACID, напрямую не применимы к нескольким независимым управляемым хранилищам данных. Из-за этих ограничений для шаблона Saga часто лучше подходят архитектуры, которые опираются на межпроцессное взаимодействие или традиционные модели транзакций, такие как протокол двухфазной фиксации.

Решение

Шаблон Saga управляет транзакциями, разбив их в последовательность локальных транзакций.

Каждая локальная транзакция:

1. Выполняет свою работу атомарно в рамках одной службы.
2. Обновляет базу данных службы.
3. Инициирует следующую транзакцию через событие или сообщение.

Если локальная транзакция завершается ошибкой, сага выполняет ряд компенсирующих транзакций, чтобы отменить изменения, внесенные предыдущими локальными транзакциями.

Основные понятия в шаблоне Saga

• компенсируемые транзакции могут быть отменены или компенсируются другими транзакциями с противоположным эффектом. Если шаг саги завершается с ошибкой, компенсирующие транзакции отменяют изменения, внесенные компенсируемыми транзакциями.

• Поворотные транзакции служат точкой невозврата в саге. После успешного завершения опорной транзакции компенсирующие транзакции больше не имеют значения. Все последующие действия необходимо выполнить для того, чтобы система достигла согласованного окончательного состояния. Опорная транзакция может выполнять разные роли, в зависимости от хода саги:

  • Необратимые транзакции или транзакции, не подлежащие компенсации, нельзя отменить или повторно выполнить.

  • Граница между обратимой и подтверждённой означает, что опорная транзакция может быть последней транзакцией, которую можно отменить или компенсировать. Или это может быть первой операцией в саге, допускающей повторную попытку.

• Повторные транзакции следуют за опорной транзакцией. Повторные транзакции являются идемпотентными и помогают гарантировать, что сага может достичь окончательного состояния, даже если возникают временные сбои. Они помогают саге в конечном итоге достичь согласованного состояния.

Подходы к реализации Saga

Два типичных подхода к реализации саги — это хореография и оркестрация. Каждый подход имеет собственный набор проблем и технологий для координации рабочего процесса.

Хореография

В подходе к хореографии службы обмениваются событиями без централизованного контроллера. При использовании хореографии каждая локальная транзакция публикует события домена, которые активируют локальные транзакции в других службах.

Преимущества хореографии	Недостатки хореографии
Хорошо подходит для простых рабочих процессов, имеющих несколько служб и не нуждающихся в логике координации.	Рабочий процесс может быть запутан при добавлении новых шагов. Трудно отслеживать, на какие команды отвечает каждый участник саги.
Для координации не требуется никакой другой службы.	Существует риск циклической зависимости между участниками саги, так как они должны обрабатывать команды друг друга.
Не создает единую точку отказа, так как обязанности распределены между участниками саги.	Тестирование интеграции сложно, так как все службы должны выполняться для имитации транзакции.

Оркестровка

В оркестрации централизованный контроллер или оркестратор, обрабатывает все транзакции и сообщает участникам, какие операции выполнять на основе событий. Оркестратор выполняет запросы saga, хранит и интерпретирует состояния каждой задачи и обрабатывает восстановление сбоев с помощью компенсирующих транзакций.

Преимущества оркестрации	Недостатки оркестрации
Лучше подходит для сложных рабочих процессов или при добавлении новых служб.	Для другой сложности проектирования требуется реализация логики координации.
Избегает циклических зависимостей, так как оркестратор управляет потоком.	Представляет точку сбоя, так как оркестратор управляет полным рабочим процессом.
Четкое разделение обязанностей упрощает логику службы.

Проблемы и рекомендации

При принятии решения о том, как реализовать этот шаблон, учитывайте следующие моменты:

• Изменение подхода к проектированию: внедрение паттерна Saga требует иного образа мышления. Для этого необходимо сосредоточиться на координации транзакций и согласованности данных в нескольких микрослужбах.

• Сложность отладки саг: Отладка саг может быть сложной, особенно по мере роста числа участвующих служб.

• необратимые изменения локальной базы данных: невозможно откатить данные, так как участники saga фиксируют изменения в соответствующих базах данных.

• Обработка временных сбоев и идемпотентность: Система должна эффективно обрабатывать временные сбои и обеспечивать идемпотентность, когда повторение одной и той же операции не изменяет результат. Дополнительные сведения см. в разделе Идемпотентная обработка сообщений.

• Необходимость мониторинга и отслеживания саг: Мониторинг и отслеживание процесса выполнения саги — важнейшие задачи для поддержания операционного контроля.

• Ограничения компенсирующих транзакций: компенсирующие транзакции могут не всегда выполняться успешно, что может оставить систему в несогласованном состоянии.

Потенциальные аномалии данных в сагах

Аномалии данных — это несоответствия, которые могут возникать, когда саги работают в нескольких сервисах. Так как каждая служба управляет собственными данными, называемыми данными участников, встроенная изоляция между службами отсутствует. Эта настройка может привести к несоответствиям данных или проблемам устойчивости, таким как частично примененные обновления или конфликты между службами. К типичным проблемам относятся:

• Потерянные обновления: Когда одна сага изменяет данные без учета изменений, внесенных другой сага, это приводит к перезаписи или отсутствующим обновлениям.

• Грязные считывания: Когда сага или транзакция считывает данные, измененные другой сагой, но эти изменения еще не завершены.

• Нечёткие или неповторяемые чтения: Когда разные шаги в саге считывают несогласованные данные, поскольку обновления происходят между чтениями.

Стратегии устранения аномалий данных

Чтобы уменьшить или предотвратить эти аномалии, рассмотрите следующие контрмеры:

• Семантическая блокировка: Используйте блокировки уровня приложения, когда компенсационная транзакция саги использует семафор, чтобы указать, что обновление находится в процессе.

• Коммутативные обновления: разрабатывайте обновления так, чтобы их можно было применять в любом порядке, получая один и тот же результат. Такой подход помогает уменьшить конфликты между сагами.

• Пессимистичный вариант: Измените порядок шагов саги так, чтобы обновления данных выполнялись в транзакциях с возможностью повтора, чтобы исключить грязное чтение. В противном случае одна сага может считывать грязные данные или незафиксированные изменения, в то время как другая сага одновременно выполняет компенсируемую транзакцию, чтобы откатить внесённые ею обновления.

• перечитанные значения: Убедитесь, что данные остаются неизменными перед обновлением. Если данные изменились, остановите текущий шаг и при необходимости перезапустите сагу.

• файлы версий: сохранить журнал всех операций, выполняемых в записи, и убедитесь, что они выполняются в правильной последовательности, чтобы предотвратить конфликты.

• Параллелизм на основе ценности с учётом риска: Динамически выбирайте подходящий механизм параллелизма исходя из потенциального бизнес-риска. Например, используйте sagas для обновлений с низким риском и распределенных транзакций для обновлений высокого риска.

Когда следует использовать этот шаблон

Используйте этот шаблон, когда:

• Необходимо обеспечить согласованность данных в распределенной системе без жесткой связи.
• Если не удаётся выполнить одну из операций в этой последовательности, необходимо выполнить откат или компенсацию.

Этот шаблон может быть не подходит, если:

• Транзакции тесно связаны.
• Компенсационные транзакции происходят у предыдущих участников.
• Существуют циклические зависимости.

Следующий шаг

• Облачные шаблоны данных

Связанные ресурсы

При реализации этого шаблона могут быть важны следующие шаблоны:

• В шаблоне «Хореография» каждый компонент системы участвует в процессе принятия решений о ходе бизнес-транзакции вместо того, чтобы полагаться на центральную точку управления.

• Шаблон компенсирующих транзакций отменяет работу, выполняемую рядом шагов, и в конечном итоге определяет согласованную операцию, если один или несколько шагов завершается ошибкой. Облачные приложения, реализующие сложные бизнес-процессы и рабочие процессы, часто следуют этому конечной модели согласованности.

• Шаблон повторных попыток позволяет приложению обрабатывать временные сбои при попытке подключиться к службе или сетевому ресурсу путем прозрачного повторения неудачной операции. Этот шаблон может повысить стабильность приложения.

• Шаблон Circuit Breaker pattern обрабатывает сбои, восстановление после которых может занимать разное время, при подключении к удалённой службе или ресурсу. Этот шаблон может повысить стабильность и устойчивость приложения.

• Шаблон мониторинга конечных точек работоспособности реализует в приложении функциональные проверки, к которым внешние средства могут обращаться через опубликованные конечные точки через регулярные промежутки времени. Этот шаблон поможет проверить правильность работы приложений и служб.