Понимать идеи дизайна структуры распределенных транзакций с помощью документации Fescar (Seata)

ФескарАлибабаоткрытый источникРаспределенная транзакцияпромежуточное ПО дляэффективныйи для бизнеса0 Вторжениеспособ решитьМикросервисыПроблемы с распределенными транзакциями, возникающие в сценарии.

Какие проблемы с распределенными транзакциями возникают из-за микросервисов?

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

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

По мере изменения бизнес-требований и архитектуры монолитные приложения разбиваются на микросервисы: исходные 3 модуля разбиваются на 3 независимых сервиса, каждый из которых использует независимые источники данных (Pattern: Database per service). Бизнес-процесс будет завершен вызовом 3 сервисов.

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

История Фескара.

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

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

В 2016 году TXC претерпела преобразование продукта вGTS (Глобальная транзакционная служба)В то время он стал единственным облачным продуктом распределенных транзакций в отрасли.В общедоступном облаке и проприетарных облачных решениях Alibaba Cloud он начал обслуживать множество внешних клиентов.

С 2019 года, на основе технического накопления TXC и GTS, команда промежуточного программного обеспечения Alibaba запустила проект с открытым исходным кодом.Fescar (быстрая и простая фиксация и откат, FESCAR), работайте с сообществом над созданием этого решения для распределенных транзакций.

TXC/GTS/Fescar находятся в одном ряду и предоставили уникальный ответ на решение проблемы распределенных транзакций в рамках микросервисной архитектуры.

Первоначальный замысел дизайна

В эпоху бурного развития Интернетабыстрые пробы и ошибкиСпособность критически относиться к бизнесу:

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

Основываясь на этих двух моментах, наиболее важным соображением в начале нашего дизайна является:

• Ненавязчивость к бизнесу:здесьвторжениеЭто означает, что из-за ограничений технической проблемы распределенных транзакций приложение должно быть спроектировано и преобразовано на бизнес-уровне. Такая конструкция и модификация часто приводят к высоким затратам на НИОКР и техническое обслуживание приложения. Мы хотим поставить проблему распределенных транзакций впромежуточное ПОЭтот уровень решен, не требуя от приложения дополнительной работы на бизнес-уровне.
• высокая производительность:Введение гарантии распределенных транзакций неизбежно приведет к дополнительным накладным расходам, что приведет к снижению производительности. Мы надеемся снизить потери производительности, связанные с распределенными транзакциями, до очень низкого уровня, чтобы внедрение распределенных транзакций не повлияло на приложение.

Почему существующие решения неудовлетворительны?

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

Ненавязчивое решение для бизнеса

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

1. База данных требуется для обеспечения поддержки XA. Если вы столкнулись с базой данных, которая не поддерживает XA (или поддерживает ее плохо, например версии MySQL до 5.7), ее нельзя использовать.
2. Ограниченные самим протоколом ресурсы транзакций (записи данных, соединения с базой данных) имеют длительный период блокировки. С точки зрения бизнеса долгосрочная блокировка ресурсов часто не нужна, а поскольку управляющим ресурсами транзакций является сама база данных, уровень приложений не может вмешиваться. В результате приложения на основе XA, как правило, имеют низкую производительность и их трудно оптимизировать.
3. Реализованные распределенные решения на основе XA полагаются на тяжеловесные серверы приложений (Tuxedo/WebLogic/WebSphere и т. д.), которые не подходят для микросервисной архитектуры.

Сценарии вторжения в бизнес

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

• Схема возможной согласованности на основе надежных сообщений
• TCC
• Saga

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

Каким должен быть идеальный сценарий?

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

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

Принцип и конструкция

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

Можно ли развиваться на основе XA и решить проблемы, с которыми сталкивается решение XA?

Как определить распределенную транзакцию?

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

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

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

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

1. TM обращается к TC, чтобы открыть глобальную транзакцию, глобальная транзакция успешно создается и генерируется глобально уникальный XID.
2. XID распространяется в контексте цепочки вызовов микрослужб.
3. RM регистрирует транзакцию филиала в TC и переводит ее в юрисдикцию глобальной транзакции, соответствующей XID.
4. TM инициирует глобальную фиксацию или разрешение отката для XID в TC.
5. TC планирует все транзакции филиалов под юрисдикцией XID для выполнения запроса на фиксацию или откат.

Пока механизм протокола Fescar в целом соответствует XA.

В чем разница с ХА?

Уровень архитектуры

RM схемы XA фактически находится на уровне базы данных, а RM — это, по сути, сама база данных (путем предоставления драйвера, который поддерживает XA для использования приложением).

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

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

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

Давайте сначала посмотрим на процесс 2PC XA.

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

При нормально работающем бизнесе существует высокая вероятность того, что в конце будет успешно отправлено более 90% транзакций. Можем ли мы отправить локальные транзакции на этапе 1? Таким образом, более чем в 90% случаев можно сэкономить время удержания блокировки Фазы 2 и повысить общую эффективность.

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

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

Конечно, вы обязательно спросите: как можно откатить Phase2 при отправке Phase1?

Как транзакции филиалов фиксируются и откатываются?

первый,Приложение должно использовать прокси-сервер источника данных JDBC от Fescar, которым является RM от Fescar.

Фаза 1:

Агент источника данных JDBC от Fescar организует зеркало бизнес-данных до и после обновления в журнал отката посредством анализа бизнес-SQL.местные делаФункция ACID обновления бизнес-данных и журнал отката записываются в одном и том жеместные делапредставлен в.

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

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

Фаза 2:

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

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

Механизм распространения транзакций

XID — это уникальный идентификатор глобальной транзакции. Механизм распространения транзакций должен передать XID в ссылке вызова службы и привязать его к контексту транзакции службы. Таким образом, операция обновления базы данных в службе ссылка будет Зарегистрировать ветку с глобальной транзакцией, представленной этим XID, и привести ее под юрисдикцию этой же глобальной транзакции.

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

В соответствии со свойствами распространения транзакций, определенными спецификацией Java EE и Spring, Fescar поддерживает следующее:

• РАСПРОСТРАНЕНИЕ_ТРЕБУЕТСЯ:Поддержка по умолчанию
• PROPAGATION_SUPPORTS:Поддержка по умолчанию
• PROPAGATION_MANDATORY: Приложение реализовано через API
• PROPAGATION_REQUIRES_NEW: Приложение реализовано через API
• PROPAGATION_NOT_SUPPORTED: Приложение реализовано через API
• PROPAGATION_NEVER: Приложение реализовано через API
• PROPAGATION_NESTED: не поддерживается

изоляция

Изоляция глобальных транзакций основана на локальном уровне изоляции транзакций филиалов.

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

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

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

Отражение атрибута ACID транзакций в Fescar — относительно сложная тема, для глубокого анализа у нас будет специальная статья, которая не будет здесь далее расширяться.

Применимый анализ сценариев

Один из основных принципов Fescar, описанный ранееВажная предпосылка: ресурсы, задействованные в транзакции филиала,долженда поддержкаКИСЛОТНЫЕ транзакцииизРеляционная база данных. Механизмы фиксации и отката веток зависят от гарантии локальных транзакций. Таким образом, если приложение использует базу данных, которая не поддерживает транзакции или вообще не является реляционной базой данных, оно не применяется.

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

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

Собственный режим работы Fescar, представленный выше, называется режимом AT (автоматическая транзакция), который не мешает бизнесу. Другой соответствующий рабочий режим называется режимом MT (Ручная транзакция).В этом режиме транзакции ветвей должны применяться для определения самого бизнеса и логики фиксации и отката.

Основные модели поведения веток

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

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

Модели поведения ветвей режима AT

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

Паттерны поведения ветки паттернов МТ

Бизнес-логику необходимо разбить на части Prepare/Commit/Rollback 3, чтобы сформировать ветку MT и присоединиться к глобальной транзакции.

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

режим смешивания

Поскольку ветви режимов АТ и МТ принципиально одинаковы по поведению, они могут быть полностью совместимы, то есть в глобальной транзакции ветви АТ и МТ могут существовать одновременно. Таким образом, может быть достигнута цель всестороннего охвата бизнес-сценариев: если режим AT может поддерживаться, используйте режим AT; если режим AT временно не может поддерживаться, вместо этого используйте режим MT. Кроме того, естественно, нетранзакционные ресурсы, управляемые режимом MT, также могут быть включены в управление одной и той же распределенной транзакцией вместе с ресурсами реляционной базы данных, поддерживающими транзакции.

Перспектива сценариев применения

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

точка расширения

Поддержка фреймворка микросервисов

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

Поддерживаемые типы баз данных

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

Обнаружение регистрации конфигурации и службы

Поддерживает доступ к различным решениям для обнаружения конфигурации и регистрации служб. Например: Nacos, Eureka, ZooKeeper и т. д.

Сценарий расширения режима MT

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

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

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

Roadmap

Lanscape

The green part is already open sourced, the yellow part will open source by Alibaba/AntFinancial, the blue part we want co-building with out community:

• Developers can refer to Seata implementation of MySQL support if you want to support different databases transaction
• Developers can refer to Seata implementation of Dubbo support if you want to support different microservices
• Developers can refer to Seata implementation of TCC support if you want to support different data source(such as MQ, NoSQL)
• Developers can refer to Seata implementation of TCC support if you want to support different data source(such as MQ, NoSQL)
• Developers can easily support configuration/registry services with just a little work
• The blue part is warmly welcome you, join it and contribute excellent solution
• We will support XA which is the standard of distributed transaction in our product roadmap

Ссылки по теме

• FESCAR on GitHub
• GTS on Aliyun

блогер

Личный публичный аккаунт WeChat:

Персональный гитхаб:

github.com/jiankunking

личный блог:

jiankunking.com