Оригинал заявления: Эта статья является оригинальной автором. Несанкционированная перепечатка отдельными лицами, СМИ, публичными аккаунтами или веб-сайтами запрещена. Нарушители будут привлечены к ответственности.
Сценарии приложений на основе протокола XA
По сравнению с моделью TCC с точки зрения архитектуры, самая большая разница между протоколом XA и моделью TCC заключается в том, что XA напрямую воздействует на уровень ресурсов, а последний воздействует на уровень обслуживания.
Ресурсный слой более общий и почти не имеет вторжения в бизнес, но для адаптации к различным бизнес-сценариям необходимо строго следовать характеристикам ACID транзакций, сервисный слой ближе к бизнесу и может быть оптимизирован для различные предприятия, преследующие более высокие пределы производительности.
Конечно, это не означает, что протокол XA можно использовать только в мультиресурсных сценариях внутри одного сервиса, возможны и мультиресурсные сценарии между сервисами, но также требуется дополнительный механизм доставки транзакций.
Как показано в разделе «Обзор распределенных транзакций», протокол XA обеспечивает глобальную изоляцию за счет локальной изоляции транзакций каждого RM (диспетчер ресурсов, диспетчер ресурсов) и должен обеспечивать согласованность распределенных транзакций с помощью уровня изоляции сериализации. Однако существуют определенные проблемы с производительностью, связанные с уровнями изоляции сериализации, а именно:
На уровне изоляции сериализации блокировки чтения будут добавлены к незаблокированным операциям чтения моментального снимка Select, что увеличит время удержания блокировки и еще больше снизит одновременную производительность. Когда реализуется глобально согласованное чтение без блокировки, такое как распределенный MVCC, время удержания блокировки может быть значительно сокращено, а производительность параллелизма значительно улучшена.
Однако независимо от того, как реализована оптимизация, производительность параллелизма данных в горячих точках распределенных транзакций является самой высокой, что близко к локальным транзакциям на одной машине. Поэтому, будь то распределенная транзакция на основе протокола XA или локальная транзакция на одном компьютере, существует ограничение на производительность параллелизма горячих данных.
Итак, какова самая большая роль протокола XA? Его самая большая роль заключается в обеспечении транзакционных атрибутов доступа к нескольким ресурсам при горизонтальном масштабировании ресурсов базы данных.
Когда одна машина RM достигает узкого места в производительности ресурсов и не может удовлетворить потребности роста бизнеса, необходимо горизонтально расширить ресурсы RM, чтобы сформировать кластер RM. Для крупномасштабных интернет-продуктов очень важно улучшить одновременную производительность данных, не являющихся точками доступа, за счет горизонтального масштабирования ресурсов.
В качестве примера на приведенном выше рисунке, если предположить, что производительность параллелизма данных без точки доступа для одного RM составляет 100 TPS, тогда 5 RM составляют 500 TPS.Даже если распределенная транзакция включает в среднем 2 RM, она все равно имеет 250 TPS. что увеличивает возможность параллелизма без точки доступа в 2,5 раза.
Подводя итог, можно сказать, что распределенные транзакции, основанные на протоколе XA, не могут улучшить одновременную производительность хотспотов.Значение состоит в том, что при горизонтальном расширении ресурсов для повышения параллельной производительности данных, не являющихся хотспотами, это может строго гарантировать характеристики ACID транзакций для мультиресурсов. доступ.
Что касается производительности параллелизма горячих данных, для общих приложений, после определенной оптимизации производительности на уровне SQL, производительность параллелизма в основном может удовлетворить потребности бизнеса. Если после оптимизации предел производительности не может быть удовлетворен, его необходимо повысить до бизнес-уровня и реализовать с помощью специальной бизнес-логики или оптимизации бизнес-архитектуры в соответствии с бизнес-характеристиками.
Еще одним преимуществом реализации распределенных транзакций непосредственно на уровне ресурсов является его универсальность, которая может скрыть основные детали реализации от бизнеса верхнего уровня. Это особенно полезно в эпоху облачных сервисов.Облачные сервисы используются большим количеством малых и средних предприятий и даже отдельными разработчиками с различными бизнес-требованиями.Универсальные и стандартные продукты для распределенных транзакций очень необходимы, чтобы позволить разработчикам Разработка Разработчики отделены от основных технических деталей и больше внимания уделяют реализации бизнес-логики, чтобы добиться более эффективного и быстрого развития бизнеса.
Сценарии применения на основе модели TCC
Модель распределенных транзакций TCC действует непосредственно на сервисном уровне. Он не связан с конкретной сервисной структурой, не имеет ничего общего с базовым протоколом RPC и не имеет ничего общего с базовым носителем данных.Он может гибко выбирать степень детализации блокировки бизнес-ресурсов, сокращать время удержания блокировок ресурсов, и имеет хорошую масштабируемость.Можно сказать, что это независимо развернутый сервис SOA.и разработан.
Преимущества модели TCC
Для модели распределенных транзакций TCC автор считает, что ее применение в бизнес-сценариях имеет два значения.
1. Распределенные транзакции по сервисам
Функция этой части аналогична функции XA.Разделение услуг также можно рассматривать как горизонтальное расширение ресурсов, но направление другое.
Горизонтальное масштабирование может идти в двух направлениях:
1. Расширение функций. Группировка данных по функциям и распределение различных групп функций по нескольким разным базам данных на самом деле является сервитизацией в рамках архитектуры SOA.
2. Шардирование данных, разделение данных на несколько баз данных внутри функциональной группы, добавление нового измерения к горизонтальному расширению.
Следующая диаграмма кратко иллюстрирует стратегию горизонтального масштабирования данных:
Одновременно можно использовать два метода горизонтального расширения: в разных базах данных могут храниться три разные функциональные группы: информация о пользователе (Users), информация о продукте (Products) и информация о транзакциях (Trans). Кроме того, каждая функциональная группа может быть разделена на несколько баз данных в соответствии с объемом ее бизнеса, и каждая функциональная группа может расширяться независимо друг от друга.
Поэтому одной из функций TCC является обеспечение транзакционных свойств доступа к нескольким ресурсам, когда ресурсы масштабируются в соответствии с функциями.
2. Двухэтапный сплит
Другая функция TCC состоит в разделении двух фаз на две независимые фазы, которые связаны посредством блокировки бизнес-ресурсов. Преимущество ресурсного метода бизнес-блокировки состоит в том, что он не будет ни блокировать дальнейшее использование того же ресурса другими транзакциями в первой фазе, ни влиять на правильное выполнение второй фазы этой транзакции.
Параллельные транзакции для модели XA
Параллельные транзакции для модели TCC
Можно обнаружить, что модель TCC еще больше сокращает время удержания блокировок ресурсов. В то же время, теоретически, пока бизнес позволяет, вторая фаза транзакции может быть выполнена в любое время, так как ресурсы заблокированы бизнесом, и никакие другие транзакции не будут использовать ресурсы, заблокированные транзакцией.
Какую пользу это приносит бизнесу? Возьмем в качестве примера сценарий безопасных транзакций Alipay. В упрощенном случае необходимо задействовать только две службы: службу транзакций и бухгалтерскую службу. Транзакция — это основная бизнес-служба, а учет — вспомогательная бизнес-служба, предоставляющая интерфейсы Try, Commit и Cancel:
1. Интерфейс Try вычитает доступные средства пользователя и переводит их в предварительно замороженные средства. Предварительная заморозка средств — это схема блокировки бизнеса. На втором этапе каждой транзакции могут использоваться только предварительно замороженные средства этой транзакции. После выполнения первого этапа другие параллельные транзакции могут продолжать обрабатывать доступные средства пользователя.
2. Интерфейс Commit списывает предварительно замороженные средства и увеличивает доступные средства на промежуточном счете (защищенные транзакции не могут сразу отправить деньги продавцу, промежуточный счет необходим для временного хранения).
Предполагая, что существует только одна промежуточная учетная запись, каждый раз, когда вызывается интерфейс Commit платежной службы, промежуточная учетная запись будет заблокирована, и у промежуточной учетной записи возникают проблемы с производительностью.
Однако в сценарии защищенной транзакции средства должны быть переведены с промежуточного счета продавцу через семь дней, и промежуточный счет не нужно отображать для внешнего мира. Таким образом, после выполнения первого этапа платежного сервиса можно считать, что платежное звено данной транзакции выполнено, и пользователю и продавцу возвращается успешный результат платежа. Коммит-интерфейс второго этапа платежного сервиса.В период низкого фронта он медленно переваривается и выполняется асинхронно.
Некоторые читатели могут подумать, что обеспеченные транзакции — это нечто особенное, ведь прямые платежные транзакции (режим транзакций, при котором деньги переводятся напрямую на мерчант-счет, после вычета предварительно замороженных средств из интерфейса Commit, не переводятся на промежуточные счета, но напрямую переведены на счет мерчанта) также может быть Таким образом, если мерчант будет проинформирован заранее, средства транзакции в пиковый период не поступят на счет в режиме реального времени, но расчет гарантированно будет завершен в течение определенного периода времени.Продавец также должен понимать.
Это двухэтапная асинхронная функция модели распределенных транзакций TCC.Если первая фаза бизнес-службы выполнена успешно, основная бизнес-служба может быть отправлена и завершена, а затем платформа асинхронно выполнит вторую фазу каждого подчиненного устройства. бизнес Сервис.
Универсальное решение ТСС
Решение TCC общего назначения является наиболее типичной реализацией модели распределенных транзакций TCC.Все подчиненные бизнес-сервисы должны участвовать в принятии решений основного бизнес-сервиса.
Применимая сцена
Так как подчиненная бизнес-служба вызывается синхронно, результат будет влиять на решение основной бизнес-службы.Поэтому универсальное решение для распределенных транзакций TCC подходит для бизнеса с определенным временем выполнения и коротким временем, таким как три Основные услуги интернет-финансовых предприятий: Транзакции, Платежи, Счета:
Когда пользователь инициирует транзакцию, он сначала обращается к службе транзакций, чтобы создать заказ на транзакцию, затем служба транзакций вызывает службу платежей, чтобы создать платежное поручение для транзакции, выполняет платежное действие, и, наконец, служба платежей вызывает службу учета. для записи движения счета и бухгалтерского учета.
Чтобы гарантировать, что три услуги завершат транзакцию вместе, успешно или одновременно неудачно, можно использовать общее решение TCC, чтобы поместить эти три услуги в распределенную транзакцию, транзакцию в качестве основной бизнес-услуги и платежную услугу. как подчиненные бизнес-услуги, учет как платежные услуги вложены из бизнес-услуг, а атомарность транзакций гарантируется моделью ТСС.
Интерфейс Try платежного сервиса формирует платежное поручение, запускает вложенную распределенную транзакцию и вызывает интерфейс Try бухгалтерского сервиса, в интерфейсе Try бухгалтерский сервис замораживает средства покупателя. После завершения вызова первой фазы транзакция завершается, локальная транзакция отправляется, а структура TCC завершает вызов распределенной транзакции из бизнес-службы на второй фазе.
На втором этапе платежного сервиса сначала вызывается интерфейс Confirm бухгалтерского сервиса для разморозки средств покупателя и увеличения свободных средств продавца. После успешного вызова платежная служба переводит платежное поручение в состояние «завершено» и завершает платеж.
Когда вызываются две фазы платежных и бухгалтерских услуг, вся распределенная транзакция заканчивается.
Асинхронное гарантированное решение TCC
Прямая подчиненная бизнес-служба асинхронного гарантированного решения TCC является надежной службой сообщений, в то время как реальная подчиненная бизнес-служба отделена от службы сообщений и выполняется асинхронно как потребитель службы сообщений.
Надежная служба сообщений должна иметь три интерфейса: Try, Confirm и Cancel. Интерфейс Try является предварительно отправленным и отвечает только за постоянное сохранение данных сообщения, интерфейс Confirm подтверждает отправку, после чего начинается реальная доставка сообщения, интерфейс Cancel отменяет отправку и удаляет данные сообщения.
Данные сообщений службы сообщений хранятся и масштабируются независимо друг от друга, что снижает связь между бизнес-службой и системой сообщений и обеспечивает окончательную согласованность распределенных транзакций при условии, что служба сообщений надежна.
Хотя это решение увеличивает стоимость обслуживания службы сообщений, поскольку служба сообщений реализует интерфейс TCC вместо подчиненной бизнес-службы, подчиненная бизнес-служба не нуждается в каких-либо модификациях, а стоимость доступа очень низка.
Применимая сцена
Поскольку потребление сообщений от бизнес-служб является асинхронным процессом, время выполнения не определено, что может привести к увеличению несогласованного временного окна. Таким образом, решение распределенных транзакций с асинхронным гарантированным TCC подходит только для некоторых пассивных бизнесов, которые менее чувствительны к конечному времени согласованности (результат обработки подчиненного бизнес-сервиса не влияет на решение основного бизнес-сервиса, и только пассивно получает основной бизнес-сервис). бизнес-сервис результаты решения). Например, служба регистрации членства и служба отправки электронной почты:
Когда пользователь успешно регистрируется в качестве члена, ему необходимо отправить электронное письмо, чтобы проинформировать пользователя об успешной регистрации и предложить пользователю активировать членство. Но обратите внимание на две вещи:
1. Если регистрация пользователя прошла успешно, обязательно отправьте электронное письмо пользователю;
2. Если регистрация пользователя не удалась, вы не должны отправлять электронные письма пользователю.
Следовательно, он также требует, чтобы служба членства и почтовая служба гарантировали атомарность, либо обе выполнялись, либо не выполнялись ни одна из них. Разница в том, что служба электронной почты является только пассивным бизнесом, и это не влияет на то, может ли пользователь успешно зарегистрироваться.Ему нужно только отправить электронное письмо пользователю после того, как пользователь успешно зарегистрировался.Службе электронной почты не нужно участвовать в принятии решений о членских услугах.
Для этого бизнес-сценария можно использовать асинхронное гарантированное решение распределенных транзакций TCC следующим образом:
Членская служба и почтовая служба разделены надежной службой сообщений, а членская служба и служба сообщений формируют модель транзакции TCC, чтобы обеспечить атомарность транзакции. Затем с помощью надежной функции службы сообщений гарантируется, что сообщение может быть использовано почтовой службой, так что участник и почтовая служба находятся в одной и той же распределенной транзакции. В то же время служба электронной почты не повлияет на процесс выполнения службы членства и только пассивно получает запрос на отправку электронных писем после успешного выполнения службы членства.
Компенсированные решения TCC
Компенсационное решение TCC по структуре похоже на общее решение TCC, и его вспомогательная бизнес-служба также должна участвовать в принятии решения о деятельности основной бизнес-службы. Но разница в том, что ведомому бизнес-сервису первого нужно предоставить только два интерфейса, Do и Compensate, а второму — три интерфейса.
Интерфейс Do непосредственно выполняет реальную полную бизнес-логику, завершает бизнес-обработку, и результаты бизнес-выполнения видны извне; операция «Компенсация» используется для компенсации бизнеса, компенсации или частичной компенсации бизнес-результатов прямой бизнес-операции, а операция «Компенсация» должен удовлетворять идемпотентности.
По сравнению с решением общего назначения подчиненному бизнес-сервису компенсационного решения не нужно преобразовывать исходную бизнес-логику, а нужно только добавить дополнительную логику отката компенсации, а объем бизнес-преобразования невелик. Однако следует отметить, что бизнес выполняет всю бизнес-логику в один этап и не может добиться эффективной изоляции транзакций, когда требуется откат, компенсация может не сработать, и требуются дополнительные механизмы обработки исключений, такие как ручное вмешательство.
Применимая сцена
Из-за отказа компенсации отката компенсационное решение распределенных транзакций TCC подходит только для некоторых сервисов, которые имеют меньше конфликтов параллелизма или нуждаются во взаимодействии с внешним миром.Эти внешние сервисы не являются пассивными сервисами, и результаты их выполнения будут влиять на основные бизнес-услуги, такие как услуги по бронированию авиабилетов для авиаагентов:
Билетный сервис предоставляет услугу многоразового бронирования билетов, которая может бронировать несколько рейсов одновременно, например, из Пекина в Санкт-Петербург вам нужен первый рейс из Пекина в Москву, а второй рейс из Москвы в Санкт-Петербург. Петербург.
Когда пользователь бронирует рейс, он определенно хочет иметь возможность бронировать оба рейса одновременно, и пользователю не имеет смысла бронировать только один рейс. Следовательно, для таких бизнес-услуг также требуется атомарность: если бронирование билетов на один рейс не удается, другой рейс должен иметь возможность отменить бронирование.
Однако, поскольку авиакомпании являются внешним бизнесом по сравнению с агентами по продаже билетов и предоставляют только интерфейс бронирования и интерфейс отмены бронирования, продвигать трансформацию авиакомпаний чрезвычайно сложно. Следовательно, для таких бизнес-услуг можно использовать компенсирующее решение для распределенных транзакций TCC следующим образом:
Служба шлюза добавляет интерфейс компенсации на основе исходной логики и отвечает за вызов интерфейса отмены соответствующей авиакомпании.
Когда пользователь инициирует запрос на бронирование билетов, служба продажи билетов сначала обращается к интерфейсу бронирования каждой авиакомпании через интерфейс шлюза Do. Если все рейсы забронированы успешно, вся распределенная транзакция выполняется напрямую; распределение Структура транзакций TCC вызывает интерфейс компенсации компенсации каждого шлюза, который затем вызывает интерфейс отмены бронирования соответствующей авиакомпании. Таким образом, также гарантируется атомарность сервиса бронирования билетов на несколько рейсов.
Суммировать
Для существующих Интернет-приложений горизонтальное расширение ресурсов обеспечивает большую гибкость и является относительно простым в реализации масштабируемым решением, но в то же время оно также значительно увеличивает сложность и создает некоторые новые проблемы, например проблемы согласованности данных между ресурсами. .
Горизонтальное масштабирование данных можно масштабировать по сегментам данных или по функциям. Роль моделей XA и TCC в этом отношении аналогична, обе из них могут обеспечить атрибуты транзакций доступа к нескольким ресурсам при горизонтальном расширении ресурсов, но первая работает на сегментировании данных, а вторая — на расширении функций.
Еще одно значение модели XA заключается в ее универсальности.Помимо проблем с производительностью, ее можно применять практически ко всем бизнес-моделям, что очень полезно для некоторых базовых технологических продуктов, таких как распределенные базы данных и облачные сервисы, распределенная структура транзакций и т. д.
В дополнение к роли кросс-сервисных распределенных транзакций модель TCC также имеет функцию двухэтапного разделения.За счет блокировки бизнес-ресурсов допускается асинхронное выполнение второго этапа, и идея асинхронности для решения проблемы производительности параллелизма горячих данных.Одно из острых орудий.
В этой статье, объединяющей конкретные бизнес-сценарии и примеры, сравниваются и анализируются возможности каждого решения для распределенных транзакций с точки зрения производительности, конфликтов горячих точек, сложности доступа и применимых сценариев, в надежде помочь читателям глубже понять распределенные транзакции.
Каждый бизнес отличается друг от друга. Некоторые предприятия могут терпеть краткосрочные несоответствия, а некоторые предприятия могут работать идемпотентно. Независимо от того, какое решение для распределенных транзакций имеет свои преимущества и недостатки, ни одна серебряная пуля не может удовлетворить всех. Следовательно, какое решение необходимо бизнесу, необходимо сочетать с его собственными бизнес-потребностями, бизнес-характеристиками, технической архитектурой и характеристиками каждого решения, а для поиска наиболее подходящего решения можно использовать всесторонний анализ.
В следующей статье будет представлен набор продуктов для распределенных транзакций и различные решения, которые Ant Financial разработала после нескольких лет разработки распределенных транзакций, обслуживающих большое количество внутренних и внешних предприятий.
Официальная учетная запись: распределенная архитектура финансового уровня (Antfin_SOFA)