文章首发于51CTO技术栈公众号
作者 陈彩华
文章转载交流请联系 caison@aliyun.com

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

Я считаю, что после терпеливого прочтения этой статьи, когда дело доходит до распределенных транзакций, больше нет просто «2PC», «3PC», «транзакция сообщения MQ», «согласованность в конечном счете», «TCC» и другие фрагменты знаний, но может Связать знания вместе, чтобы сформировать систему знаний.

1 Что такое сделка

Прежде чем представить распределенные транзакции, давайте сначала представим, что такое транзакции.

Конкретное определение транзакции

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

Проще говоря, транзакции обеспечивают «Либо ничего не делай, либо делай все (все или ничего)"механизм.

ACID-свойства транзакций базы данных

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

атомарностьВсе операции во всей транзакции либо завершены, либо не завершены, и нельзя застаиваться на каком-то звене посередине. Если во время выполнения транзакции возникает ошибка, она будет отброшена к состоянию до начала транзакции, как если бы транзакция никогда не выполнялась. Например: банковский перевод, перевод 100 юаней со счета A на счет B, делится на два этапа:
- (1) Снять 100 юаней со счета А
- (2) Внесите 100 юаней на счет B. Эти два шага либо выполняются вместе, либо не вместе.Если только первый шаг завершен, а второй не пройден, деньги необъяснимым образом уменьшатся на 100 юаней.
ПоследовательностьОграничения согласованности данных базы данных не нарушаются до начала транзакции и после ее завершения. Например: существующее ограничение целостности A+B=100, если транзакция изменяет A, B необходимо изменить так, чтобы A+B=100 по-прежнему выполнялось после завершения транзакции, иначе транзакция не будет выполнена.
ИзоляцияСпособность базы данных позволять нескольким параллельным транзакциям одновременно читать, записывать и изменять данные.Если данные, к которым должна получить доступ одна транзакция, изменяются другой транзакцией, пока другая незафиксированная транзакция не повлияет на доступ к нему. Изоляция может предотвратить несогласованность данных из-за перекрестного выполнения, когда несколько транзакций выполняются одновременно. Например, есть транзакция, которая переводит 100 юаней со счета A на счет B. Если эта транзакция не была завершена, если B в это время запрашивает свой собственный счет, он не увидит вновь добавленные 100 юаней.
ДолговечностьПосле завершения транзакции изменение данных является постоянным и не будет потеряно даже в случае сбоя системы.

Проще говоря, ACID описывает характеристики транзакций из разных измерений:

Атомарность — целостность транзакционных операций
Согласованность - правильность данных при транзакционных операциях
Изоляция - правильность данных при параллельных транзакционных операциях
Durability — надежность транзакций для модификаций данных.

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

Когда использовать транзакции базы данных

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

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

2 Что такое распределенная транзакция

После введения основных понятий, связанных с транзакциями, давайте познакомимся с распределенными транзакциями.

Предыстория и концепция распределенного поколения

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

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

В качестве примера возьмем обычный транзакционный бизнес в Интернете:

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

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

Сложности распределенных транзакций

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

3 Согласованность распределенных систем

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

Конфликт между доступностью и согласованностью — теория CAP

Теорема CAP, также известная как теорема Брюера, представляет собой гипотезу, предложенную Брюэром, ученым-компьютерщиком из Калифорнийского университета, в 2000 году. В 2002 году Сет Гилберт и Нэнси Линч из Массачусетского технологического института опубликовали доказательство гипотезы Брюэра, что сделало ее общепризнанной теоремой распределенных вычислений.

Брюэр специально не определял значение трех слов: согласованность, доступность и допуск на разделение, когда предлагал гипотезу CAP. Конкретные определения различных материалов также различаются. Для лучшего объяснения сделаны следующие выборки.Robert Greinerстатья«Теорема CAP»в качестве опорной базы.

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

Непротиворечивость, доступность и устойчивость к разделам объясняются следующим образом:

С - Консистенция

Чтение гарантированно возвращает самую последнюю запись для данного клиента. Для данного клиента операция чтения гарантированно возвращает последний результат операции записи.

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

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

А - Доступность

Исправный узел вернет разумный ответ в течение разумного периода времени (без ошибок или тайм-аута). Исправные узлы возвращают разумные ответы (не ошибки и тайм-ауты) в разумные сроки.

Упор здесь делается на разумный ответ, который не может быть отложен по времени и не может ошибаться. Обратите внимание, что он не говорит «правильный» результат, например, он должен был вернуть 100, но на самом деле вернул 90, конечно, не правильный результат, но может быть разумным результатом.

P - Допуск на перегородку Допуск на перегородку

Система будет продолжать функционировать при возникновении сетевых разделов. при появлениисетевой разделПосле этого система может продолжать «выполнять свои обязанности».

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

Варианты согласованности, доступности и допустимости разделов

Хотя теоретическое определение CAP состоит в том, что можно взять только два из трех элементов, но когда мы подумаем об этом в распределенной среде, мы обнаружим, что мы должны выбрать элемент P (допуск к разделению), потому что сама сеть не может быть 100% надежен и может дать сбой, так что разбиение на разделы — неизбежное явление.

Если мы выберем CA (согласованность + доступность) и откажемся от P (толерантность к разделам), то при возникновении явления разделения для обеспечения C (согласованности) системе необходимо запретить запись, а при наличии запроса на запись system Возвращает ошибку (например, текущая система не разрешает запись), которая снова конфликтует с A (доступность), поскольку A (доступность) не требует возврата ошибки и тайм-аута.

Следовательно, для распределенной системы теоретически невозможно выбрать архитектуру CA (согласованность + доступность),Можно выбрать только архитектуру CP (Consistency + Partition Tolerance) или AP (Availability + Partition Tolerance), что обеспечивает компромисс между согласованностью и доступностью..

CP — непротиворечивость + допуск на разделение

Как показано на рисунке выше, данные Node1 были обновлены до y из-за прерывания соединения между Node1 и Node2, но канал репликации между Node1 и Node2 прерван, и данные y не могут быть синхронизированы с Node2, и данные на Node2 все еще старые данные x.

В это время, когда клиент C обращается к узлу 2, узел 2 должен вернуть ошибку, сообщая клиенту, что «система обнаружила ошибку». Поддерживается требованиями доступности (наличия), поэтому три CAP могут соответствовать только CP.

AP — доступность + допуск на разделы

Это также данные на узле Node2 или старые данные x. В это время, когда клиент C обращается к Node2, Node2 возвращает клиенту текущие данные x, которыми он владеет. Фактически, последние данные уже являются y. Требования согласованности выполнены, поэтому три CAP могут удовлетворить только AP.

Примечание. Здесь узел Node2 возвращает x, хотя и не «правильный», но «разумный» результат, потому что x — это старые данные, а не беспорядочное значение, просто не самые последние данные.

Стоит добавить, что теория CAP говорит нам, чтоРаспределенные системы могут выбирать только AP или CP, но на самом деле это не означает, что вся система может выбирать только AP или CP.Когда теория CAP применяется на практике, нам необходимо классифицировать данные в системе в соответствии с различными сценариями и требованиями приложений и выбирать разные стратегии для каждого типа данных (CP или CP).AP), а не напрямую ограничивать всю систему одной и той же политикой для всех данных.

Кроме того, можно выбрать только CP или AP, что означает, что C (непротиворечивость) и A (доступность) не могут быть гарантированы одновременно при разделении системы, но это не означает, что ничего не делается. решена, системе по-прежнему необходимо поддерживать гарантию CA.

Расширение теории CAP — теория BASE

BASE относится к Basic Available, Soft State и Eventual Consistency.Основная идея заключается в том, что даже если строгая согласованность не может быть достигнута (согласованность CAP — это сильная согласованность), приложения могут использовать соответствующий способ для достижения конечной согласованности.

BA - В основном доступноПри сбое распределенной системы допускается потеря части доступности, то есть ядро гарантированно будет доступно.

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

S - Мягкое состояние Мягкое состояниеДопускается промежуточное состояние системы, не влияющее на общую доступность системы. Промежуточным состоянием здесь является несогласованность данных в теории CAP.
E - Возможная согласованностьВсе копии данных в системе в конечном итоге достигнут согласованного состояния через определенный период времени.

Ключевые слова здесь «некоторое время» и «в конце концов», «определенное время«Это тесно связано с характеристиками данных, и время несогласованности, которое могут допустить разные данные, различно для разных сервисов. Например, платежные услуги требуют согласованности в течение нескольких секунд, потому что пользователи всегда обращают внимание; последняя публикация Weibo, опубликованная пользователями, может допускать 30 Стабильное состояние достигается в течение нескольких минут, потому что пользователи не могут воспринимать микроблоги, размещенные знаменитостями в течение короткого времени.наконец-то«Смысл в том, что независимо от того, сколько времени это займет, в конечном итоге оно достигнет состояния согласованности.

BASE теория, по сути, является расширением и дополнением к CAP, точнее, дополнением к схеме AP в CAP:

Теория CAP игнорирует задержку, а задержка неизбежна в практических приложениях. Это означает, что идеального сценария CP не существует, даже при задержке репликации данных в несколько миллисекунд система не соответствует требованиям CP в течение этих временных интервалов в несколько миллисекунд. Таким образом, схема CP в CAP фактически обеспечивает окончательную согласованность, но «определенное время» относится к нескольким миллисекундам.
Пожертвование согласованностью в схеме AP относится только к моменту отказа раздела, а не к отказу от согласованности навсегда. На самом деле это то, в чем расширяется теория BASE: согласованность приносится в жертву во время разбиения на разделы, но после восстановления после сбоя раздела система должна достичь конечной согласованности.

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

Модель BASE представила ранее упомянутые «сильную согласованность» и «конечную согласованность», и эти модели согласованности представлены ниже.

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

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

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

гибкие дела

Концепция гибких транзакций

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

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

Реализовать некоторые функции гибких транзакций

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

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

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

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

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

4 распространенных решения для распределенных транзакций

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

Существует множество реализаций распределенных транзакций, среди которых более классическим является протокол распределенных транзакций XA, предложенный Tuxedo.Протокол XA включает в себя две реализации двухфазной фиксации (2PC) и трехфазной фиксации (3PC).

4.1 Схема 2PC (двухэтапная фиксация) — строгая согласованность

Введение в программу

Двухфазная фиксация (2PC) — это широко используемое решение для распределенных транзакций, то есть процесс фиксации транзакции делится на две фазы обработки: фазу подготовки и фазу фиксации. Инициатор сделки называется координатором, а исполнитель сделки – участником.

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

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

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

Поток обработки

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

Фаза 1: Фаза подготовки

1. Координатор отправляет содержимое транзакции всем участникам, спрашивает, можно ли отправить транзакцию, и ждет ответа от всех участников.

2. Каждый участник выполняет бизнес-операции и записывает информацию UNDO и REDO в журнал транзакций (но не отправляет транзакции).

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

Фаза 2: Фаза фиксацииЕсли координатор получает сообщение о сбое или тайм-ауте участника, он напрямую отправляет сообщение об откате каждому участнику; в противном случае он отправляет сообщение о фиксации; участник выполняет операцию фиксации или отката в соответствии с инструкциями координатора, Освобождает все ресурсы блокировки, использованные во время транзакции. обработка. (Примечание: ресурсы блокировки должны быть освобождены на финальном этапе) Далее процесс этапа представления обсуждается в двух случаях.

Случай 1, когда все участники отвечают да, фиксируют транзакцию:

1. Координатор отправляет формальный запрос на транзакцию (т.е. запрос на фиксацию) всем участникам.

2. Участник выполняет запрос фиксации и освобождает ресурсы, занятые в течение всей транзакции.

3. Каждый участник возвращает координатору сообщение о завершении подтверждения (ответа).

4. После того, как координатор получит сообщения подтверждения, отправленные всеми участниками, транзакция будет отправлена.

Случай 2, когда участник какой-либо фазы 1 возвращает нет, транзакция прерывается:

1. Координатор отправляет запрос на откат (т.е. запрос на откат) всем участникам.

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

3. Каждый участник возвращает координатору сообщение о завершении подтверждения.

4. После того, как координатор получит сообщения подтверждения, отправленные всеми участниками, транзакция прерывается.

Краткое содержание программы

Схема 2PC проста в реализации и редко используется в реальных проектах, в основном из-за следующих проблем:

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

4.2 Схема 3PC (трехэтапное обязательство)

Введение в программу

Протокол трехфазной фиксации — это улучшенная версия протокола двухфазной фиксации, отличающаяся от двухфазной фиксации механизмом тайм-аута. При этом как у координатора, так и у участников вводится механизм тайм-аута.

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

Поток обработки

Фаза 1: можно зафиксироватьКоординатор отправляет участнику запрос на фиксацию, а участник возвращает ответ yes, если участник может совершить фиксацию (участник не выполняет операцию транзакции), в противном случае возвращает ответ no:

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

2. После того, как участник получит запрос canCommit, если он считает, что транзакционная операция может быть выполнена, он вернет yes и войдет в состояние подготовки, иначе вернет no.

Фаза 2: предварительная фиксацияКоординатор решает, может ли выполняться операция preCommit на основе транзакции, в соответствии с реакцией участников фазы 1 canCommit. В зависимости от ответа возможны следующие две возможности.

Сценарий 1: все участники фазы 1 отвечают утвердительно, и участники предварительно выполняют транзакцию:

1. Координатор рассылает всем участникам preCommit запрос на переход в стадию подготовки.

2. После того, как участник получает запрос preCommit, выполняется транзакционная операция, и информация об отмене и повторе записывается в журнал транзакций (но транзакция не фиксируется).

3. Каждый участник возвращает ответ подтверждения или нет координатору и ожидает окончательной инструкции.

Случай 2: Любой участник Фазы 1 сообщает нет, или координатор не может получить обратную связь от всех участников после ожидания таймаута, то есть транзакция прерывается:

1. Координатор отправляет всем участникам запрос на прерывание.

2. Независимо от получения от координатора запроса на прерывание или тайм-аут ожидания запроса координатора, участник прервет транзакцию.

Фаза 3: сделайте коммитНа этом этапе выполняется реальная отправка транзакции, которую также можно разделить на следующие две ситуации:

Сценарий 1. Все участники фазы 2 отправляют ответные подтверждения и выполняют реальную фиксацию транзакции:

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

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

1. Если координатор работает, отправьте всем участникам запрос на прерывание.
2. Участник использует информацию об отмене в фазе 1 для выполнения операции отката и освобождения ресурсов, занятых в течение всей транзакции.
3. Каждый участник возвращает координатору сообщение о завершении подтверждения.
4. После того, как координатор получит сообщения подтверждения, отправленные всеми участниками, транзакция прерывается.

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

Краткое содержание программы

преимущество По сравнению с двухфазной фиксацией, трехфазная близость уменьшает диапазон блокировки, и координатор или участник прервет транзакцию после ожидания тайм-аута. Проблема единственной точки координатора исключена.Если координатор выйдет из строя на этапе 3, участники продолжат отправлять транзакции.
недостаток Проблема несогласованности данных все еще существует, когда участник ждет команду do commite после получения запроса preCommit, если координатор запрашивает прервать транзакцию, но координатор не может нормально связаться с участником, участник продолжит отправлять транзакцию , что приводит к несогласованности данных.

4.3 Транзакция TCC (Try-Confirm-Cancel) — согласованность в конечном итоге

Введение в программу

Концепция TCC (Try-Confirm-Cancel) была впервые предложена Пэтом Хелландом в статье под названием «Жизнь за пределами распределенных транзакций: мнение отступника», опубликованной в 2007 году.

TCC — это двухэтапная модель программирования, ориентированная на службы, и все ее методы Try, Confirm и Cancel реализованы с помощью бизнес-кодирования;

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

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

Поток обработки

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

1. Пробный этапС точки зрения этапа выполнения это то же самое, что бизнес-логика в традиционном механизме транзакций. Но с точки зрения бизнеса все по-другому. Механизм Try in the TCC — это только предварительная операция, которая действительно может представлять собой полную бизнес-логику вместе с последующим подтверждением, этот этап в основном завершен:

Выполните все бизнес-проверки (согласованность)
Резервирование необходимых бизнес-ресурсов (квазиизоляция)
Попробуйте заняться бизнесом Механизм транзакции TCC сосредоточен на предварительной операции (Try), а операция подтверждения (Confirm) и операция отмены (Cancel) выполняются вокруг предварительной операции (Try). Таким образом, операция в фазе «Попытка» имеет наилучшую гарантию.Даже в случае сбоя все еще существует операция «Отмена», которая может отменить результат ее выполнения.

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

2. Подтвердить/Отменить этапПродолжайте выполнять операцию подтверждения (Confirm) или отмените операцию (Cancel) в зависимости от того, все ли службы на этапе Try выполняются нормально. Операции Confirm и Cancel являются идемпотентными. Если операция Confirm или Cancel завершается с ошибкой, она будет повторять попытки до тех пор, пока выполнение не будет завершено.

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

Используемые здесь ресурсы должны быть бизнес-ресурсами, зарезервированными на этапе пробной версии. В механизме транзакций TCC считается, что если ресурсы могут быть зарезервированы в обычном режиме на этапе Try, Confirm должен быть в состоянии полностью и правильно отправить их. Фаза подтверждения также может рассматриваться как дополнение к фазе пробы.Попытка+подтверждение вместе образуют полную бизнес-логику.

Отмена: при сбое выполнения службы на этапе «Попытка» перейдите к этапу «Отмена».

Отмена отменяет выполнение и освобождает бизнес-ресурсы, зарезервированные на этапе "Попытка". В приведенном выше примере операция "Отмена" освобождает замороженные запасы и обновляет статус заказа до отмены.

Краткое содержание программы

По сравнению с традиционным механизмом транзакций (X/Open XA) механизм транзакций TCC имеет следующие преимущества по сравнению с механизмом транзакций XA, представленным выше:

повышение производительности Степень детализации управления блокировками ресурсов для определенных служб снижается, и весь ресурс не будет заблокирован.
Возможная согласованность данных На основе идемпотентности Confirm и Cancel гарантируется окончательное подтверждение или отмена транзакции, а также гарантируется непротиворечивость данных.
надежность Он решает проблему единой точки отказа координатора протокола XA.Главная бизнес-сторона инициирует и контролирует всю бизнес-активность, а менеджер бизнес-активности также становится многоточечным, который внедряется в кластер.

недостаток: Операционные функции «Попробовать», «Подтвердить» и «Отмена TCC» должны быть реализованы в соответствии с конкретным бизнесом, а степень связанности бизнеса высока, что увеличивает стоимость разработки.

4.4 Локальная таблица сообщений — окончательная согласованность

Введение в программу

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

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

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

Поток обработки

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

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

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

Весь бизнес-процесс выглядит следующим образом:

Шаг 1 Активная сторона транзакции обрабатывает локальную транзакцию.Транзакции активно обрабатывают операции бизнес-обновления и записывают операции таблицы сообщений в локальных транзакциях. В приведенном выше примере этап службы инвентаризации завершает вычет инвентаря и записывает таблицу сообщений (1 и 2 на рисунке) в локальную транзакцию.

Шаг 2 Активная сторона транзакции уведомляет пассивную сторону транзакции об обработке транзакции через промежуточное программное обеспечение сообщений и уведомляет транзакцию об ожидании сообщения.. Промежуточное программное обеспечение сообщений может быть основано на очередях сообщений Kafka и RocketMQ.Активный метод транзакции активно записывает сообщения в очередь сообщений, а потребитель транзакций потребляет и обрабатывает сообщения в очереди сообщений. В приведенном выше примере служба инвентаризации записывает сообщение об ожидании транзакции в ПО промежуточного слоя сообщений, а служба заказов использует сообщение ПО промежуточного слоя сообщений для выполнения нового заказа (3–5 на рисунке).

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

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

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

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

3. Если это бизнес-сбой, пассивная сторона транзакции может отправить сообщение активной стороне транзакции для отката.

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

Краткое содержание программы

Преимущества схемы следующие:

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

Недостатки следующие:

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

4.5 MQ-транзакции — окончательная согласованность

Введение в программу

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

Поток обработки

Далее в основном представлена схема распределенных транзакций MQ, основанная на версиях после RocketMQ 4.3.

В схеме локальной таблицы сообщений обеспечение согласованности отправки и записи данных бизнес-таблицы активной стороной транзакции и записи данных таблицы сообщений основано на транзакциях базы данных.По сравнению с обычным MQ, сообщения о транзакциях RocketMQ обеспечивают интерфейс отправки 2PC.Схема как следует:

Нормальная ситуация - активная сторона транзакции отправляет сообщениеПри этом активное обслуживание транзакции нормальное и сбоя нет.Процесс отправки сообщения выглядит следующим образом:

Рис. 1. Отправитель отправляет половину сообщения на сервер MQ (MQ Server).

Рис. 2. После того как сервер MQ успешно сохранил сообщение, он подтверждает, что сообщение было успешно отправлено отправителю с подтверждением подтверждения.

На рис. 3 отправитель начинает выполнять логику локальной транзакции.

На рис. 4 отправитель отправляет вторичное подтверждение (фиксация или откат) на сервер MQ в соответствии с результатом выполнения локальной транзакции.

Рисунок 5. MQ Server помечает полусообщение как доставленное, когда получает статус фиксации, и подписчик в конечном итоге получает сообщение; MQ Server удаляет полусообщение, когда получает статус отката, и подписчик не примет сообщение.

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

На рис. 5 сервер MQ инициирует обратную проверку сообщения.

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

Рисунок 7. Отправитель снова отправляет второе подтверждение в соответствии с окончательным состоянием локальной транзакции, полученным путем проверки

Рис. 8. Сервер MQ доставляет или удаляет сообщения в зависимости от фиксации/отката

Краткое содержание программы

По сравнению со схемой локальной таблицы сообщений преимущества схемы транзакций MQ:

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

слабость это:

Для отправки одного сообщения требуется два сетевых запроса (половина сообщения + сообщение фиксации/отката)
Службе бизнес-обработки необходимо реализовать интерфейс проверки статуса сообщения.

4.6 Транзакции Saga — окончательная согласованность

Введение в программу

Транзакция Saga возникла из статьи о том, как работать с долгосрочными транзакциями, опубликованной Хекто и Кеннетом из Принстонского университета в 1987 году. Основная идея транзакций Saga заключается в разделении длинных транзакций на несколько локальных коротких транзакций, которые координируются. Координатором транзакций Saga.Если она завершается нормально, то завершается нормально, если шаг терпит неудачу, операция компенсации вызывается по одной в обратном порядке.

Поток обработки

Основной протокол транзакции Saga выглядит следующим образом.:

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

Видно, что по сравнению с TCC у Saga нет действия «резервирования», и его Ti напрямую передается в библиотеку.

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

Транзакция проходит нормально T1, T2, T3, ..., Tn, например: вычесть запасы (T1), создать заказ (T2), оплатить (T3) и завершить всю транзакцию по порядку.
откат транзакции T1, T2, ..., Tj, Cj,..., C2, C1, где 0

Saga определяет две стратегии восстановления:

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

Соответствует первому порядку выполнения выше, он подходит для сценариев, которые должны завершиться успешно. В случае сбоя выполняется повторная попытка. Порядок выполнения подобен этому: T1, T2, ..., Tj (сбой), Tj (повторная попытка ), ..., Tn, где j — подтранзакция, в которой произошла ошибка. Ci в этом случае не требуется.

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

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

Существует две распространенные реализации транзакций Saga:

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

Центральный оркестратор (OSO) взаимодействует с каждой службой в режиме «команда-ответ» и несет единоличную ответственность за указание каждому участнику, что и когда делать.

В качестве примера возьмем заказ электронной коммерции:

1. Основная бизнес-логика инициатора транзакции запрашивает у ОСО-сервиса открытие транзакции ордера 2. OSO запрашивает службу инвентаризации для вычета инвентаря, и служба инвентаризации отвечает результатом обработки. 3. OSO запрашивает службу заказов на создание заказа, и служба заказов отвечает результатом создания. 4. OSO запрашивает оплату платежному сервису, и платежный сервис отвечает результатом обработки. 5. Основная бизнес-логика получает и обрабатывает ответ о результате транзакции OSO.

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

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

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

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

В качестве примера возьмем заказ электронной коммерции:

1. Основная бизнес-логика инициатора транзакции публикует событие стартового ордера 2. Служба инвентаризации отслеживает события начала заказа, вычитает запасы и публикует события вычета запасов. 2. Служба заказов отслеживает событие вычета запасов, создает заказ и публикует событие создания заказа. 4. Платежный сервис отслеживает событие создания заказа, производит оплату и публикует событие оплаты заказа 5. Основная бизнес-логика отслеживает событие оплаты заказа и обрабатывает его.

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

Краткое содержание программы

Преимущества и недостатки дизайна координации команд:Преимущества заключаются в следующем:

1. Отношения между службами просты, что позволяет избежать циклических зависимостей между службами, потому что координатор Saga будет звонить участнику Saga, но участник не будет звонить координатору.
2. Разработка программы проста, нужно только выполнить команду/ответ (фактически, ответное сообщение также является своего рода сообщением о событии), что снижает сложность участников.
3. Простота обслуживания и расширения, при добавлении новых шагов сложность транзакций остается линейной, откатом легче управлять, легче внедрять и тестировать

Недостатки следующие:

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

Плюсы и минусы событийного/хореографического дизайнаПреимущества заключаются в следующем:

1. Избегайте риска единичного отказа центрального координатора.
2. Когда требуется меньше шагов, разработка услуги проста и легка в реализации.

Недостатки следующие:

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

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

5 Резюме

Используйте сценарии каждого плана

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

2ПК/3ПК Опираясь на базу данных, он может обеспечить сильную согласованность и сильную транзакцию, но задержка относительно высока, что больше подходит для традиционных одиночных приложений.В том же методе есть операции между базами данных, что не подходит для высокой параллелизма и Сценарии с высокими требованиями к производительности.
ТСС Он подходит для определенного и короткого времени выполнения, высоких требований к реальному времени и высоких требований к согласованности данных, таких как три основные услуги интернет-финансовых предприятий: транзакции, платежи и бухгалтерский учет.
Локальная таблица сообщений/транзакция MQ Оба применимы к идемпотентной работе участников транзакции, требования к непротиворечивости невысоки, бизнес может допустить несогласованность данных вплоть до цикла ручной проверки, в транзакции задействовано меньшее количество участников и связей участия, имеется сверка/проверка бизнес Нижняя часть системы.
Сага дела Поскольку транзакции Saga не могут гарантировать изоляцию, параллелизм необходимо контролировать на бизнес-уровне, что подходит для бизнес-сценариев, в которых транзакции одновременно работают с одним и тем же ресурсом меньше. По сравнению с отсутствием действия перед отправкой в Saga, реализация действия компенсации более проблематична.Например, если бизнес должен отправить короткое сообщение, действие компенсации должно отправить еще одно короткое сообщение, чтобы объяснить отмену, и пользовательский опыт относительно плохой. Транзакции Saga больше подходят для сценариев, в которых компенсационные действия просты в обработке.

Проект схемы распределенных транзакций

Принцип, представленный в этой статье, смещен в сторону принципа, поскольку в отрасли уже существует множество решений с открытым исходным кодом или платных решений.

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

Самый простой в мире способ решить компьютерную проблему: "просто" не надо ее решать! —— Шэнь Сюнь, технический эксперт промежуточного программного обеспечения Alibaba

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

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

Более интересно, добро пожаловать на официальный аккаунт автора [архитектура распределенной системы]

Ссылаться на

технологический разговор - сделка

Реализация транзакций в MySQL

Алгоритмы распределенного консенсуса 2PC и 3PC

Принцип и практика распределенной открытой системы обмена сообщениями (RocketMQ)

Введение в сообщения транзакций RocketMQ

Решения и практика распределенных транзакций Saga - Jiang Ning

Сага о распределенных транзакциях

Подумайте о распределенных транзакциях от перезарядки золотых монет