Резюме статьи: Саги

Feb 16 2023
Х. Гарсия-Молина и К.
Фото Натана Райли на Unsplash

Х. Гарсия-Молина и К. Салем. 1987. Саги . В материалах международной конференции ACM SIGMOD 1987 г. по управлению данными (SIGMOD '87). Ассоциация вычислительной техники, Нью-Йорк, штат Нью-Йорк, США, 249–259.

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

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

Введение

В своей статье «Саги» Гектор Гарсия-Молина и Кеннет Салем вводят концепцию саг для реализации «длительных» операций.

Молина и Салем называют процессы, состоящие из одного шага, «краткосрочными» или «короткоживущими», а процессы, состоящие из нескольких шагов, — «длительными» или «долгоживущими». Таким образом, короткое или длительное время — это не утверждение о физическом времени, а утверждение о логическом времени, где каждый шаг представляет собой такт часов (рис. 1).

Рис. 1. Краткосрочные и долгосрочные

Проблема

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

В документе процесс P определяется как последовательность шагов a, b и т. д., где каждый шаг представляет собой транзакцию базы данных. Используя более привычные термины, вы можете думать о процессе как о функции, а о последовательности шагов — как о последовательности вызовов API к базе данных.

Мы называем последовательность шагов a, b и т. д. трассировкой:

trace(P) = a • b • …

Другими словами: последовательность из двух транзакций не является транзакцией!

Рисунок 2. Последовательная композиция двух транзакций сама по себе транзакцией не является.

Проще говоря, если процесс состоит из одной транзакции, он демонстрирует гарантии атомарности транзакции (рис. 3).

Рис. 3. Процесс P состоит из одного шага a

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

Рис. 4. Процесс P состоит из двух шагов a и b

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

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

Решение

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

Рисунок 5. Восстановление назад и вперед

Чтобы смягчить частичное выполнение, процесс может реализовать прямое или обратное восстановление [2]:

Восстановление вперед

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

Обратное восстановление

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

Обратное восстановление и компенсация

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

Рисунок 6. Транзакция sᵢ и компенсация cᵢ

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

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

Исполнение

Таким образом, при отсутствии сбоев процесс P создает желаемую трассировку.

trace(P) = s₁ • s₂ • … sₙ • ✔️

trace(P) = s₁ • s₂ • … sᵢ • × • cᵢ … • c₂ • c₁ • ✔️

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

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

Обсуждение

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

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

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

Заключение

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

Рекомендации