Изменить

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

Azure

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

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

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

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

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

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

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

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

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

Решение

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

Общие сведения о Saga.

В шаблонах Saga:

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

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

Хореография

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

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

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

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

Недостатки

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

Оркестрация

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

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

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

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

Недостатки

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

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

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

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

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

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

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

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

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

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

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

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

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

Пример

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

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

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

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