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

Адрес источника обращенияGithub.com/diligence без / худой ...

Распределенная транзакция

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

теория CAP

• Теория CAP: распределенная система не может одновременно удовлетворять трем основным требованиям согласованности, доступности и отказоустойчивости разделов и может одновременно удовлетворять не более чем двум из них.
• Непротиворечивость (C): характеристика того, могут ли данные оставаться согласованными между несколькими копиями.
• Доступность (A): относится к услуге, предоставляемой системой, которая должна быть доступна в согласованном состоянии, всегда возвращает результат запроса для каждого пользователя в течение ограниченного времени, что с течением времени система недоступна.
• Отказоустойчивость раздела (P): когда распределенная система сталкивается с отказом любого сетевого раздела, она все равно должна иметь возможность предоставлять внешние услуги, которые соответствуют согласованности и доступности, если не произойдет сбой всей сетевой среды.

Применение теоремы CAP

• Отказаться от P(CA): если вы хотите избежать проблемы отказоустойчивости разделов в системе, более простой подход — поместить все данные (или данные, относящиеся в первую очередь) на распределенный узел, хотя это невозможно Гарантированная 100% система безошибочно, но, по крайней мере, без негативных последствий из-за сетевых разделов
• Отказаться от A (CP): метод заключается в том, что после того, как система сталкивается с сетевым разделом или другим сбоем, затронутая служба должна ждать в течение определенного периода времени.В течение периода ожидания приложения система не может предоставлять обычные услуги для внешний мир, то есть он недоступен.
• Отказ от C(AP): Отказ от согласованности здесь не означает, что согласованность данных вообще не требуется, но относится к отказу от строгой согласованности данных и сохранению окончательной согласованности данных.

БАЗОВАЯ теория

• BASE в основном доступен, мягкое состояние, в конечном итоге непротиворечивое. Это результат разрешений согласованности и доступности в CAP. Он разработан на основе теоремы CAP. Основная идея заключается в том, что даже если не удается достичь строгой согласованности, каждое приложение может использовать соответствующий метод в соответствии со своим бизнесом. достигает конечной согласованности

подача 2ПК

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

Фаза 1: Зафиксировать запрос на транзакцию

• Запрос транзакции: координатор отправляет содержимое транзакции всем участникам, спрашивает, можно ли выполнить операцию фиксации транзакции, и начинает ждать ответа каждого участника.
• Выполнить транзакцию: каждый узел-участник выполняет транзакционные операции и записывает информацию об отмене и повторении в журнал транзакций.
• Если участник успешно выполняет транзакционную операцию, он возвращает координатору ответ «Да», указывая на то, что транзакция может быть выполнена. транзакция не может быть выполнена.
• Этап подачи некоторых на втором этапе называется этапом голосования на ночь, то есть каждому участнику голоса для указания того, можно ли продолжить следующую операцию по представлению транзакции.

Фаза 2: выполнение фиксации транзакции

• Если координатор получает ответ Да от всех участников, то выполняется фиксация транзакции.
• Отправить запрос на фиксацию: координатор отправляет запрос на фиксацию всем узлам-участникам.
• Фиксация транзакции: после того, как участник примет запрос на фиксацию, он формально выполнит операцию фиксации транзакции, а после завершения фиксации отдаст ресурсы транзакции, занятые в течение всего периода выполнения транзакции.
• Результаты отправки транзакции обратной связи: после того, как участник завершает отправку транзакции, он отправляет сообщение ACK координатору.
• Завершить транзакцию: координатор завершает транзакцию после получения сообщений ACK, отправленных обратно всеми участниками.

Прерывание транзакции

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

Преимущества и недостатки

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

подача 3ПК

• Трехфазная фиксация, также известная как протокол трехфазной фиксации, представляет собой улучшенную версию двухфазной фиксации (2PC).
• В отличие от двухфазной фиксации, трехфазная фиксация имеет две точки изменения. Внедрить механизм тайм-аута. При этом как у координатора, так и у участников вводится механизм тайм-аута. Вставьте этап подготовки между первым и вторым этапом. Гарантируется, что состояние каждого участвующего узла непротиворечиво перед финальной фазой фиксации.
• Существует три фазы CanCommit, PreCommit и DoCommit для трехэтапной фиксации.

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

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

Терминология Seata

• ТС: координатор сделок. Поддерживайте состояние глобальных транзакций и транзакций филиалов, а также управляйте фиксацией или откатом глобальных транзакций.
• ТМ: менеджер транзакций. Определите область глобальной транзакции: запустите глобальную транзакцию, зафиксируйте или откатите глобальную транзакцию.
• RM: Управляет ресурсами для обработки транзакций филиала, общается с TC для регистрации транзакций филиала и сообщает о состоянии транзакций филиала, а также управляет фиксацией или откатом транзакций филиала.

Двухкомпьютерное решение Seata

• Этап 1. Бизнес-данные и записи журнала отката фиксируются в одной и той же локальной транзакции, освобождая локальные блокировки и ресурсы подключения.
• Фаза 2: фиксация выполняется асинхронно и выполняется очень быстро. Откат обратно компенсируется одноступенчатым журналом отката.
• Прежде чем зафиксировать однофазную локальную транзакцию, необходимо убедиться, что сначала получена глобальная блокировка. Если глобальная блокировка не может быть получена, локальная транзакция не может быть отправлена.
• Попытки взять глобальную блокировку ограничены определенным диапазоном, за пределами которого он сдастся, откатит локальную транзакцию и снимет локальную блокировку.
• В зависимости от уровня изоляции чтения локальной транзакции базы данных, зафиксированного или выше, глобальный уровень изоляции Seata по умолчанию (режим AT) считается незафиксированным.
• Если приложение используется в определенном сценарии, необходимо требовать глобального чтения.В настоящее время метод Seata использует прокси оператора SELECT FOR UPDATE.

Анализ потока для выполнения SeaSa

• каждыйRMиспользоватьDataSourceProxyдорога передачи данных, цель состоит в том, чтобы использоватьConnectionProxy, целью использования источников данных и прокси данных являетсяundo_logИ бизнес-данные передаются в локальной транзакции, поэтому, пока есть бизнес-операция, должен быть журнал отмены.
• На первом этапе undo_log измененные значения до и после модификации данных сохраняются для подготовки к откату транзакции, поэтому транзакция ветки была зафиксирована после завершения первого этапа, и ресурсы блокировки освобождены.
• TM запускает глобальную транзакцию, помещает глобальный идентификатор транзакции XID в контекст транзакции, а также передает XID в транзакцию нижестоящей ветви через фиктивный вызов.Каждая транзакция ветви связывает свой собственный идентификатор ветви с XID.
• На втором этапе отправки глобальной транзакции TC уведомит каждого участника ветки о необходимости отправить транзакцию ветки.Транзакция ветки была отправлена ​​на первом этапе.Здесь каждому участнику нужно только удалить undo_log, и это может быть выполнено асинхронно. Второй этап очень быстрый.
• Если транзакция ветвления ненормальна, глобальная транзакция откатывается на втором этапе, и ТС уведомляет каждого участника ветвления о необходимости отката транзакции ветвления.XIDиBranch-IDНайдите соответствующий журнал отката и используйте реверс, сгенерированный журналом отката.SQLи выполнить, чтобы завершить транзакцию ветки для отката до

Seata видела случаи реальных боевых действий

• GitHub.com/цвет ах/цвет ах…
• GitHub.com/цвет ах/цвет ах…

Распределенная транзакция TCC

• TCC — это двухэтапная модель программирования, ориентированная на службы.Все три метода Try, Confirm и Cancel реализованы с помощью бизнес-кодирования.
• TCC требует, чтобы каждая транзакция ответвления реализовывала три операции: предварительная обработка Try, подтверждение и отмена Cancel.
• Попробуйте операцию по проверке бизнеса и резервированию ресурсов,
• Подтвердить операцию подтверждения ведения бизнеса
• Cancel реализует операцию, противоположную Try, операцию отката.
• TM сначала инициирует операцию Try для всех транзакций ветвей. Если операция Try для любой транзакции ветвей не удалась, TM инициирует операцию Cancel для всех транзакций ветвей. Если все операции Try выполнены успешно, TM инициирует операцию Confirm для всех транзакций ветвей. ветвления транзакций Подтвердить Если операция /Cancel не удалась, ТМ повторит попытку.

Три стадии ТСС

• Стадия Try предназначена для бизнес-проверки (непротиворечивости) и резервирования ресурсов (изоляция).Эта фаза является лишь предварительной операцией. Она может формировать полную бизнес-логику вместе с последующим подтверждением.
• Стадия Подтверждения предназначена для подтверждения отправки.После успешного выполнения всех транзакций филиала на стадии Попытка выполняется стадия Подтверждения.Обычно TCC используется для того, чтобы думать, что стадия Подтверждения не пойдет не так, то есть до тех пор, пока Попытка прошла успешно, Подтверждение должно быть успешным. Если на этапе подтверждения истинно Ошибка, необходимо ввести механизм повторных попыток или ручную обработку
• Отмена для отмены фазы выполнения находится в ошибках выполнения ветки деловых дел, которые необходимо откатить до состояния, зарезервированные ресурсы для освобождения, при нормальных обстоятельствах считается, что использование TCC Фаза отмены также должна быть действительно успешной, действительно неправильно, если Стадия Cance, необходимо внедрить механизм повторных попыток или ручную обработку
• TM Transaction Manager: TM Transaction Manager может быть реализован как независимая служба, вы также можете全局事务发起方Выступая в роли TM, TM не зависит от общих компонентов, что позволяет учитывать повторное использование структуры системы и программного обеспечения.
• TM создает запись глобальной транзакции при инициировании глобальной транзакции. Идентификатор глобальной транзакции проходит через всю цепочку вызовов распределенной транзакции для записи контекста транзакции, отслеживания и записи состояния. Он используется для подтверждения и отмены ошибок, и его необходимо повторить, поэтому необходимо реализовать идемпотентность

Три ситуации обработки исключений TCC

идемпотентная обработка

• Из-за нестабильности сети и других причин структура распределенных транзакций может неоднократно вызывать двухфазный интерфейс транзакции ветвления в одной и той же распределенной транзакции. Следовательно, двухфазный интерфейс подтверждения/отмены транзакций ветвления должен гарантировать идемпотентность. Если двухфазный интерфейс не может гарантировать идемпотентность, возникнут серьезные проблемы, приводящие к многократному использованию или повторному высвобождению ресурсов, что приведет к сбоям в бизнесе.
• Для идемпотентных типов обычным методом является введение идемпотентных полей для предотвращения повторных атак. Ради проблемы идемпотента в структуре распределенных транзакций этим оружием тоже можно пожертвовать.
• Вставка времени записи является идемпотентным методом. Попробуйте участника, ветвь транзакции в это время инициализируется в состояние INIT. Затем он меняет свое состояние, когда двухэтапное выполнение Confirm/Cancel устанавливает CONFIRMED/ROLLBACKED.
• Когда ТС повторно вызывает двухэтапный интерфейс, участник сначала получает соответствующую запись таблицы управления статусом транзакции, чтобы просмотреть свой статус транзакции. Если статус уже CONFIRMED/ROLLBACKED, это означает, что участник уже обработал задачу и ему не нужно выполнять ее повторно, он может напрямую вернуть TC идемпотентный успешный результат, чтобы помочь ему продвинуть распределенную транзакцию.

Пустой откат

• Когда метод Try участника не вызывается, вызывается метод Cancel второго этапа.Метод Cancel должен иметь способ определить, выполняется ли Try в это время. Если Try не был выполнен, это означает, что операция Cancel недействительна, то есть этот Cancel является пустым откатом, если Try был выполнен, выполняется обычная логика отката.
• Чтобы справиться с проблемой пустого отката, необходимо, чтобы у участников был способ определить, был ли выполнен Try первого этапа в методе Cancel второго этапа. Очевидно, вы можете продолжать использовать таблицу управления состоянием транзакций для достижения этой функции.
• Когда метод Try будет успешно выполнен, будет вставлена ​​запись, указывающая, что транзакция ветви находится в состоянии INIT. Поэтому при последующем вызове метода Cancel второго этапа об этом можно судить, запросив соответствующие записи контрольной таблицы. Если запись существует и статус INIT, это означает, что первый этап был успешно выполнен, и операция отката может быть выполнена в обычном режиме для освобождения зарезервированных ресурсов; если запись не существует, это означает, что первый этап не выполнен. был выполнен, и на этот раз это пустой откат без высвобождения какого-либо ресурса.

Приостановка ресурсов

• Проблема: после того, как транзакция отката TC вызывает второй этап для завершения пустого отката, первый этап успешно выполняется.
• Решение: В качестве метода контроля используется контрольная запись состояния транзакции.Если на втором этапе запись не найдена, запись вставляется, а первый этап выполняется для проверки существования записи.

Сравнение TCC и 2PC

• 2PC обычно находится на уровне БД между базами данных, в то время как TCC обрабатывается на уровне приложения и должен быть реализован с помощью бизнес-логики.Преимущество этой реализации распределенных транзакций заключается в том, что приложение может самостоятельно определять степень детализации операций с данными, уменьшая конфликты блокировок. , можно увеличить пропускную способность
• Недостатком является то, что это очень навязчиво для приложения, и каждая ветвь бизнес-логики должна реализовать три операции: попробовать, подтвердить и отменить. Кроме того, его реализация также относительно сложна, и необходимо реализовать различные стратегии отката в зависимости от состояния сети и различных причин отказа системы.

HMILY Framework реализует дело TCC

# 账户A
try：
    try的幂等效验
    try的悬挂处理
    检查余额是否够30元
    扣减30元
    
    
confirm：
    空处理即可，通常TCC阶段是认为confirm是不会出错的

cancel:
    cancel幂等效验
    cacel空回滚处理
    增加可用余额30元，回滚操作
    
    
# 账户B

try：
    空处理即可
    
confirm：
    confirm的幂等效验
    正式增加30元
cancel:
      空处理即可
   

RocketMQ обеспечивает надежную согласованность сообщений в конечном итоге

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

уведомление о лучших усилиях

В чем разница между уведомлением о лучших усилиях и надежной согласованностью сообщений

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

Сценарии применения для обоих

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

Механизм подтверждения на основе MQ для реализации уведомления с максимальной эффективностью

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

Вариант 2. Добавьте зону обслуживания уведомлений для уведомлений, применимую при предоставлении внешних третьих лиц.

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

• 2PCОдним из самых больших критических замечаний является блокирующий протокол. RM должен дождаться решения TM после выполнения транзакции перехода, после чего служба заблокирует ресурс блокировки. Из-за своего механизма блокировки и высокой временной сложности в наихудшем случае эта схема не может адаптироваться к потребностям масштабирования с увеличением количества служб, участвующих в транзакции, и ее трудно использовать для распределенных служб с высокой степенью параллелизма и длительными субпроцессами. средний жизненный цикл транзакции
• если взятьTCCПоток обработки транзакций сравнивается с двухфазным фиксацией 2 шт. 2PC обычно находится на уровне БД Bross-базы данных, а TCC обрабатывается на уровне приложения, который необходимо реализовать через бизнес-логику. Преимущество этой распределенной транзакции состоит в том, что это позволяет应用自定义数据操作的粒度，使得降低锁冲突，提高吞吐量成为可能. Недостаток в том, что это очень навязчиво для приложения, и на каждую ветвь бизнес-логики нужно реализовать три операции. Кроме того, его реализация также относительно сложна, и необходимо применять различные стратегии в соответствии с различными причинами отказа, такими как состояние сети и отказ системы.
• 可靠消息最终一致性Транзакции подходят для сценариев с длительными циклами выполнения и низкими требованиями к реальному времени. После введения механизма сообщений синхронная транзакционная операция становится асинхронной операцией на основе сообщения, что позволяет избежать влияния синхронной операции блокировки в распределенной транзакции и реализовать разделение двух служб.Типичные сценарии: регистрация для отправки баллы, войти в систему, отправить купоны и т. д.
• 最大努力通知Это тот, у которого самые низкие требования в распределенных транзакциях. Он подходит для некоторых предприятий с низкой согласованностью в конечном итоге и чувствительностью ко времени. Он позволяет инициирующему уведомителю сбой в бизнес-обработке и активно обрабатывает сбой после того, как принимающий уведомитель получает уведомление, независимо от инициирующего уведомителя.Результат обработки не повлияет на последующую обработку принимающей стороны.Инициирующей стороне необходимо предоставить интерфейс выполнения запроса для получения результатов корректуры уведомляющей стороны.Типичные сценарии применения: уведомление банка, уведомление о результате платежа , и т.д.

	2PC	TCC	достоверные новости	уведомление о лучших усилиях
последовательность	Это было сильное сопротивление	в конечном итоге последовательный	в конечном итоге последовательный	в конечном итоге последовательный
пропускная способность	Низкий	середина	высокий	высокий
сложность реализации	легкий	трудный	середина	легкий

Адрес исходного кода демо-версии Case List

• GitHub.com/Усердие без/Тонкий…