, интересный и полезный канал с распределенной архитектурой.
Эта статья организована в соответствии с живым обменом SOFAChannel # 4, тема: Углубленный анализ режима распределенных транзакций Seata TCC.
Сеата:github.com/seata/seata
Обзор видео и PPT для просмотра окончания адреса см. Текст.
Добро пожаловать в живую интерактивную группу DingTalk: 23127468, не пропускайте каждую прямую трансляцию.
В марте 2019 года Ant Financial присоединилась к созданию сообщества распределенной транзакции Seata и внесла свой вклад в ее модель TCC. Этот выпуск является четвертым выпуском SOFAChannel на тему: Углубленный анализ режима распределенных транзакций Seata TCC.Эта статья организована в соответствии с прямой трансляцией Juesheng.
Всем добрый вечер, меня зовут Seata Committer, я работаю в команде Ant Financial, занимающейся промежуточным программным обеспечением данных. Сегодняшнее содержание в основном разделено на следующие четыре части:
- Принципиальный анализ режима Seata TCC;
- Поделитесь тем, как спроектировать интерфейс TCC на основе бизнес-модели TCC и управления параллелизмом, а также адаптировать модель TCC;
- Как управлять исключением;
- Оптимизация производительности, режим TCC для удовлетворения таких высоких потребностей бизнеса.
1. Режим TCC Seata
1.1 Разделение услуг
Теперь давайте перейдем к первой теме, режиму TCC Seata. В первые дни Ant Financial имела односистемную архитектуру, и почти все бизнес-сервисы находились в нескольких системах. С развитием бизнеса бизнес становится все более сложным, а связанность между сервисами все выше и выше, поэтому мы провели рефакторинг системы, и сервисы развязаны и разделены по вертикали по своим функциям. Проблема после разделения заключается в том, что бизнес-операция может быть завершена только путем вызова одной службы, но теперь для ее завершения необходимо вызвать несколько служб, а сеть, машины и т. д. ненадежны, а проблему согласованности данных легко решить. Такие требования, как масштабируемость, высокая доступность и аварийное восстановление, стали одной из самых больших проблем для финансовой ИТ-архитектуры при поддержке трансформации и модернизации бизнеса.
Как видно из рисунка переход от одиночной системы к микросервису фактически является процессом горизонтального расширения ресурсов Горизонтальное расширение ресурсов означает, что когда одна машина достигает узкого места производительности ресурсов и не может удовлетворить потребности роста бизнеса , ей необходимо расширять по горизонтали ресурсы для формирования кластеров. Для крупномасштабных интернет-продуктов очень важно улучшить одновременную производительность негорячих данных за счет горизонтального масштабирования ресурсов. Разделение услуг также можно рассматривать как горизонтальное расширение ресурсов, но в разных направлениях.
Масштабирование ресурсов может развиваться по двум направлениям, включая разделение бизнеса и шардинг данных:
- Разделение бизнеса. Группировка данных по функциям и распределение различных микросервисов по нескольким разным базам данных на самом деле является сервитизацией в рамках архитектуры SOA. Разделение бизнеса — это разделение бизнес-логики одной системы на несколько микросервисов.
- Срез данных. Во внутреннем микросервисе данные разбиваются на множество баз данных, добавляя новое измерение для масштабирования. Слайс данных предназначен для разделения одной БД в БД на множество микросервисов, включающих функцию Sharding. При демонтаже шкала соответствует ресурсу, так что вся конструкция может нести более высокую пропускную способность.
Одновременно могут использоваться два метода горизонтального масштабирования: три разных микросервиса транзакции, платежа и биллинга могут храниться в разных базах данных. Кроме того, каждый микросервис можно разделить на несколько баз данных в соответствии с объемом его бизнеса, и каждый микросервис можно расширять независимо друг от друга.
Seata фокусируется на проблеме согласованности данных в рамках микросервисной архитектуры и представляет собой полный набор решений для распределенных транзакций. Платформа Seata содержит два режима, один из которых — режим AT. Режим AT в основном фокусируется на согласованности данных при доступе к нескольким БД с точки зрения сегментирования данных и, конечно же, также включает согласованность доступа к данным с несколькими БД в рамках нескольких служб.
Другой — режим TCC. Режим TCC в основном фокусируется на разделении бизнеса. При расширении ресурсов по горизонтали в соответствии с бизнесом он решает проблему согласованности вызовов между микросервисами и обеспечивает атрибуты транзакций доступа к ресурсам для чтения.
Сегодня мы в основном говорим о режиме TCC. Прежде чем говорить о TCC, давайте рассмотрим режим AT, который поможет нам понять последующий режим TCC.
1.2. Режим АТ
Для режима AT, прежде чем другие студенты поделились много раз, мы должны быть более знакомы. В режиме AT каждая база данных должна рассматриваться как ресурс, Seata называлась DataSource Resource. Бизнес перехватывает доступ к базе данных через стандартный ресурс JDBC, все запросы Seata framework будут что-то делать. Каждая локальная транзакция фиксируется, Seata RM (менеджер ресурсов, менеджер ресурсов) будет TC (координатором транзакций, координатором транзакций), регистрирующим транзакцию филиала. Когда вызов ссылки запроса завершен, инициатор уведомляет TC о фиксации или откате распределенной транзакции, входит в поток вызовов второго этапа. В этот момент TC будет основываться на обратном вызове ранее зарегистрированной ветви транзакции соответствующему участнику для выполнения второго этапа соответствующего ресурса. ТС, как найти соответствие между делами ветки и ресурсами? Каждый ресурс имеет глобально уникальный идентификатор ресурса и идентификатор, зарегистрированный с ресурсами для TC во время инициализации. Во время выполнения каждая ветвь будет регистрировать свои ресурсы для получения идентификатора транзакции. Такой ТС сможет найти нужные ресурсы в соответствующем двухэтапном вызове.
Это наш режим AT. Кратко подытожим, это к каждой БД как к Ресурсу, пойдет на регистрацию филиала при подаче сделки в местные дела.
1.3 Режим ТСС
Тогда это соответствует режиму TCC, что то же самое.Среда Seata рассматривает каждую группу интерфейсов TCC как ресурс, называемый ресурсом TCC. Этот набор интерфейсов TCC может быть RPC или внутрислужебными вызовами JVM. Когда бизнес начинается, платформа Seata автоматически сканирует и идентифицирует вызывающую сторону и издателя интерфейса TCC. Если это RPC, то это диван:ссылка, диван:сервис, даббо:ссылка, даббо:сервис и т. д.
После сканирования вызывающей стороне и издателю интерфейса TCC. Если это издатель, он зарегистрирует ресурс TCC в TC при запуске службы.Как и ресурс DataSource, каждый ресурс также будет иметь идентификатор ресурса.
Если это вызывающая сторона, платформа Seata добавит к вызывающей стороне аспект, который, подобно режиму AT, перехватывает все обращения к интерфейсу TCC во время выполнения. Каждый раз, когда вызывается интерфейс Try, аспект сначала регистрирует транзакцию ветвления в TC перед выполнением исходного вызова RPC. Когда вызов ссылки запроса завершен, TC обращается к правильному участнику через идентификатор ресурса транзакции ветвления для выполнения метода Confirm или Cancel, соответствующего ресурсу TCC.
После обсуждения всей модели фреймворка вы можете спросить, как реализованы три интерфейса TCC. Поскольку сама структура очень проста, она в основном сканирует интерфейс TCC, регистрирует ресурсы, перехватывает вызовы интерфейса, регистрирует транзакции ветвей и, наконец, вызывает интерфейс второго уровня. Ядром на самом деле является логика реализации интерфейса TCC. Ниже я проанализирую, как реализовать полный интерфейс TCC, основываясь на многолетнем опыте работы в Ant Financial.
2. Бизнес-модель TCC и контроль параллелизма
2.1 Принципы разработки ТСС
В рамках модели TCC можно обнаружить, что ядро модели TCC заключается в разработке интерфейса TCC. Когда пользователи получают доступ к TCC, большая часть их работы сосредоточена на том, как реализовать услуги TCC. Ниже я поделюсь многолетней практикой применения TCC в Ant Financial и мерами предосторожности в процессе разработки и внедрения TCC.
Какова самая важная вещь для разработки набора интерфейсов TCC? Есть два основных момента,В первую очередь операция должна быть разделена на два этапа.По сравнению с традиционными моделями, такими как XA, модель распределенных транзакций TCC (Try-Confirm-Cancel) характеризуется тем, что она не полагается на поддержку RM для распределенных транзакций, а реализует распределенные транзакции путем декомпозиции бизнес-логики.
Модель TCC рассматривается для бизнес-логики конкретной бизнес-системы, в то время как ее внешняя служба должна принимать некоторую неопределенность, которая требует, чтобы первоначальная работа бизнес-логики была лишь временной операцией, вызов ее основной бизнес-службы сохраняет права последующей отмены. Если первичные бизнес-службы считают, что глобальную транзакцию следует откатить, они запросят временную операцию перед отменой, что соответствует отмене операции из бизнес-служб. И когда основные бизнес-услуги, считающиеся глобальной транзакцией, должны быть отправлены, это даст право отменить временную операцию до того, как это соответствует подтверждению операции из бизнес-сервисов. Каждая первоначальная операция в конечном итоге будет подтверждена или отменена. Таким образом, для конкретных бизнес-услуг модель распределенных транзакций TCC требует, чтобы бизнес-логика бизнес-системы содержала три раздела:
1. Предварительная операция Попробуйте: Заполните все бизнес-проверки и зарезервируйте необходимые бизнес-ресурсы.
2. подтвердите операцию. Подтверждение: реальное выполнение бизнес-логики, не выполняйте никаких бизнес-проверок, бизнес-ресурсы. Попробуйте использовать только зарезервированный этап. Таким образом, до тех пор, пока попытка успешной операции, подтверждение должно быть успешным. Кроме того, Confirm Operation подвержена идемпотентности, а гарантия распределенной транзакции может быть успешной только один раз.
3. Отмените операцию Отмена: Отпустите бизнес-ресурсы, зарезервированные в фазе TRY. Аналогичным образом, операция отмены также необходимо удовлетворить идемпотентность.
Второй момент — контролировать параллелизм по собственной бизнес-модели, что соответствует изоляции в ACID.Подробно об этом будет сказано позже.
2.2 Дизайн модели системы бухгалтерского учета
Далее проанализируем бухгалтерские услуги в звене финансового ядра. Первая и наиболее упрощенная модель учета показана на рисунке: у каждого пользователя или продавца есть учетная запись и ее доступный баланс. Затем проанализируйте всю бизнес-логику операций бухгалтерской службы, будь то транзакция, пополнение, перевод, возврат и т. д., можно рассматривать как пополнение счета и списание денег со счета.
Следовательно, мы можем разделить систему учета на два набора интерфейсов TCC, а именно два ресурса TCC, один из которых является интерфейсом TCC для добавления денег, а другой — интерфейсом TCC для вычета денег.
Что должны делать эти два набора интерфейсов? Как это сделать в два этапа? Далее будет показан процесс проектирования бизнес-модели TCC и его постепенная оптимизация.
Давайте сначала посмотрим, как реализованы ресурсы TCC, которые вычитают деньги. Сценарий таков: А переводит 30 юаней Б. На балансе счета А есть 100 юаней, из которых нужно вычесть 30 юаней. Баланс здесь - это так называемые бизнес-ресурсы.Согласно принципам, упомянутым выше, бизнес-ресурсы должны быть проверены и зарезервированы на первом этапе.Поэтому мы сначала проверяем, достаточно ли баланса счета A в интерфейсе Try вычитая ресурсы TCC, а затем резервируя бизнес-ресурсы в оставшемся остатке, будет вычтено 30 юаней.
В интерфейсе Confirm, так как в интерфейсе Try списаны бизнес-ресурсы, то в интерфейсе Confirm на втором этапе можно ничего не делать. В интерфейсе «Отмена» 30 юаней, вычтенных из интерфейса «Попробовать», необходимо вернуть на счет. Это относительно простая реализация вычета ресурсов TCC, оптимизация которой будет продолжена позже.
А в ТСС ресурсы, которые добавляют денег. На первом этапе пробного интерфейса вы не можете напрямую добавить деньги на счет.Если доступный баланс добавлен на счет в это время, деньги на счете можно использовать после выполнения первого этапа. Но после выполнения одного этапа его можно откатить. Поэтому реальное действие по добавлению денег нужно разместить в интерфейсе подтверждения. Для действия по добавлению денег нет необходимости резервировать какие-либо ресурсы в интерфейсе Try на первом этапе, и его можно оформить как пустую операцию. Соответственно, интерфейс Cancel не имеет ресурсов для освобождения, что также не является операцией. Только когда вам действительно нужно отправить, добавьте доступный баланс к учетной записи в интерфейсе подтверждения.
Это оформление простейшего ресурса ТСС для списания и прибавления денег. В ресурсе TCC удержания интерфейс Try резервирует ресурсы для удержания баланса, интерфейс Confirm ничего не делает, а интерфейс Cancel освобождает ресурсы и увеличивает баланс. В ресурсе TCC добавления денег интерфейс Try не требует резервирования ресурсов, и это пустая операция, интерфейс Confirm напрямую увеличивает баланс, интерфейс Cancel не требует освобождения ресурсов, и это пустая операция.
2.3 Контроль параллелизма модели системы учета
Упомянутый ранее, дизайн интерфейса TCC требует двух моментов, бизнес-логика заключается в необходимости разделить на две фазы. Это мы ввели. Другой момент заключается в том, что в соответствии с их собственным контролем параллелизма бизнес-модели.
Сама платформа Seata предоставляет только двухфазный протокол атомарной фиксации для обеспечения атомарности распределенных транзакций. Для достижения изоляции транзакций необходимо передать бизнес-логике. Суть изоляции заключается в контроле параллелизма и предотвращении хаотических результатов, вызванных одновременными транзакциями, работающими на одних и тех же ресурсах.
Например, при управлении средствами пользователей в финансовой сфере, когда пользователь инициирует транзакцию, средства пользователя обычно проверяются в первую очередь.Если средств достаточно, соответствующая сумма транзакции будет вычтена, средства продавца будут увеличены, и сделка будет завершена. Если нет изоляции транзакций, пользователь инициирует две транзакции одновременно, проверка двух транзакций считает, что средств достаточно, но на самом деле их достаточно только для оплаты одной транзакции, в результате обе транзакции успешно оплачены, что привело к потере капитала.
Можно обнаружить, что контроль параллелизма является гарантией правильного выполнения бизнес-логики, но технологии параллельного управления доступом, такие как двухфазные блокировки, требуют, чтобы блокировки ресурсов базы данных удерживались до конца выполнения всей транзакции, особенно в распределенной транзакции. архитектура, которая требует удержания блокировок. К концу второй фазы распределенной транзакции, то есть распределенная транзакция удлинит время удержания блокировки ресурсов, что приведет к дальнейшему снижению производительности одновременного выполнения.
Таким образом, идея изоляции модели TCC состоит в том, чтобы преобразовать бизнес после первого этапа из блокировки нижележащего уровня ресурсов базы данных в блокировку верхнего бизнес-уровня, чтобы высвободить ресурсы блокировки базовой базы данных и ослабьте протокол распределенной блокировки транзакций, чтобы свести к минимуму степень детализации блокировок и максимизировать производительность параллелизма в бизнесе.
Возьмем приведенный выше пример в качестве примера: «Учетная запись A имеет 100 юаней, транзакция T1 вычитает 30 юаней, а транзакция T2 также вычитает 30 юаней, и происходит параллелизм». На первом этапе операции Try необходимо использовать блокировку уровня ресурсов базы данных, чтобы проверить доступный баланс учетной записи.Если баланса достаточно, зарезервировать бизнес-ресурсы и вычесть сумму транзакции.После первого этапа, хотя Блокировка ресурсов на уровне базы данных заблокирована Освобождено, но этот фонд изолирован бизнесом, и другие параллельные транзакции, кроме этой транзакции, не могут его использовать.
Параллельная транзакция Т2 может продолжать работу после того, как интерфейс на первом этапе транзакции Т1 снимет блокировку ресурсов на уровне базы данных, так же как и транзакция Т1, будут добавлены блокировки, проверен баланс и вычтена сумма транзакции.
Часть средств Т1 и Т2 списываются соответственно без помех. В этих двух фазах распределенных транзакций, независимо от того, отправляется ли T1 или откатывается, это не влияет на T2, поэтому T1 и T2 могут быть реализованы одновременно на одной и той же учетной записи.
Вы можете почувствовать, что после окончания первого этапа метод бизнес-блокировки фактически используется для изоляции средств счета, а базовая блокировка ресурсов снимается непосредственно после первого этапа.Другие транзакции пользователя и продавца могут выполняться одновременно. немедленно без необходимости Когда вся распределенная транзакция завершается, можно получить более высокие возможности параллельных транзакций.
Здесь немного абстрактно, далее мы оптимизируем бизнес-модель, чтобы вы могли более интуитивно прочувствовать идею блокировки бизнеса.
2.4 Оптимизация модели системы учета
В предыдущей модели все, наверное, думали, почему деньги списывались на первом этапе? да. Это было просто, чтобы кратко проиллюстрировать дизайнерскую идею модели TCC. На практике, для лучшего взаимодействия с пользователем, на первом этапе баланс счета, как правило, не вычитается напрямую, а замораживается, так что, показывая его пользователю, вы можете четко знать, какой баланс доступен, а какой нет. замороженная сумма.
Так как же выглядит бизнес-модель? Как показано на рисунке, в бизнес-модель необходимо добавить поле замороженной суммы, чтобы указать, какая часть счета находится в замороженном состоянии.
Поскольку бизнес-модель изменилась, интерфейс TCC для вычета и добавления денег также должен быть соответствующим образом скорректирован. Давайте используем предыдущий пример для иллюстрации.
В вычетном ресурсе TCC. Интерфейс TRY больше не вычитает доступный баланс счета, но реальный зарезервированный ресурс, замораживая часть имеющегося баланса, то есть уменьшение имеющегося баланса и увеличения замороженного количества. Интерфейс подтверждения больше не является пустым операцией, но использует бизнес-ресурсы, зарезервированные интерфейсом Thry, то есть замороженная сумма вычитается; наконец, в интерфейсе отмены, зарезервированные ресурсы выделяются, замороженное количество интерфейса попробовать вычитается, и доступная учетная запись увеличивается. Баланс. Добавленный ресурс TCC не должен быть изменен, поскольку оно не связано с использованием замороженного количества.
Благодаря такой оптимизации процесс резервирования ресурсов, использования ресурсов и освобождения ресурсов интерфейса TCC становится более интуитивно понятным.
Так что же случилось с контролем параллелизма? Как и в большинстве предыдущих, на первом этапе операции Try транзакции T1 сначала блокируется учетная запись и проверяется доступный баланс учетной записи.Если баланс достаточен, бизнес-ресурсы резервируются, доступный баланс уменьшается, а замороженное количество увеличивается. Параллельная транзакция T2 аналогична блокировке, проверке баланса, уменьшению доступной суммы баланса и увеличению замороженной суммы.
Здесь можно обнаружить, что после выполнения транзакций Т1 и Т2 на первом этапе блокировки ресурсов на уровне базы данных снимаются, но на втором этапе каждого из них нет вмешательства друг в друга, и они используют функцию Try интерфейс на первом этапе транзакции Заморозить сумму. Здесь можно интуитивно почувствовать, что на первом этапе каждой транзакции блокировка ресурсов на уровне базы данных используется для резервирования бизнес-ресурсов, то есть для замораживания суммы. Хотя блокировка ресурса на уровне базы данных снимается после окончания первого этапа, выполнение второго этапа не будет нарушено, так как после снятия блокировки ресурса на уровне базы данных эта часть ресурса заблокирован с помощью бизнес-изоляции Разрешить использование других параллельных транзакций в дополнение к этой транзакции, тем самым гарантируя правильное и гладкое выполнение второй фазы транзакции.
На этих двух примерах я объяснил, как спроектировать полный набор интерфейсов TCC. Есть два основных момента: один — разделить бизнес-логику на два этапа, а именно — интерфейсы «Попробовать», «Подтвердить» и «Отменить». Интерфейс Try проверяет ресурсы, резервирует ресурсы, Confirm использует ресурсы, а интерфейс Cancel освобождает зарезервированные ресурсы. Еще одним моментом является контроль параллелизма, который использует комбинацию блокировок базы данных и бизнес-блокировок. Поскольку функция бизнес-блокировки не влияет на производительность, степень детализации блокировок базы данных должна быть максимально уменьшена, а бизнес-блокировка должна быть переведена для улучшения параллелизма в бизнесе.
3. Аномальный контроль TCC
Имея полный набор интерфейсов TCC, действительно ли легко сесть и расслабиться? ответ отрицательный. В микросервисной архитектуре может возникнуть ряд нештатных ситуаций, таких как тайм-аут сети, повторная передача и простои компьютера. Как только эти случаи будут обнаружены, это вызовет исключение в нашем процессе выполнения распределенной транзакции. Согласно многолетнему внутреннему использованию Ant Financial, тремя наиболее распространенными исключениями являются пустой откат, идемпотент и приостановка.
因此，TCC 接口里还需要解决这三类异常。 In fact, these three questions can be completed in Seata framework, but we do not have now Seata framework, then we will process these exceptions Case transplanted into Seata framework, businesses do not need to pay attention to these anomalies, focusing on business logic can быть.
Хотя впоследствии вам не нужно заботиться о бизнесе, вы можете лучше устранять проблемы, понимая его внутренний механизм реализации. Ниже я объясню вам причины этих трех типов исключений и соответствующие решения.
3.1 Пустой откат
Первый — это пустой откат.Что такое пустой откат? Пустой откат означает, что для распределенной транзакции двухэтапный метод Cancel вызывается без вызова метода Try ресурса TCC.Метод Cancel должен распознать, что это пустой откат, а затем напрямую возвращает успех.
Какая ситуация вызовет пустой откат? На рисунке вы можете увидеть шаг 2. Как упоминалось ранее, при регистрации транзакции филиала для вызова RPC аспект платформы Seata перехватит запрос на вызов, сначала зарегистрирует транзакцию филиала с помощью TC, а затем выполнит логику вызова RPC. . Если есть проблема с логикой вызова RPC, например, компьютер вызывающего абонента не работает или сеть ненормальна, вызов RPC завершится ошибкой, то есть метод Try не будет выполнен. Однако распределенная транзакция была открыта и ее необходимо довести до конечного состояния, поэтому ТС вызовет интерфейс Cancel второго этапа участника, тем самым сформировав пустой откат.
Будет ли время представить его? Теоретически нет, если вызывающая сторона выходит из строя, распределенная транзакция по умолчанию откатывается. Если это сетевая аномалия, вызов RPC завершается сбоем, и инициатор должен уведомить TC об откате распределенной транзакции. вызов не удался.Пустые коммиты будут возникать либо из-за проблемы с кодом, либо из-за того, что разработчик четко знает, что это нужно сделать.
Итак, как решить пустой откат? Как упоминалось ранее, Cancel необходимо идентифицировать пустой откат и напрямую возвращать успех. Ключ в том, чтобы распознать этот пустой откат. Идея очень проста: нужно знать, выполняется ли этап, если он выполняется, то это обычный откат, если не выполняется, то это пустой откат. Поэтому требуется дополнительная таблица управления транзакциями, которая содержит идентификатор распределенной транзакции и идентификатор транзакции ветви, а в метод Try на первом этапе вставляется запись, указывающая, что первый этап выполняется. Прочитайте запись в интерфейсе Отмена.Если запись существует, она будет откатана нормально, если запись не существует, она будет пуста.
3.2 Мощность и т. д.
Далее идет идемпотентность.Идемпотентность означает, что для одной и той же транзакции ветвления одной и той же распределенной транзакции повторно вызывается интерфейс второй фазы транзакции ветвления, поэтому двухфазные интерфейсы подтверждения и отмены TCC должны быть идемпотентными, а ресурсы не будут повторно использованы или выпущены. Если идемпотентное управление не выполнено должным образом, это может вызвать серьезные проблемы, такие как потеря капитала.
Какие ситуации вызовут дублирование коммитов или откатов? Как видно из схемы, фиксация или откат — это сетевой вызов от ТК к участнику. Таким образом, сбой сети, время простоя участника и т. д. могут привести к тому, что ресурсы TCC участника фактически реализуют предотвращение второго этапа, но TC не получит возвращенный результат. В это время TC будет повторять вызов до тех пор, пока вызов не будет успешным. , и весь дистрибутив Транзакция заканчивается.
Как решить идемпотентную задачу повторного выполнения? Простая идея состоит в том, чтобы записывать статус выполнения каждой транзакции филиала. В состоянии перед выполнением, если оно было выполнено, оно не будет выполнено, в противном случае оно будет выполнено в обычном режиме. Говоря о пустом откате, уже есть таблица управления транзакциями.Каждая запись в таблице управления транзакциями связана с транзакцией ветви.Затем мы можем добавить поле состояния в эту таблицу управления транзакциями для записи каждого состояния выполнения транзакции ветви .
Как показано на рисунке, поле состояния имеет три значения: инициализация, фиксация и откат. Когда метод Try вставлен, он находится в инициализированном состоянии. После выполнения двухэтапных методов Confirm и Cancel они изменяются до состояния фиксации или отката. При повторном вызове двухэтапного интерфейса сначала получается соответствующая запись таблицы управления транзакциями и проверяется статус, если он был выполнен, он сразу вернет успех, в противном случае он будет выполнен нормально.
3.3 Подвеска
И, наконец, антиподвеска.Как обычно, сначала поговорим о том, что такое подвеска. Приостановка означает, что для распределенной транзакции интерфейс Cancel второй фазы выполняется перед интерфейсом Try. По причине разрешения пустого отката интерфейс Cancel считает, что интерфейс Try не выполнен, и пустой откат напрямую возвращает успех.Для платформы Seata считается, что интерфейс второй фазы распределенной транзакции был успешно выполнен. выполняется, и вся распределенная транзакция завершена. Но после этого метод Try действительно начинает выполняться и резервировать бизнес-ресурсы.Бизнес-блокировка контроля параллелизма транзакций упоминалась ранее.Для бизнес-ресурса, зарезервированного методом Try, можно использовать только распределенную транзакцию.Однако фреймворк Seata считает, что распределение Транзакция завершилась, то есть, когда это происходит, никто не может справиться с бизнес-ресурсами, зарезервированными на первом этапе распределенной транзакции, В этой ситуации мы называем это приостановкой, то есть бизнесом После ресурс зарезервирован, обработка не может быть продолжена.
Какая ситуация приведет к приостановке? Как упоминалось выше, когда выполняется вызов RPC, сначала регистрируется транзакция ответвления, а затем выполняется вызов RPC.Если сеть вызова RPC в это время перегружена, вызов RPC обычно имеет тайм-аут.После RPC-вызова время ожидания инициатор уведомляет TC о возврате. Прокручивание распределенной транзакции может привести к тому, что запрос RPC прибудет к участнику и фактически выполнится после завершения отката, что приведет к приостановке.
Как добиться антиподвески? По условиям возникновения приостановки сначала разберем ее.Приостановка означает, что первая фаза будет выполнена после выполнения второй фазы Отмена. То есть, чтобы избежать приостановки, если выполнение второго этапа завершено, этот этап не может продолжать выполняться. Поэтому при выполнении первого этапа необходимо проверить, был ли выполнен второй этап, если он был выполнен, то первый этап выполняться не будет, в противном случае он может выполняться нормально. Так как же проверить, был ли выполнен второй этап? Вы когда-нибудь задумывались о таблице управления транзакциями, используемой для решения пустого отката и идемпотентности прямо сейчас?Вы можете вставить запись управления транзакцией во время выполнения второго этапа, и статус откатится, так что, когда выполнение первого этапа будет выполняется, запись читается первой. , если запись существует, считается, что второй этап выполнен, в противном случае второй этап не выполнен.
3.3 Реализация управления исключениями
После анализа причин и решений аномальных случаев, таких как пустой откат, идемпотентность и приостановка, давайте рассмотрим, как интерфейс TCC может полностью решить эти три проблемы.
прежде всегоTry метод.В сочетании с пустым откатом и зависшими исключениями, упомянутыми выше, метод Try в основном должен учитывать две проблемы: во-первых, метод Try должен сообщать интерфейсу второго уровня, что бизнес-ресурсы успешно зарезервированы. Второй — проверить, был ли выполнен второй этап, и если да, то он не будет выполнен. Следовательно, логика метода Try может быть следующей:
Сначала вставьте запись таблицы управления транзакциями, если вставка прошла успешно, это означает, что второй этап не выполнен, и можно продолжить первый этап. Если вставка не удалась, это означает, что второй этап был выполнен или выполняется, выбрасывается исключение и можно выполнить завершение.
ДалееConfirm метод.Поскольку метод Confirm не допускает пустых откатов, то есть метод Confirm должен выполняться после метода Try. Следовательно, метод Confirm должен сосредоточиться только на повторяющихся отправках. Вы можете сначала заблокировать запись транзакции.Если запись транзакции пуста, это означает, что это пустой коммит, который не разрешен, и выполнение прекращается. Если запись транзакции не пуста, продолжаем проверять, инициализирован ли статус, если да, то это означает, что первый этап выполняется правильно, а второй этап может выполняться нормально. Если статус Submitted, то это считается повторной отправкой, и она может сразу вернуться к успеху, если статус Rolled Back, то это тоже исключение. удалось перехватить эту нештатную ситуацию и вызвать полицию.
Ну наконец тоCancel метод.Поскольку метод CANCEL допускает пустой откат и заставляет метод Try воспринимать Cancel, он немного отличается от CANCEL тем, что Cancel был выполнен. Во-первых, это по-прежнему блокирующая запись транзакции. Если запись транзакции пуста, считается, что метод TRY не был выполнен, т.е. пустой откат. В случае пустого возврата сначала следует вставить запись транзакции, чтобы гарантировать, что последующий метод TRY не будет выполнен. Если вставка прошла успешно, метод TRY еще не был выполнен, и пустой рулон продолжается. Если вставка не удалась, считается, что метод try выполняется, ожидая повторной попытки TC. Если прочитанная запись транзакции не пуста, то метод TRY был выполнен, проверка состояния — инициализация, если да, то другие методы второго этапа не выполнялись, а логика CANCEL выполняется нормально. Если статус откат, то это повторный вызов, разрешающий питание и т.д., напрямую вернуться к успеху. Если статус отправлен, это тоже исключение, отправленная транзакция не может откатиться снова.
Благодаря этой части объяснения вы должны иметь представление о трех наиболее распространенных аномальных случаях в модели TCC, причинах пустого отката, идемпотентности и приостановки, а также знать, как решать эти три типа исключений из практических примеров. В случае этих трех типов исключений наш дизайн интерфейса TCC относительно завершен. В будущем мы пересадим эти решения на фреймворк Seata, а фреймворк Seata завершит обработку исключений, и студентам, разрабатывающим интерфейс TCC, больше не нужно будет заботиться.
4. Оптимизация производительности TCC
Хотя модель TCC завершена, с ростом бизнеса задачи модели TCC становятся все больше и больше, и для удовлетворения потребностей бизнеса могут потребоваться некоторые специальные оптимизации. Далее мы расскажем вам, какие оптимизации Ant Financial внесла в модель TCC.
4.1 Тот же режим библиотеки
Первое решение по оптимизации — перейти в тот же режим библиотеки. Один и тот же режим библиотеки просто означает, что записи транзакций филиала и бизнес-данные находятся в одной библиотеке. Что это обозначает? Как упоминалось ранее, при регистрации записи транзакции ветки вызывающий аспект платформы сначала регистрирует запись транзакции ветки в TC.После успешной регистрации он продолжит выполнение вызова RPC. После получения запроса на регистрацию записи транзакции филиала TC вставит запись транзакции филиала в свою собственную базу данных, чтобы обеспечить постоянное хранение данных транзакции. Тот же режим библиотеки означает, что вызывающий аспект больше не регистрируется в TC, а напрямую вставляет запись транзакции в бизнес-базу данных.
Прежде чем объяснять тот же режим точки оптимизации производительности базы данных, кратко расскажем о режиме логической библиотеки восстановления. Зафиксировать или откатить распределенную транзакцию или уведомление TC инициатором, но из-за филиальных записей бизнес-транзакций, хранящихся в базе данных, а не завершения TC. Поэтому ТС не знает, какую ветвь транзакции зафиксировать в квитанции уведомления о подаче или откате, только состояние распределенной транзакции зафиксирует ее. Эта транзакция ветки записывает, как реальная реализация второго этапа этого? Необходимо запустить участника в рамках каждой асинхронной задачи, периодически получать запись транзакции базы данных службы филиала, которая не была завершена, затем всю распределенную транзакцию для проверки состояния TC, т.е. запрос StateCheckRequest на фиг. TC после получения запроса, в соответствии с ранее сохраненным состоянием распределенной транзакции, сообщает участникам о фиксации или откате для завершения записи ветки транзакции.
Тогда что это хорошо, это делать? Слева использует одну и ту же базу данных перед режимом графика вызовов, каждый вызов к времени участника представляет собой Xianxiang TC зарегистрировал распределенную запись транзакций, а затем TC постоянно хранится в своей собственной базе данных, то есть зарегистрированных записей транзакций, включая RPC, И еще раз постоянное хранение.
Справа — оптимизированный график вызовов. Как видно из рисунка, каждый раз, когда участник звонит, он напрямую сохраняется в бизнес-базе, тем самым сокращая RPC-вызовы с TC. После оптимизации количество вызовов RPC равно числу участников.
Это схема производительности того же библиотечного режима. Сохраняйте записи транзакций филиала в бизнес-базе данных, тем самым сокращая число вызовов RPC с помощью TC.
4.2 Асинхронный
Другой метод оптимизации производительности — асинхронность. Что такое асинхронность? Одной из функций модели TCC является разделение двух фаз на две независимые фазы, которые связаны посредством блокировки бизнес-ресурсов. Преимущество метода ресурсной бизнес-блокировки заключается в том, что он не будет блокировать дальнейшее использование того же ресурса другими транзакциями на первом этапе и не повлияет на правильное выполнение второго этапа транзакции. Теоретически, пока бизнес позволяет, вторая фаза транзакции может быть выполнена в любое время, но в любом случае ресурсы заблокированы бизнесом, и никакие другие транзакции не будут использовать ресурсы, заблокированные транзакцией.
Предполагая, что существует только одна промежуточная учетная запись, каждый раз, когда вызывается интерфейс Commit из платежной службы, промежуточный счет будет заблокирован, а промежуточная учетная запись имеет проблемы с высокой производительностью.
Однако в сценарии защищенной транзакции средства должны быть переведены с промежуточного счета продавцу через семь дней, и промежуточный счет не нужно отображать для внешнего мира. Таким образом, после выполнения первого этапа платежного сервиса можно считать, что платежное звено данной транзакции выполнено, и пользователю и продавцу возвращается успешный результат платежа. Коммит-интерфейс второго этапа платежного сервиса.В период низкого фронта он медленно переваривается и выполняется асинхронно.
5. Резюме
Сегодня был проведен глубокий анализ режима Seata TCC. Он в основном знакомит с принципом режима Seata TCC и рассказывает, как спроектировать интерфейс TCC и как работать с исключениями, такими как пустой откат, идемпотентность и приостановка, с точки зрения бизнес-модели TCC и контроля параллелизма. Производительность TCC в Ant Financial Краткое введение позволяет модели TCC удовлетворить более высокие потребности бизнеса.
Предприятия разные, некоторые предприятия могут терпеть краткосрочные несоответствия, а некоторые бизнес-операции могут быть идемпотентными.Независимо от того, какое решение для распределенных транзакций имеет свои преимущества и недостатки, ни одна серебряная пуля не может удовлетворить всех. Следовательно, какое решение необходимо бизнесу, необходимо сочетать с его собственными бизнес-потребностями, бизнес-характеристиками, технической архитектурой и характеристиками каждого решения, и для поиска наиболее подходящего решения можно использовать всесторонний анализ.
Если у вас есть собственные идеи о производительности и потребностях Seata, вы можете обсудить их с нами в группе DingTalk (номер группы: 23127468) или на Github.
Сеата:github.com/seata/seata
Сегодняшняя трансляция подошла к концу, всем спасибо!
Видеообзор этого выпуска и адрес просмотра PPT
specialty.ant fin.com/activities/…
Яркие моменты прошлых прямых трансляций
- SOFAChannel#3 Практика оптимизации производительности SOFARPC (ниже):specialty.ant fin.com/activities/…
- SOFAChannel#2 Практика оптимизации производительности SOFARPC (часть 1):specialty.ant fin.com/activities/…
- SOFAChannel#1 начинается с практики микросервисов Ant Financial:specialty.ant fin.com/activities/…
Официальная учетная запись: распределенная архитектура финансового уровня (Antfin_SOFA)