предисловие

Текст был включен в мой репозиторий GitHub, добро пожаловать, звезда:GitHub.com/bin39232820…
Лучшее время посадить дерево было десять лет назад, затем сейчас

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

1 Основные понятия

1.1 Что такое транзакция

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

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

1.2 Местные транзакции

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

Ознакомьтесь с четырьмя характеристиками транзакций базы данных ACID:

A (Atomic): Атомарность, все операции, составляющие транзакцию, либо выполняются, либо не выполняются вообще, и не может быть частичного успеха или частичного отказа.

C (согласованность): согласованность, до и после выполнения транзакции ограничения согласованности базы данных не разрушаются. Например: Чжан Сан переводит 100 юаней Ли Си, и данные до и после перевода верны.Это называется согласованностью.Если Чжан Сан переводит 100 юаней, а счет Ли Си не увеличивается на 100 юаней, будут данные ошибка Согласованность не достигнута.

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

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

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

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

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

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

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

begin transaction； 
//1.本地数据库操作：张三减少金额 
//2.本地数据库操作：李四增加金额 
commit transation;

Но в распределенной среде это станет следующим образом:

begin transaction；
 //1.本地数据库操作：张三减少金额
  //2.远程调用：让李四增加金额 
  commit transation;

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

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

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

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

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

2.1 Основная теория распределенных транзакций

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

2.1.1 Теория CAP

CAP этоConsistency,Availability,Partition toleranceАббревиатура трех слов, обозначающих согласованность, доступность и устойчивость к разделам. Ниже мы объясним отдельно:

Чтобы облегчить понимание теории CAP, мы объединили некоторые бизнес-сценарии в системе электронной коммерции, чтобы понять CAP.

На следующем рисунке показан поток выполнения управления информацией о товарах:

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

1、商品服务请求主数据库写入商品信息（添加商品、修改商品、删除商品）
2、主数据库向商品服务响应写入成功。
3、商品服务请求从数据库读取商品信息。

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

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

На приведенном выше рисунке чтение и запись информации о товаре должны соответствовать следующим целям:

1、商品服务写入主数据库成功，则向从数据库查询新数据也成功。 
2、商品服务写入主数据库失败，则向从数据库查询新数据也失败。

Как добиться согласованности?

1、写入主数据库后要将数据同步到从数据库。 
2、写入主数据库后，在向从数据库同步期间要将从数据库锁定，待同步完成后再释放锁，以免在新数据写入成功 后，向从数据库查询到旧的数据。

Особенности согласованности распределенной системы:

1、由于存在数据同步的过程，写操作的响应会有一定的延迟。 
2、为了保证数据一致性会对资源暂时锁定，待数据同步完成释放锁定资源。 3、如果请求数据同步失败的结点则会返回错误信息，一定不会返回旧数据。

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

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

1、从数据库接收到数据查询的请求则立即能够响应数据查询结果。 
2、从数据库不允许出现响应超时或响应错误。

Как добиться доступности?

1、写入主数据库后要将数据同步到从数据库。
2、由于要保证从数据库的可用性，不可将从数据库中的资源进行锁定。
3、即时数据还没有同步过来，从数据库也要返回要查询的数据，哪怕是旧数据，如果连旧数据也没有则可以按照 约定返回一个默认信息，但不能返回错误或响应超时。

Особенности доступности распределенной системы:

1、 所有请求都有响应，且不会出现响应超时或响应错误。

P - допуск перегородки:

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

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

1、主数据库向从数据库同步数据失败不影响读写操作。 
2、其一个结点挂掉不影响另一个结点对外提供服务。

Как добиться толерантности к разделам?

1、尽量使用异步取代同步操作，例如使用异步方式将数据从主数据库同步到从数据，这样结点之间能有效的实现 松耦合。 
2、添加从数据库结点，其中一个从结点挂掉其它从结点提供服务。

Особенности допуска распределенного раздела:

1、分区容忍性分是布式系统具备的基本能力。

2.1.2 Комбинация CAP

1. Есть ли в приведенном выше примере товарного менеджмента одновременно CAP?

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

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

Значение допуска разделения на этом рисунке:

1）主数据库通过网络向从数据同步数据，可以认为主从数据库部署在不同的分区，通过网络进行交互。 
2）当主数据库和从数据库之间的网络出现问题不影响主数据库和从数据库对外提供服务。 
3）其一个结点挂掉不影响另一个结点对外提供服务。

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

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

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

2. Какие бывают комбинации ВП?

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

1) AP: отказаться от согласованности и стремиться к устойчивости и доступности разделов. Это выбор многих распределенных систем.

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

2) КП:

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

3) ЦА:

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

Вышеупомянутое управление товарами, если вы хотите реализовать CA, имеет следующую структуру:

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

2.1.3 Резюме

Из вышеизложенного мы узнали соответствующие знания теории CAP, CAP является проверенной теорией: распределенная система может одновременно удовлетворять только трем требованиям согласованности, доступности и устойчивости к разделам. Его можно использовать в качестве стандарта рассмотрения при выборе архитектуры и технологий. Для большинства крупномасштабных сценариев интернет-приложений существует множество узлов и разбросанных развертываний, а масштаб текущего кластера становится все больше и больше, поэтому сбой узла и сбой сети являются нормальными, и необходимо обеспечить, чтобы доступность службы достигла N 9s (99,99..%), чтобы добиться хорошей производительности ответа для улучшения взаимодействия с пользователем, обычно делаются следующие выборы: обеспечить P и A, отбросить C для строгой согласованности и обеспечить окончательную согласованность.

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

1. Понимание строгой согласованности и окончательной согласованности

Теория CAP говорит нам, что распределенная система может одновременно удовлетворять только двум из трех пунктов: согласованности, доступности и устойчивости к разделам Среди них AP больше относится к практическим приложениям, а AP — отказ от согласованности для обеспечения доступности и устойчивости к разделам. , но в реальных условиях во многих сценариях необходимо добиться согласованности. Например, в примере, который мы привели ранее, основная база данных синхронизирует данные с подчиненной базой данных. Даже если согласованность не требуется, в конце данные должны быть синхронизированы. обеспечить согласованность данных. Эта согласованность отличается от согласованности в CAP. Согласованность в CAP требует, чтобы данные каждого запрашиваемого узла в любое время были непротиворечивыми. Это подчеркивает сильную согласованность, но окончательная согласованность данные каждого узла могут быть несогласованными в течение определенного периода времени, но данные каждого узла должны быть непротиворечивыми через определенный период времени, что подчеркивает согласованность окончательных данных.

2. Введение в базовую теорию

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

Базовая доступность: при сбое распределенной системы часть доступных функций может быть потеряна, а основные функции гарантированно доступны. Например, если есть проблема с оплатой транзакции на сайте электронной коммерции, товары все еще можно просматривать в обычном режиме.
Мягкое состояние: Поскольку строгая согласованность не требуется, BASE допускает промежуточное состояние (также называемое мягким состоянием) в системе, которое не влияет на доступность системы, например, «оплата», «синхронизация данных» и другие состояния заказа, ожидание данных После возможного консенсуса состояние изменяется на состояние «успех».
Согласованность в конечном счете. Согласованность в конечном счете означает, что через определенный период времени все данные узла будут согласованы. Например, статус заказа «Оплата» в конечном итоге станет «Платеж выполнен» или «Платеж не выполнен», так что статус заказа соответствует фактическому результату транзакции, но требуется определенная задержка и ожидание.

3 2PC (двухэтапная фиксация) для решений с распределенными транзакциями

3.1 Что такое 2PC

2PC представляет собой двухэтапный протокол фиксации, который делит весь процесс транзакции на две фазы: фазу подготовки и фазу фиксации.2 относится к двум фазам, P относится к фазе подготовки, а C относится к фазе фиксации.

Например: Чжан Сан и Ли Си давно не виделись, и старые друзья вместе обедают.Хозяин ресторана просит оплатить счет перед выдачей билета. В это время Чжан Сан и Ли Си, соответственно, жаловались, что текущая ситуация неудовлетворительна, они слишком застенчивы и не желают угощать гостей.В это время они могли только АА. Только после того, как Чжан Сан и Ли Си заплатят, босс может выписать билет, чтобы организовать обед. Но поскольку Чжан Сан и Ли Си — железные петухи, возникла неловкая сцена:

Этап подготовки: Босс просит Чжан Сан заплатить, и Чжан Сан платит. Босс попросил Ли Си заплатить, и Ли Си заплатила.

Этап подачи: Босс выдал билет, и они вдвоем взяли билет и сели ужинать.

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

Весь процесс транзакции состоит из менеджера транзакций и участников.Менеджером транзакций является владелец магазина, а участниками транзакции являются Чжан Сан и Ли Си.Менеджер транзакций отвечает за принятие решений о фиксации и откате всей распределенной транзакции, и участники транзакции несут ответственность за свою локальную фиксацию и откат транзакций

3.2 Решения

3.2.1 XA схема

Традиционное решение 2PC реализовано на уровне базы данных.Например, Oracle и MySQL поддерживают протокол 2PC.Чтобы унифицировать стандарт и снизить ненужные затраты на стыковку в отрасли, необходимо сформулировать стандартизированные модели обработки и стандарты интерфейса. Международная организация открытых стандартов Open Group определяет эталонную модель распределенной обработки транзакций (DTP).

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

Последовательность выполнения следующая:

  1、应用程序（AP）持有用户库和积分库两个数据源。 
  2、应用程序（AP）通过TM通知用户库RM新增用户，同时通知积分库RM为该用户新增积分，RM此时并未提交事 务，此时用户和积分资源锁定。 
  3、TM收到执行回复，只要有一方失败则分别向其他RM发起回滚事务，回滚完毕，资源锁释放。 
  4、TM收到执行回复，全部成功，此时向所有RM发起提交事务，提交完毕，资源锁释放。

Модель DTP определяет следующие роли:

AP (прикладная программа): прикладная программа, которую можно понимать как программу, использующую распределенные транзакции DTP.
RM (Manager Resource): Manager Resource, может понять участников транзакций, в целом обратитесь к экземпляру базы данных, контролируя базу данных через менеджер ресурсов, управляющий ресурсами
TM (Менеджер транзакций): Менеджер транзакций отвечает за координацию и управление транзакциями.Менеджер транзакций контролирует глобальные транзакции, управляет жизненным циклом транзакций и координирует каждый RM. Глобальная транзакция относится к распределенной среде обработки транзакций, в которой для выполнения задания необходимо работать с несколькими базами данных, и это задание является глобальной транзакцией.
Модель DTP определяет спецификацию интерфейса для связи между TM и RM, называемую XA, которая просто понимается как протокол интерфейса 2PC, предоставляемый базой данных Реализация 2PC на основе протокола XA базы данных также называется схемой XA.
Взаимодействие между тремя вышеупомянутыми ролями выглядит следующим образом:
- TM предоставляет интерфейс прикладного программирования для AP, и AP фиксирует и откатывает транзакции через TM.
- Промежуточное ПО транзакции TM уведомляет транзакцию базы данных RM о начале, завершении, фиксации, откате и т. д. через интерфейс XA.
- Суммировать:
- Весь процесс транзакции 2PC включает в себя три роли AP, RM и TM. AP относится к приложениям, которые используют распределенные транзакции 2PC; RM относится к диспетчерам ресурсов, которые контролируют транзакции ветвей; TM относится к диспетчерам транзакций, которые контролируют всю глобальную транзакцию.

1) На этапе подготовки RM выполняет реальные бизнес-операции, но не совершает транзакции, а ресурсы блокируются;

2) На этапе фиксации TM примет ответ об исполнении от RM на этапе подготовки. Пока какой-либо RM не будет выполнен, TM уведомит все RM о выполнении операции отката, в противном случае TM уведомит все RM для отправки транзакции. В конце фазы фиксации блокировка ресурсов снимается.

Проблемы со схемой XA:

1、需要本地数据库支持XA协议。 
2、资源锁需要等到两个阶段结束才释放，性能较差。

3.2.2 Решение Seata

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

Проблема традиционного 2PC была решена в Seata, который управляет выполнением глобальных транзакций путем координации ветвей транзакций локальной реляционной базы данных и является промежуточным программным обеспечением, работающим на прикладном уровне. Основное преимущество заключается в том, что он имеет лучшую производительность и не занимает ресурсы подключения в течение длительного времени.Он решает проблему распределенных транзакций, возникающих в сценарии микросервиса, эффективным и ненавязчивым способом.В настоящее время он обеспечивает режим AT (т.е. 2PC) и Режим TCC Решение для распределенных транзакций.

Идея дизайна Seata заключается в следующем.

Цели дизайна Seata, одна из которых является неинвазивной для бизнеса, и поэтому начните с бизнес-программы 2PC неинвазивной, основанной на эволюции традиционных 2PC, и решит проблемы, стоящие перед программой 2PC.

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

Подобно традиционной модели 2PC, Seata определяет 3 компонента для протоколирования обработки распределенных транзакций:

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

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

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

1. 用户服务的 TM 向 TC 申请开启一个全局事务，全局事务创建成功并生成一个全局唯一的XID。 
2. 用户服务的 RM 向 TC 注册 分支事务，该分支事务在用户服务执行新增用户逻辑，并将其纳入 XID 对应全局 事务的管辖。 
3. 用户服务执行分支事务，向用户表插入一条记录。 
4. 逻辑执行到远程调用积分服务时(XID 在微服务调用链路的上下文中传播)。积分服务的RM 向 TC 注册分支事 务，该分支事务执行增加积分的逻辑，并将其纳入 XID 对应全局事务的管辖。 
5. 积分服务执行分支事务，向积分记录表插入一条记录，执行完毕后，返回用户服务。 
6. 用户服务分支事务执行完毕。 
7. TM 向 TC 发起针对 XID 的全局提交或回滚决议。 
8. TC 调度 XID 下管辖的全部分支事务完成提交或回滚请求。

Различия между реализацией Seata 2PC и традиционной 2PC:

С точки зрения архитектуры, RM традиционного 2PC-решения фактически находится на уровне базы данных, RM — это, по сути, сама база данных, которая реализована через протокол XA, в то время как RM Seata развертывается в виде jar-пакета. в качестве промежуточного слоя на стороне приложения.

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

3.3 Резюме

В этом разделе описываются два решения 2PC: традиционный 2PC (на основе протокола XA базы данных) и Seata для реализации 2PC.Поскольку Seata является навязчивым и решает проблему долгосрочной блокировки ресурсов традиционного 2PC, рекомендуется использовать Seata для реализации 2PC. .

Seata реализует 2 балла PC:

1、全局事务开始使用 @GlobalTransactional标识 。 
2、每个本地事务方案仍然使用@Transactional标识。 
3、每个数据都需要创建undo_log表，此表是seata保证本地事务一致性的关键

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

4.1. Что такое транзакция TCC

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

ТС делится на три этапа:

Стадия Try предназначена для бизнес-проверки (непротиворечивости) и резервирования ресурсов (изоляция).Эта фаза является лишь предварительной операцией, и она действительно может представлять собой полную бизнес-логику вместе с последующим подтверждением.
Стадия Confirm предназначена для подтверждения отправки, на стадии Try все транзакции филиалов успешно выполняются, а затем выполняется Confirm. В нормальных условиях при использовании TCC считается, что на этапе подтверждения нет ошибки. То есть: пока попытка успешна, подтверждение должно быть успешным. Если что-то пойдет не так на этапе подтверждения, необходимо внедрить механизм повторных попыток или ручную обработку.
Фаза отмены — это отмена бизнес-выполнения транзакции филиала в состоянии, когда необходимо откатить ошибку бизнес-процесса и высвободить зарезервированные ресурсы. При нормальных обстоятельствах принятие TCC считается определенным успехом на этапе отмены. Если на этапе отмены возникает ошибка, необходимо внедрить механизм повторных попыток или ручную обработку.
Диспетчер транзакций TM Диспетчер транзакций TM может быть реализован как независимая служба, или глобальный инициатор транзакций может действовать как TM.TM является независимым, чтобы стать общедоступным компонентом, чтобы учитывать структуру системы и повторное использование программного обеспечения.

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

4.2 Решения ТСС

На рынке существует множество фреймворков TCC, например следующие: (следующая дата сбора данных — 23 ноября 2019 г.)

имя кадра	адрес гитхаба	количество звезд
tcc-transaction	GitHub.com/ часто детали…	3850
Hmily	GitHub.com/and199195/еще нет…	2407
ByteTCC	GitHub.com/Лю Янмин…	1947
EasyTransaction	GitHub.com/Q n Jr-группа/…	1690

Упомянутый выше Seata также поддерживает TCC, но режим Seata TCC не поддерживает Spring Cloud. Наша цель — понять принцип TCC и процесс согласования транзакций, поэтому мы предпочитаем легкий и понятный фреймворк, поэтому Hmily окончательно определился.

Hmily — это высокопроизводительная платформа TCC с открытым исходным кодом для распределенных транзакций. Разработанный на основе языка Java (JDK1.8), он поддерживает платформы RPC, такие как Dubbo и Spring Cloud, для распределенных транзакций. В настоящее время он поддерживает следующие функции:

- 支持嵌套事务(Nested transaction support).
- 采用disruptor框架进行事务日志的异步读写，与RPC框架的性能毫无差别
- 支持SpringBoot-starter 项目启动，使用简单
- RPC框架支持 : dubbo,motan,springcloud。
- 本地事务存储支持 : redis,mongodb,zookeeper,file,mysql。
- 事务日志序列化支持 ：java，hessian，kryo，protostuff
- 采用Aspect AOP 切面思想与Spring无缝集成，天然支持集群。
- RPC事务恢复，超时异常恢复等

Hmily использует АОП для перехвата локальных и удаленных методов, участвующих в распределенных транзакциях.Благодаря многостороннему перехвату участники транзакции могут прозрачно вызывать методы Try, Confirm и Cancel другой стороны, передавать контекст транзакции и записывать журналы транзакций по мере необходимости. Компенсация, повторная попытка и т. д.

Hmily не требует службы координации транзакций, но должна предоставить базу данных (mysql/mongodb/zookeeper/redis/file) для хранения журналов.

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

Введение на официальном сайте:Д-р Омар А.орг/веб-сайт/это-…

TCC необходимо обратить внимание на три типа обработки исключений: пустой откат, идемпотент и приостановка.

Пустой откат:

Без вызова метода Try ресурса TCC вызывается двухэтапный метод Cancel.Метод Cancel должен распознать, что это пустой откат, а затем напрямую вернуть успех.

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

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

Идемпотент:

Из предыдущего введения стало известно, что для того, чтобы гарантировать, что двухэтапный механизм повторной отправки TCC не приведет к несогласованности данных, двухэтапные интерфейсы Try, Confirm и Cancel TCC должны быть идемпотентными, чтобы ресурсы нельзя использовать повторно или выпускать. Если идемпотентный контроль выполнен неправильно, это может вызвать серьезные проблемы, такие как несогласованность данных.

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

приостановка:

Приостановка означает, что для распределенной транзакции интерфейс Cancel второго этапа выполняется перед интерфейсом Try.

Причина в том, что когда RPC вызывает транзакцию ветки try, сначала регистрируется транзакция ветки, а затем выполняется вызов RPC.Если сеть вызова RPC в это время перегружена, вызов RPC обычно имеет тайм-аут. время ожидания RPC истекает, TM уведомит RM о возврате Откат распределенной транзакции Возможно, что после завершения отката запрос RPC поступает к участнику для реального выполнения, и бизнес-ресурсы, зарезервированные методом Try, могут использоваться только распределенной транзакцией Бизнес, зарезервированный на первом этапе распределенной транзакции Никто больше не может обрабатывать ресурсы В этой ситуации мы называем это приостановкой, то есть бизнес-ресурсы не могут быть обработаны дальше после того, как они зарезервированы .

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

Например, сценарий таков, что А переводит 30 юаней Б, а счета А и Б находятся в разных сервисах.

план 1:

Аккаунт А

    ```
    try：
        检查余额是否够30元 
        扣减30元 
    confirm： 
        空 
    cancel：
        增加30元
    ```

Аккаунт Б

 ```
 try：
    增加30元 
 confirm： 
    空 
 cancel：
    减少30元
 ```

Описание варианта 1:

1) Аккаунт А, баланс здесь это так называемые бизнес-ресурсы.По указанному выше принципу бизнес-ресурсы нужно проверить и зарезервировать на первом этапе.Поэтому сначала проверяем баланс аккаунта А в интерфейсе Try вычета ресурсов TCC.Достаточно ли, если достаточно, вычесть 30 юаней. Интерфейс «Подтвердить» указывает на формальную отправку.Поскольку бизнес-ресурсы были вычтены в интерфейсе «Попробовать», в интерфейсе «Подтвердить» на втором этапе ничего нельзя сделать. Выполнение интерфейса «Отмена» означает, что вся транзакция откатывается.При откате учетной записи А 30 юаней, вычтенных из интерфейса «Попробовать», необходимо вернуть на учетную запись.

2) Аккаунт B, добавьте деньги на счет B в интерфейсе Try на первом этапе.Выполнение интерфейса Cancel означает, что вся транзакция откатывается.Если аккаунт B откатывается, 30 юаней, добавленных в интерфейсе Try, необходимо быть вычтено.

Анализ проблемы схемы 1:

1）如果账户A的try没有执行在cancel则就多加了30元。 
2）由于try，cancel、confirm都是由单独的线程去调用，且会出现重复调用，所以都需要实现幂等。 
3）账号B在try中增加30元，当try执行完成后可能会其它线程给消费了。 
4）如果账户B的try没有执行在cancel则就多减了30元。

проблема решена:

1）账户A的cancel方法需要判断try方法是否执行，正常执行try后方可执行cancel。 
2）try，cancel、confirm方法实现幂等。 
3）账号B在try方法中不允许更新账户金额，在confirm中更新账户金额。 
4）账户B的cancel方法需要判断try方法是否执行，正常执行try后方可执行cancel。

Оптимизация:

Аккаунт А

    ```
    try：
        try幂等校验 
        try悬挂处理 
        检查余额是否够30元 
        扣减30元 
    confirm： 
        空 
    cancel：
        cancel幂等校验 
        cancel空回滚处理 
        增加可用余额30元
    ````

Аккаунт Б

 ```
 try：
    空 
 confirm： 
    confirm幂等校验 
    正式增加30元 
 cancel：
    空
 ```

4.3 Резюме

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

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

5 Надежная консистентность сообщений для решений распределенных транзакций

###5.1 Что такое транзакция согласованности в конечном счете надежного сообщения

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

Это решение выполняется с использованием промежуточного программного обеспечения сообщений, как показано ниже:

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

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

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

Давайте сначала попробуем эту операцию, сначала отправим сообщение, а затем поработаем с базой данных:

begin transaction； 

    //1.发送MQ 
    //2.数据库操作 
commit transation;

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

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

begin transaction；
    //1.数据库操作 
    //2.发送MQ 
commit transation;

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

2 Надежность участников сделки, получающих сообщения

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

3 Проблема повторного потребления сообщений

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

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

5.2 Решения

5.2.1 Схема локальной таблицы сообщений

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

Ниже приведен пример регистрации для отправки баллов:

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

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

begin transaction； 
    //1.新增用户 
    //2.存储积分消息日志 
commit transation;

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

2. Журнал проверки запланированных задач

Как убедиться, что сообщение отправлено в очередь сообщений?

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

3. Потребительские новости

Как гарантировать, что потребители могут потреблять сообщения?

Здесь можно использовать механизм ack (т. е. подтверждения сообщения) MQ. Потребитель слушает MQ. Если потребитель получает сообщение и отправляет ack (т. е. подтверждение сообщения) MQ после завершения бизнес-обработки, это означает что потребитель завершил обычное потребление сообщения, и сообщения MQ больше не будут передаваться потребителям, иначе потребители будут продолжать повторять попытки отправки сообщений потребителям.

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

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

5.2.2 Схема сообщения транзакции RocketMQ

RocketMQ — промежуточное ПО для распределенного обмена сообщениями от Alibaba, исходный код которого был открыт в 2012 году, а в 2017 году он официально стал проектом верхнего уровня Apache. Понятно, что, включая продукты для обмена сообщениями в Alibaba Cloud и приобретенные дочерние компании, все продукты для обмена сообщениями Alibaba Group работают на RocketMQ, и RocketMQ в последние годы хорошо зарекомендовал себя в рекламной акции Double Eleven. Версии после Apache RocketMQ 4.3 официально поддерживают сообщения транзакций, обеспечивая удобную поддержку реализации распределенных транзакций.

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

После RocketMQ 4.3 реализовано полное транзакционное сообщение, которое фактически является инкапсуляцией локальной таблицы сообщений.Локальная таблица сообщений перемещена внутрь MQ, чтобы решить атомарную проблему отправки сообщения на стороне производителя и выполнения локальной транзакции.

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

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

1. Производитель отправляет сообщения о транзакциях

Источник (отправитель MQ) отправляет сообщение транзакции на сервер MQ, и сервер MQ помечает состояние сообщения как Подготовлено (состояние подготовки).Обратите внимание, что этот потребитель сообщения (подписчик MQ) не может использовать его в данный момент. В этом примере производитель отправляет «сообщение об увеличении количества кредитов» на сервер MQ.

2. Сервер MQ отвечает, что сообщение было успешно отправлено. Когда сервер MQ получает сообщение, отправленное источником, он отвечает, что сообщение отправлено успешно, указывая на то, что MQ получил сообщение.

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

4. Доставка сообщений Если локальная транзакция производителя выполнена успешно, он автоматически отправит сообщение фиксации на MQServer.После получения сообщения фиксации сервер MQ пометит состояние «Сообщение об увеличении кредита» как доступное для потребления.В это время MQ подписчик (кредитная служба) будет потреблять сообщение в обычном режиме; Если источник не может выполнить локальную транзакцию, он автоматически отправит сообщение об откате на сервер MQServer.После того как сервер MQ получит сообщение об откате, он удалит «сообщение об увеличении количества баллов».

Подписчик MQ (точечный сервис) потребляет сообщение, и если потребление успешно, он отвечает на MQ подтверждением, в противном случае он будет получать сообщение повторно. Здесь ack по умолчанию отвечает автоматически, то есть, если программа выполняется нормально, она автоматически отвечает на ack.

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

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

RoacketMQ предоставляет интерфейс RocketMQLocalTransactionListener:

public interface RocketMQLocalTransactionListener {
 /** 
 ‐ 发送prepare消息成功此方法被回调，该方法用于执行本地事务 
 ‐ @param msg 回传的消息，利用transactionId即可获取到该消息的唯一Id 
 ‐ @param arg 调用send方法时传递的参数，当send时候若有额外的参数可以传递到send方法中，这里能获取到 
 ‐ @return 返回事务状态，COMMIT：提交 ROLLBACK：回滚 UNKNOW：回调 
 */
 RocketMQLocalTransactionState executeLocalTransaction(Message msg, Object arg); 
 /** 
 ‐ @param msg 通过获取transactionId来判断这条消息的本地事务执行状态 
 ‐ @return 返回事务状态，COMMIT：提交 ROLLBACK：回滚 UNKNOW：回调 
 */
 RocketMQLocalTransactionState checkLocalTransaction(Message msg); }

Отправить сообщение о транзакции:

Ниже приведены API-интерфейсы, которые RocketMQ предоставляет для отправки транзакционных сообщений:

    TransactionMQProducer producer = new TransactionMQProducer("ProducerGroup"); 
    producer.setNamesrvAddr("127.0.0.1:9876"); 
    producer.start();
   //设置TransactionListener实现 
   producer.setTransactionListener(transactionListener）； 
   //发送事务消息 
    SendResult sendResult = producer.sendMessageInTransaction(msg, null);

5.3 Резюме

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

RocketMQ как промежуточное ПО для сообщений,

RocketMQ в основном решает две функции:

1、本地事务与消息发送的原子性问题。 
2、事务参与方接收消息的可靠性。 可靠消息最终一致性事务适合执行周期长且实时性要求不高的场景。
引入消息机制后，同步的事务操作变为基于消 息执行的异步操作, 避免了分布式事务中的同步阻塞操作的影响，并实现了两个服务的解耦。

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

6.1 Что такое уведомление о максимальных усилиях

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

Интерактивный процесс:

1、账户系统调用充值系统接口
2、充值系统完成支付处理向账户系统发起充值结果通知 若通知失败，则充值系统按策略进行重复通知
3、账户系统接收到充值结果通知修改充值状态。
4、账户系统未接收到通知会主动调用充值系统的接口查询充值结果

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

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

В частности, включают:

1、有一定的消息重复通知机制。 因为接收通知方可能没有接收到通知，此时要有一定的机制对消息重复通知。
2、消息校对机制。 如果尽最大努力也没有通知到接收方，或者接收方消费消息后要再次消费，此时可由接收方主动向通知方查询消息 信息来满足需求。

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

1. Различные идеи решения

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

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

Сценарии бизнес-приложений двух разных

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

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

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

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

6.2 Решения

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

план 1:

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

1、发起通知方将通知发给MQ。使用普通消息机制将通知发给MQ。 注意：如果消息没有发出去可由接收通知方主动请求发起通知方查询业务执行结果。（后边会讲）
2、接收通知方监听 MQ
3、接收通知方接收消息，业务处理完成回应ack
4、接收通知方若没有回应ack则MQ会重复通知。
5、接收通知方可通过消息校对接口来校对消息的一致性。

Сценарий 2:

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

Процесс взаимодействия выглядит следующим образом:

1、发起通知方将通知发给MQ。 使用可靠消息一致方案中的事务消息保证本地事务与消息的原子性，最终将通知先发给MQ。
2、通知程序监听 MQ，接收MQ的消息。 方案1中接收通知方直接监听MQ，方案2中由通知程序监听MQ。通知程序若没有回应ack则MQ会重复通知。
3、通知程序通过互联网接口协议（如http、webservice）调用接收通知方案接口，完成通知。 通知程序调用接收通知方案接口成功就表示通知成功，即消费MQ消息成功，MQ将不再向通知程序投递通知消 息。
4、接收通知方可通过消息校对接口来校对消息的一致性。

Разница между Вариантом 1 и Вариантом 2:

1. В схеме 1 принимающая сторона уведомления взаимодействует с MQ, то есть принимающая схема уведомления слушает MQ.Эта схема в основном взаимодействует между приложениями и внутренними приложениями.

2. В схеме 2 программа уведомления взаимодействует с MQ, программа уведомления отслеживает MQ, и после получения сообщения от MQ программа уведомления вызывает принимающую сторону уведомления через протокол интерфейса Интернет. Это решение в основном используется для уведомлений между внешними приложениями, такими как уведомления о результатах платежей Alipay и WeChat.

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

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

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

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

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

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

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

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

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

ежедневные комплименты

Хорошо всем, вышеизложенное является полным содержанием этой статьи. Люди, которые могут видеть это здесь, всеталант.

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

Six Meridians Excalibur | Text [Original] Если в этом блоге есть какие-то ошибки, прошу покритиковать и посоветовать, буду очень признателен!