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

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

местные дела

Транзакция Транзакция состоит из набора SQL и имеет четыре свойства ACID.

ACID

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

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

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

долговечностьПосле совершения транзакции результат остается постоянным даже в случае простоя (не повреждения диска).

Реализация сделки

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

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

undo logЖурнал отмены используется для хранения значения до изменения данных.Если модификация является ненормальной, журнал отмены можно использовать для реализации операции отката, чтобы обеспечить согласованность транзакции. Кроме того, функция транзакций InnoDB MVCC также реализована на основе журнала отмены. Журнал отмены разделен на журнал отмены вставки (журнал, созданный оператором вставки, удаляется сразу после фиксации транзакции) и журнал отмены обновления (журнал, созданный операторами удаления и обновления. Поскольку журнал отмены может использоваться механизмом MVVC его нельзя удалить, когда транзакция зафиксирована. ).

введение проблемы

теория CAP

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

Традиционные СУБД, такие как MySQL, на самом деле имеют комбинацию ЦС.При архитектуре ведущий-ведомый в случае разделения чтения-записи в жертву приносится определенная степень согласованности (задержка ведущий-ведомый).

Базовая теория

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

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

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

Как решить

Пример сценария

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

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

локальная таблица

Для приведенного выше сценария создайте две таблицыФорма записи о возвратеиЛист регистрации отправки СМСи соответствующийКомпенсационная работа

Конкретный процесс реализации:

  1. Добавить новую таблицу записей возврата, статус обрабатывается
  2. Позвоните в службу возврата системы B, чтобы вернуть деньги.
  3. Обновите статус записи возврата до соответствующего статуса (успешно/неудачно)
  4. При успешном возврате будет добавлена ​​новая запись об отправке СМС, а статус записи будет отправлен
  5. Позвоните в SMS-сервис системы C и отправьте SMS
  6. Обновить запись об отправке СМС как отправленной

Возврат компенсации за работуЗапросите записи обработки в таблице записей возврата и вызовите службу возврата системы B. Возврат успешно обработан:

  1. Добавить новую запись об отправке СМС, статус записи будет отправлен
  2. Позвоните в SMS-сервис системы C и отправьте SMS
  3. Обновить запись об отправке СМС как отправленной

Компенсация смс-оповещения РаботаЗапросите записи для отправки в записях отправки SMS и позвоните в службу SMS системы C.

  1. Позвоните в SMS-сервис системы C и отправьте SMS
  2. Обновить запись об отправке СМС как отправленной

Уведомление:

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

сообщение о транзакции

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

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

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

Конкретный процесс реализации:

  • Отправить сообщение о транзакции для возврата
  • Добавить новую запись о возврате, статус: обрабатывается
  • Сообщение о подтверждении транзакции возврата

Обеспечить обратный вызов транзакции MQ

Запрос обратного звонка на возврат

  • Фиксировать, если есть запись о возврате и она обрабатывается
  • Другие Откат

Отправить смс-запрос обратного звонка

  • Совершать, если есть запись возврата, и это успешно
  • Другие Откат

Возврат задания синхронизации

Запросите записи обработки в таблице записей возврата и вызовите интерфейс запроса возврата системы B. Состояние синхронизации. Где возврат был успешно обработан:

  • Транзакционное сообщение для отправки SMS
  • Обновить запись возврата как успешную
  • Подтвердить SMS-сообщение о транзакции

родственные теории

двухэтапная фиксация

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

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

Для решения проблемы двухступенчатой ​​подачи существует еще одинТрехэтапная фиксация:

  • Решите проблему блокировки: разделите первый этап в 2PC на два, предоставьте этап CanCommit, этот этап не блокирует ресурсы, что может значительно снизить вероятность блокировки
  • Решить проблему одной точки: на стороне участника также введен механизм тайм-аута.

DTP Model

Модель X/Open Distributed Transaction Processing (DTP) — это программная архитектура, ставшая де-факто поведенческим стандартом для компонентов модели транзакций. Это позволяет нескольким приложениям совместно использовать ресурсы, предоставленные несколькими менеджерами ресурсов, и позволяет координировать их работу как глобальную транзакцию.

ApplicationProgram(AP)Приложение определяет границы транзакций и указывает операции, из которых состоит транзакция.

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

TransactionManagger(TM)Менеджер транзакций — это независимый компонент, который присваивает идентификаторы транзакциям и следит за выполнением транзакций, отвечает за завершение транзакций и устранение сбоев.

CommunicationResourceManager(CRM)Диспетчер коммуникационных ресурсов управляет связью распределенных приложений между одним или несколькими доменами TM.

XA Specification

Спецификация XA — это спецификация X/Open для распределенной обработки транзакций (DTP). Спецификация описывает интерфейс между глобальным диспетчером транзакций и локальным диспетчером ресурсов. Цель спецификации XA — разрешить доступ к нескольким ресурсам (таким как базы данных, серверы приложений, очереди сообщений и т. д.) в рамках одной транзакции, чтобы свойства ACID оставались действительными для разных приложений. XA использует двухэтапную фиксацию, чтобы гарантировать одновременную фиксацию или откат любой конкретной транзакции всеми ресурсами.

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

TCC

saga

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

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

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

Преимущества режима Saga:

  • Фиксация транзакций локальной базы данных в один этап, без блокировок и с высокой производительностью;
  • Участники могут использовать управляемое транзакциями асинхронное выполнение с высокой пропускной способностью;
  • Компенсационная услуга — это «обратная сторона» форвардной услуги, которую легко понять и легко реализовать;

недостаток:

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

проект с открытым исходным кодом

seata

Seata — это решение для распределенных транзакций с открытым исходным кодом, предназначенное для предоставления высокопроизводительных и простых в использовании сервисов распределенных транзакций в рамках микросервисной архитектуры. Он поддерживает четыре режима: AT, TCC, SAGA и XA и совместим с инфраструктурой микросервисов.

Как показано на рисунке ниже, в Seata есть три основных модуля, а именно TM, RM и TC. Среди них TM и RM интегрированы с бизнес-системой в качестве клиентов Seata, а TC развернут независимо в качестве сервера Seata.

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

ТМ – Менеджер транзакцийОпределите область действия глобальной транзакции: запустите глобальную транзакцию, зафиксируйте или откатите глобальную транзакцию.

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

В Seata поток выполнения распределенных транзакций:

  • TM открывает распределенные транзакции (TM регистрирует глобальные записи транзакций в TC);
  • Организация внутритранзакционных ресурсов, таких как базы данных и сервисы, в соответствии с бизнес-сценариями (RM сообщает о состоянии подготовки ресурсов TC);
  • TM завершает распределенную транзакцию, и транзакция завершается в одну фазу (TM уведомляет TC о необходимости фиксации/отката распределенной транзакции);
  • TC агрегирует информацию о транзакциях и решает, будет ли распределенная транзакция зафиксирована или отменена;
  • TC уведомляет все RM о фиксации/откате ресурсов, и вторая фаза транзакции заканчивается;

В режиме

Режим AT — это ненавязчивое решение для распределенных транзакций. В режиме AT пользователям нужно обращать внимание только на свой «бизнес-SQL». «Бизнес-SQL» пользователя используется в качестве первого этапа, а платформа Seata автоматически генерирует операции фиксации и отката транзакции второго этапа.

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

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

режим ТСС

Распределенная глобальная транзакция, в целом представляет собой двухэтапную модель фиксации. Глобальная транзакция состоит из нескольких транзакций ветвей.Транзакция ветвления должна соответствовать требованиям двухфазной модели фиксации, то есть каждая транзакция ветвления должна иметь свою собственную:

Однофазная подготовка Двухэтапная фиксация или поведение отката

Режим TCC, который не зависит от поддержки транзакций базового ресурса данных:

  • Поведение одноэтапной подготовки: вызов пользовательской логики подготовки.
  • Поведение двухэтапной фиксации: вызов пользовательской логики фиксации.
  • Двухэтапное поведение отката: вызов пользовательской логики отката.

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

Режим саги

В настоящее время режим Saga, предоставляемый SEATA, реализован на основе движка конечного автомата.Механизм:

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

Принцип движка конечного автомата

  • Диаграмма состояний на рисунке состоит в том, чтобы сначала выполнить состояние A, затем выполнить состояние B, а затем выполнить состояние C.
  • Выполнение «состояния» основано на модели, управляемой событиями.После завершения выполнения состоянияA будет сгенерировано сообщение о маршрутизации и помещено в EventQueue, а потребитель события извлечет сообщение из EventQueue и выполнит состояниеB.
  • При запуске всего конечного автомата будет вызван Seata Server для запуска распределенной транзакции, будет сгенерирован xid, а затем событие запуска «экземпляра конечного автомата» будет записано в локальную базу данных.
  • При выполнении «состояния» будет вызван сервер Seata для регистрации транзакции ветки, будет сгенерирован branchId, а затем будет записан «экземпляр состояния», чтобы запустить событие выполнения в локальную базу данных.
  • Когда «состояние» выполняется, оно записывает событие окончания выполнения «экземпляра состояния» в локальную базу данных, а затем вызывает сервер Seata, чтобы сообщить о состоянии транзакции ветки.
  • Когда выполнение всего конечного автомата будет завершено, событие завершения выполнения «экземпляра конечного автомата» будет записано в локальную базу данных, а затем будет вызван сервер Seata для фиксации или отката распределенной транзакции.
Категории