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

Деловая сцена

Простое и абстрактное описание бизнес-сценария: имеется четыре модуля A, B, C и D, где B, C и D — нижестоящие сервисы, а A — вышестоящий вызывающий сервис. Запрос поступает из внешнего интерфейса и входит в A. A должен записать запрос и сохранить его в базе данных, затем последовательно вызвать службы B и C и асинхронно вызвать службу D. После завершения вызова запрос в база обновляется.

В сценарии электронной коммерции, с которым мы наиболее знакомы, это следующие шаги:

Пользователь размещает заказ на платформе заказов
вести учет запасов
счет за деньги
создать заказ

Как показано ниже:

Распределенные системы

Прежде чем говорить о более подробных бизнес-сценариях, давайте взглянем на картинку выше. На приведенном выше рисунке показано простое представление распределенного приложения, которое разделяет бизнес электронной коммерции на несколько сервисов. В сценарии вызова распределенного приложения часто встречается"Аномальная сетевая связь","Исключение узла сервера",четное"Сервер не работает"сцена. Есть поговорка, что в распределенных приложениях будет больше аномальных сценариев, чем вы думаете, и они будут происходить чаще.

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

Распределенные системы имеют следующие"Функции":

"Высокая доступность": в случае, если один или несколько серверных узлов вышли из строя или даже вышли из строя, система по-прежнему доступна, а несколько узлов развертываются с распределенной избыточностью для обеспечения высокой доступности.
"высокая производительность": в случае одной машины такие факторы, как ЦП и память машины, могут легко стать узким местом производительности.В случае распределенного развертывания с несколькими машинами высокая производительность может быть достигнута за счет разделения служб и развертывания нескольких машин.
"Сильная масштабируемость": когда количество посещений увеличивается и увеличивается потребность в хранилище, один или несколько серверов оказываются слабыми. В это время вы можете отреагировать, добавив серверы в кластер серверов.
"Сильная масштабируемость": Необходимо различать масштабируемость и масштабируемость.Масштабируемость основана на базовом оборудовании, а масштабируемость для бизнеса, то есть она удобна для нового расширения бизнеса или разделения бизнеса. И вообще он модульный, поэтому его проще расширять и повторно использовать модули. Бизнес разделен, и эффективность развития также будет повышена.

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

согласованность данных

Мы часто слышим во многих статьях"последовательность"Этот термин упоминается при использовании базы данных"ACID"C в нем для согласованности, распределенной системы"теория CAP"C внутри также непротиворечив, так в чем разница между ними? Что мы подразумеваем под последовательностью здесь сегодня? Далее у нас хороший разговор.

ACID

ACID относится к четырем характеристикам, которые должны быть удовлетворены, чтобы гарантировать правильность и надежность транзакции при записи или обновлении базы данных."A (атомарность), C (согласованность), I (изоляция), D (долговечность)". Давайте пока отложим остальные три функции. Под согласованностью здесь подразумевается согласованность транзакций. Другие три функции, как я понимаю, в конечном счете служат этой согласованности. Согласованность здесь относится к переходу системы из одного правильного состояния в другое правильное состояние до и после транзакции.

Что вызвано"правильное состояние"Шерстяная ткань? Чтобы привести простой пример, на счетах A и B есть по 100 юаней, и A переводит 50 юаней B. После перевода счет A становится 50 юаней, а счет B становится 150 юаней.Это правильное состояние. Если А переводит 100 юаней Б в это время, то счет А становится -50 юаней, а счет Б становится 250 юаней, тогда это неправильное состояние. В этом примере, если это становится состоянием ошибки, транзакцию необходимо откатить, что является непротиворечивостью транзакции. Вообще говоря, эта согласованность может быть гарантирована ограничениями базы данных, но чаще бизнес-логика более сложна, и уровень логики кода должен быть ограничен и гарантирован.

CAP

Теория CAP обычно используется в распределенных системах, соответственно CAP"C (непротиворечивость), A (доступность), P (допуск разделения)"Теория CAP считает, что в распределенной системе эти три свойства могут одновременно удовлетворять только двум. Под согласованностью данных мы подразумеваем именно эту согласованность.Эта согласованность и согласованность транзакций в ACID совсем не одно и то же.Не путайте их.

"последовательность": все копии данных в распределенной системе имеют одно и то же значение в одно и то же время.
"Доступность": Когда один или несколько узлов в кластере распределенной системы выходят из строя, клиентские запросы на чтение и запись все равно будут отвечать.
"Допуск перегородки": Когда узлы в кластере не могут взаимодействовать друг с другом или система не может достичь согласованности данных в течение определенного срока, это означает, что происходит разделение. Раздел по-прежнему доступен после его создания, то есть допуск раздела.

Тогда почему одновременно могут быть удовлетворены только два из них?Во-первых, если вы хотите соблюсти допуск по разделам, вам нужно сделать несколько копий, но как только копий будет больше, согласованность будет нарушена, синхронизация данных будет занимает больше времени, и данные Если синхронизация занимает слишком много времени, это повлияет на доступность.Он может быть недоступен в течение определенного периода времени.В то же время допуск разделения не может быть полностью удовлетворен из-за более длительного времени для достижения последовательность. Это можно резюмировать так:

"Удовлетворяет C\A, но не удовлетворяет P", то есть не требуется никакого раздела, количество узлов ограничено, то есть отказывается от масштабируемости системы, что противоречит распределенным характеристикам.Обычно в этой схеме используются традиционные базы данных, такие как Oracle и Mysql.
"Познакомьтесь с C \ P a не удовлетворены", доступность не требуется, а требуется согласованность, то есть данные всех копий должны быть согласованы, а разделение может привести к значительному увеличению времени синхронизации данных.В этом сценарии приносится в жертву удобство работы пользователя и пользователь может только ждать, пока все данные не будут согласованы. Обычно распределенные базы данных используют эту схему.
"Удовлетворяет A\P, но не удовлетворяет C", то согласованность не требуется.После того, как раздел будет создан и останется доступным, каждый узел будет предоставлять службы с локально сохраненными данными, чтобы пользователи могли получить доступ к данным с истекшим сроком действия. В этом случае пользовательский интерфейс будет немного затронут, но высокая доступность не заблокирует процесс.

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

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

На этот раз в нашем бизнес-сценарии вызовы вышестоящей службы A к службам B, C и D должны обеспечивать непротиворечивость конечных данных. Для служб B и C они вызываются синхронно.Если во время вызова службы произошел сбой, транзакция будет отброшена напрямую. Для асинхронных вызовов службы D можно допустить долгосрочную несогласованность данных, введенную до окончательной согласованности."Мягкое состояние (промежуточное состояние)"В качестве временного состояния, когда результат асинхронного вызова не вернулся, можно установить"Заказ формируется"статус.

Отказоустойчивость

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

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

сценарий успеха

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

сценарий отказа

Здесь показаны три сценария сбоя, для первых двух в случае сбоя необходимо выполнить откат:

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

Для третьего сценария отказа есть еще несколько вариантов:

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

Сценарий тайм-аута/исключения

Существуют различные причины тайм-аутов,"Дрожание сети, сбой узла сервера, сбой узла сервера", когда есть тайм-аут, программисты всегда лихорадочно ищут причину. Кроме того, с тайм-аутами связана еще одна трудность, из-за которой особенно легко вызвать несоответствия в состоянии: когда служба А вызывает службу Б и тайм-аут истекает, невозможно узнать, получил ли Б запрос. решения, нужно потребовать от B, чтобы достичь"идемпотент"или предоставить"Интерфейс запроса статуса", служба A обрабатывает ситуацию тайм-аута, повторяя попытку, или"принудительный откат"Чтобы справиться с тайм-аутом, но когда оба метода снова истекают, вам нужно вручную вмешаться в обработку.В это время вам необходимо зарезервировать методы ручной обработки, предоставленные эксплуатационному и обслуживающему персоналу.

Сценарий простоя

Внезапный сбой питания, выдергивание вилки или злонамеренное уничтожение процесса, приложение не выдерживает такого броска, и как только это происходит, состояние и данные, хранящиеся в памяти, исчезают. Если служба A успешно вызвала службу B, чтобы заморозить инвентарь в это время, и питание внезапно отключилось до вызова службы C, это неизбежно приведет к несогласованности данных по каждой услуге, инвентарь был вычтен, но деньги были не был вычтен из заказа. Если он не создан, не является ли это необъяснимым вычетом дополнительных запасов? Поэтому перед вызовом службы необходимо сохранить данные на месте, чтобы облегчить операцию отката после выключения и перезапуска.

После перезапуска системы будет запущен поток для чтения сохраненных данных на месте, и будет сделан откат на основе данных на месте, поэтому данные на месте должны содержать несколько частей информации:"Вызываемый модуль, переданные параметры, статус"(Определить, использовались ли данные для обработки отката, если был проведен откат, то он обрабатывается, в противном случае он находится в ожидании).

Вариант 1: ТСС

Вначале мы намерены использовать структуру TCC для реализации вызовов между микросервисами для решения вышеуказанных бизнес-сценариев. Так что же такое структура TCC?

ТСС на самом деле является первой буквой трех слов, а именно: пробовать, подтверждать, отменять, Можно сказать, что по буквальному смыслу можно догадаться. попытаться — попробовать, подтвердить — подтвердить, отменить — отменить. Это как если бы вы собирались пригласить нескольких друзей поесть раков ночью, а затем попросить нескольких друзей зарезервировать место, это попытка. Друг договорился о встрече, чтобы забронировать место, и ушел с работы в 5:30 вовремя, чтобы пойти на ужин.Это подтверждение. Поскольку вам приходится работать сверхурочно, чтобы исправить ошибку, или ваши друзья работают сверхурочно, или вы не получаете места, у вас не будет раков.

Без дальнейших церемоний мы будем использовать народные + диаграммы в сочетании с реальными бизнес-сценариями, чтобы все поняли.

нормальная логика

Этап 1: попробуй

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

Этап 2: подтвердить

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

"Первое"Если подтверждение выполнено успешно, то вызовы сервисов B и C завершаются, и сервисы согласуются с точки зрения данных.

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

Этап 3: отменить

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

Думай дальше

Говоря об этом, вы можете в основном знать, что такое структура TCC. В конкретной реализации можно выбрать фреймворк ТСС с открытым исходным кодом: ByteTCC, Himly, ТСС-транзакция, Seata и т.д. Или напишите сами, но детали реализации внутри рамок рукописного ввода пока очень сложны, как воспринимать выполнение каждого этапа, как протолкнуть его на следующий этап, как реализовать механизм повтора, сигнализацию, ручное вмешательство , и аварийный откат Подожди, подожди, подумай.

модификация интерфейса

Кроме того, если будет принята структура TCC, все службы должны принять структуру TCC единообразно. Для вызываемой стороны исходный интерфейс необходимо преобразовать в три интерфейса: попытка-подтверждение-отмена.

"пробная фаза"Необходимо реализовать замораживание и предварительное занятие данных, и в то же время необходимо сохранять запись вызова для трассировки данных и поддерживать идемпотентный механизм.
"подтвердить этап"Необходимо вычесть/увеличить замороженные и вытесненные данные и реализовать идемпотентный механизм для возврата одного и того же результата в случае нескольких вызовов (обычно результат подтверждения успешен. Как правило, время ожидания вызова истекает, и его необходимо Если явно возвращается результат сбоя, велика вероятность ручного вмешательства или допускается откат в зависимости от ситуации).
"отменить фазу"Данные, которые необходимо разморозить и вытеснить, то есть операция отката, вызываемый объект откатывается к вызываемому, и данные непротиворечивы. Точно так же для отмены необходимо реализовать идемпотентный механизм: повторная попытка разрешена в случае тайм-аута, а ручное вмешательство, вероятно, потребуется в случае явного возврата ошибочного результата.

идемпотентный механизм

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

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

Другая обработка исключений

Кроме того, мы рассмотрели только различные сценарии, в которых вызываемый объект возвращает результат на вышеуказанных этапах, но если мы скажем"Произошло исключение в вызывающей системе", то его тоже нужно обрабатывать по ситуации:

"в пробной фазе"Произошла ошибка/исключение/тайм-аут, и их необходимо отменить и выполнить откат. Здесь необходимо рассмотреть два особых случая:
- "Вызываемый абонент получил отмену, но не получил попытку": в это время вызываемому объекту не нужно выполнять какую-либо обработку, потому что нет попытки, т. е."Пустой откат";
- "Вызываемый получил отмену, а затем получил попытку": в это время вызываемому объекту необходимо выполнить пустой откат предыдущей отмены, идентифицировать последующую попытку и признать, что процесс отмены был обработан, поэтому вызов попытки больше не будет обрабатываться, что также называется"Контроль подвески";
- Пустой контроль отката и предотвращения приостановки обычно также можно реализовать путем введения таблиц управления транзакциями;
"На этапах подтверждения и отмены"Исключение необходимо повторить или требуется ручное вмешательство;
если"подтвердить, что фаза завершена"Если возникает исключение, рассмотрите возможность отката в зависимости от ситуации. Например, если исключение возникает в асинхронном вызове, можно рассмотреть механизм повторных попыток. Если работа базы данных ненормальна, скорее всего, потребуется откат назад.

Еще один момент, который мы уже рассматривали в сценарии даунтаймов: если даунтайм происходит, необходимо сохранить данные на месте, а также сохранить статус каждого этапа транзакционного каркаса ТСС.

PS: Подумайте, как мы можем обеспечить высокую доступность системы через структуру TCC в производственной среде? Вместо частого ручного вмешательства? Основной метод, принятый автором на практике, основан на реализации высокодоступного промежуточного ПО MQ, такого как kafka или rabbitMq, заинтересованные друзья также могут узнать о нем самостоятельно.

Вариант 2: Сага

По мнению автора, фреймворк Saga - это фреймворк TCC без подтверждения, но он не очень точен, т.к. попытка саги - это уже не попытка, нет упреждения и заморозки данных, а данные напрямую вычитаются/ Увеличивать.

Теория саги исходит из статьи Sagas, опубликованной Hector & Kenneth 1987, основной идеей которой является компенсационное соглашение:

"компенсационное соглашение": в режиме Saga в распределенной транзакции участвует несколько участников, и каждый участник представляет собой услугу положительной компенсации. на картинке вышеT1~Tnто есть"переадресация вызова",C1~Cnда"Вызов компенсации", существует однозначное соответствие между вызовами переадресации и вызовами компенсации. Предположим, что есть n вызываемых сервисов,T1это звонок в сервис один, а потомT2Это вызов на сторону обслуживания 2, а T3 — это вызов на сторону обслуживания 3. Если в это время возвращается сбой, то необходимо выполнить откат, и в это время будет выполнен вызов.T2соответствующая компенсацияC2,передачаT1соответствующая компенсацияC1, чтобы распределенная транзакция вернулась в исходное состояние.

Применимые сценарии Saga

Сага - это"Решения для длинных транзакций", что больше подходит для"Длинный бизнес-процесс и множество бизнес-процессов"место действия;
Если участниками службы являются другие компании или унаследованные системные службы, а три интерфейса в режиме TCC в настоящее время не могут быть предоставлены, необходимо использовать Saga;
Типичная бизнес-система: система стыковки финансового учреждения (необходимо стыковать с внешними системами), интеграция каналов (долгий процесс), службы распределенной архитектуры;
Банковские и финансовые учреждения используются более широко;

Сходства и различия между Saga и TCC

Из приведенного выше утверждения вы должны подумать, что Saga не очень похожа на TCC? Если рождается TCC, то почему рождается Saga? На самом деле у них все же есть отличия, в основном отраженные в разных сценариях применения.

изоляция данных

Вернемся к нашему бизнес-сценарию. Служба A вызывает службы B и C, если происходит следующее:

1) Попытка службы B успешна, но попытка службы C не удалась;
2) В это время есть пользователи для чтения данных службы B и службы C;
3) А, В, С откатиться назад;

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

Для TCC попытка — это просто замороженная операция, поэтому она работает только с «замороженным полем», которое не влияет на фактические данные, запрашиваемые пользователем, поэтому может возвращать правильные результаты.

Для Saga try — это прямая операция над данными, которая изменит данные, к которым пользователь хочет получить доступ, а затем в это время вернет пользователю грязные данные. Будут грязные чтения, значит данные во фреймворке Saga есть"изоляция"проблемы.

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

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

двухступенчатые и одноступенчатые

Из приведенного выше описания Saga в основном не хватает изоляции по сравнению с TCC, причина в том, что TCC — это двухэтапная транзакция фиксации, а Saga — одноэтапная транзакция фиксации.

Для ТСС,"первый этап"Ресурс будет вытеснен, а ресурс будет заблокирован."второй этап"ресурсы используются или высвобождаются.

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

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

Суммировать

"структура УТС"

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

"кадр саги"

Он подходит для сценариев, когда интерфейс нельзя изменить;
Существуют проблемы с изоляцией данных, которые могут вызвать такие проблемы, как грязные данные, потерянные обновления и нечеткое чтение;
Одноэтапная отправка транзакций, без блокировок, подходит для бизнес-логики длительного процесса;
Подходит для управляемого событиями асинхронного выполнения с более высокой пропускной способностью;
В сценариях, где компенсация не удалась, требуется дополнительная обработка исключений, например ручное вмешательство;

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

Простая реализация фреймворка Saga

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

Основной метод реализации заключается в добавлении в код бизнес-процесса@SagaTransactionalАннотация, реализующая обработку отката захвата исключений в коде процесса внутри аннотации.
Определить общую структуру сообщенияSagaAction, структура содержит информацию, которую необходимо удалить из таблицы управления транзакциями Saga ("Идентификатор транзакции, Тип службы, Идентификатор службы, Идентификатор нижестоящей системы, Отправить сообщение о пересылке информации о системе нижестоящего уровня, Отправить сообщение о компенсации информации о системе нижестоящего уровня, Статус транзакции"), и может"Индивидуальная операционная идентификация", такие как откат вручную (применимо к сценариям, требующим отката без создания исключения), механизм обработки тайм-аута (вы можете настроить повторную отправку или откат после тайм-аута) и механизм обработки исключений (вы можете настроить, следует ли повторно отправить или откат после исключения). roll) и т.д.
будет выполняться при каждом запросе"постоянные записи базы данных", чтобы обеспечить возможность нормального отката или повторного запуска системы путем считывания информации из базы данных после того, как система не работает.
поставка"нижний механизм", Зарегистрируйте механизм нижней строки в начале бизнес-процесса.После создания исключения инфраструктура Saga автоматически выполнит обработку отката.После завершения отката выполняется итоговая программа, которая в основном используется для изменения промежуточного констатировать или обеспечить согласованность данных.
поставка"Механизм исключения обработки транзакций Saga", при сбое компенсации или ненормальном тайм-ауте последующие операции можно настроить, в том числе"Ручное вмешательство и автоматическая ретрансляция сигналов тревоги"Ждать.

Обзор

Подводя итог, я кратко зафиксировал изучение и практику фреймворков TCC и Saga в рабочем процессе, сначала представил соответствующие теории распределенных систем, а затем сосредоточился на бизнес-сценариях и реализации распределенных транзакций TCC и Saga. процесс, каждый Вы можете выбрать в соответствии с вашими потребностями и условиями бизнеса. Из соображений конфиденциальности исходный код не может быть предоставлен, а демо-версия будет написана для ознакомления позже.Если вы найдете какие-либо ошибки, пожалуйста, исправьте их!

Ссылаться на:

https://www.sofastack.tech/blog/sofa-meetup-3-seata-retrospect/