Всем привет! Мы снова сосредоточимся на проблеме распределенных транзакций. В предыдущей статье мы подробно рассмотрели схему двухфазной фиксации (2PC). Однако двухфазная фиксация также имеет свои ограничения, такие как необходимость в очень надежном координаторе и возможность блокировки системы в случае сбоя координатора. Итак, есть ли другие решения этой проблемы? Ответ — да, это компенсационные транзакции, также известные как режим Саги. Сегодня давайте вместе рассмотрим этот план.

1. Что такое компенсационная транзакция (режим Saga)?

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

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

2. Как работает режим Саги?

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

Например, у нас есть сага, содержащая три транзакции T1, T2 и T3 и соответствующие компенсационные транзакции C1, C2 и C3. Если T1 и T2 успешны, а T3 терпят неудачу, мы выполняем C2 и C1, чтобы отменить эффекты T1 и T2.

3. Преимущества и недостатки режима Саги

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

недостаток：ноSagaШаблоны также имеют свои ограничения。первый,Для каждого дела необходимо определить соответствующие компенсационные дела.,Это увеличивает сложность разработки. Во-вторых,Поскольку режим Saga обрабатывает неудачную транзакцию путем отката выполненной транзакции.,Поэтому в некоторых случаях,Производительность в реальном времени не может быть гарантирована.,Потому что операция отката может занять много времени.

4. Происхождение саги

Слово «Сага» изначально было формой повествования в Северной Европе. Обычно оно используется для описания приключений героев или истории королевской семьи. Хотя эти события или истории являются полными. по отдельности они все являются неотъемлемой частью повествования.

В контексте баз данных и распределенных систем термин «Сага» был впервые введен Гектором Гарсиа-Молиной и Кеннетом Салемом в их статье 1987 года «Концепция саги в системах длинных транзакций». По их определению, сага — это длинная транзакция, состоящая из серии более коротких субтранзакций (которые можно понимать как шаги или операции). Эти субтранзакции могут быть независимо зафиксированы в базе данных. Если сага не может завершиться успешно (например, из-за сбоя одной из субтранзакций), уже выполненные субтранзакции можно откатить с помощью серии компенсирующих транзакций (компенсирующих транзакций).

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

5. Резюме

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

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