Изменить

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

Azure

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

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

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

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

В архитектурах с несколькими службами:

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

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

Распределенные транзакции, такие как протокол двухфазной фиксации (2PC), требуют от всех участников транзакции фиксации или отката перед продолжением транзакции. Однако некоторые реализации участников, такие как базы данных NoSQL и брокер сообщений, не поддерживают эту модель.

Другим ограничением распределенных транзакций является синхронизация и доступность межпроцессного взаимодействия (IPC ). IPC, предоставляемый операционной системой, позволяет отдельным процессам совместно использовать данные. Для фиксации распределенных транзакций все участвующие службы должны быть доступны, что может снизить общую доступность системы. Архитектурные реализации с ограничениями IPC или транзакций являются кандидатами на использование шаблона Saga.

Решение

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

Общие сведения о Сага.

В шаблонах Saga:

  • Компилируемые транзакции — это транзакции, которые потенциально могут быть отменены путем обработки другой транзакции с противоположным эффектом.
  • Сводная транзакция — это точка go/no-go в саге. Если транзакция сводных данных фиксируется, сага выполняется до завершения. Сводная транзакция может быть транзакцией, которая не поддается ни компенсации, ни повторной, либо это может быть последняя комплируемая транзакция или первая повторная транзакция в саге.
  • Повторяемые транзакции — это транзакции, которые следуют за сводной транзакцией и гарантированно будут успешно выполнены.

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

Хореография

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

Общие сведения о хореографии

Преимущества

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

Недостатки

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

Оркестрация

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

Общие сведения об оркестрации

Преимущества

  • Хорошо подходит для сложных рабочих процессов с участием большого количества участников или новых участников, добавленных с течением времени.
  • Подходит, когда есть контроль над каждым участником процесса, и контроль над потоком действий.
  • Не вводит циклических зависимостей, так как оркестратор в одностороннем порядке зависит от участников саги.
  • Участникам Saga не нужно знать о командах для других участников. Четкое разделение задач упрощает бизнес-логику.

Недостатки

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

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

При реализации шаблона Saga учитывайте следующие моменты:

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

Следующие аномалии могут произойти без надлежащих мер:

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

Предлагаемые контрмеры по сокращению или предотвращению аномалий включают:

  • Семантическая блокировка— блокировка на уровне приложения, в которой комплемируемая транзакция саги использует семафор, чтобы указать, что выполняется обновление.
  • Коммутативные обновления , которые могут выполняться в любом порядке и дают одинаковый результат.
  • Пессимистичное представление: Одна сага может считывать грязные данные, а другая — выполнять комплемируемую транзакцию для отката операции. Пессимистичное представление изменяет порядок саги, чтобы базовые данные обновлялись в повторяемой транзакции, что исключает возможность "грязного" чтения.
  • Значение повторного чтения проверяет, что данные не изменяются, а затем обновляет запись. Если запись была изменена, шаги прервулись, и сага может перезапуститься.
  • Файл версии записывает операции с записью по мере их поступления, а затем выполняет их в правильном порядке.
  • По значению использует бизнес-риск каждого запроса для динамического выбора механизма параллелизма. Запросы с низким риском используют саги, а запросы с высоким риском — распределенные транзакции.

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

Используйте шаблон Saga в следующих случаях:

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

Шаблон Saga менее подходит для следующих целей:

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

Пример

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

Дальнейшие действия

Следующие шаблоны также могут быть полезными при реализации этого шаблона:

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