Общедоступная учетная запись WeChat «Back-end Advanced», ориентированная на совместное использование серверных технологий: Java, Golang, WEB-инфраструктура, распределенное промежуточное программное обеспечение, управление услугами и т. д.
В системе микросервисной архитектуры мы можем проектировать уровни в соответствии с бизнес-модулями и развертывать их отдельно, что снижает нагрузку на развертывание сервисов и разъединяет бизнес-связь, предотвращая постепенное превращение приложения в монстра, чтобы его можно было легко расширять. , Сбой некоторых служб не повлияет на нормальную работу других служб. Словом, микросервисы приносят нам все больше и больше преимуществ в быстром развитии бизнеса, но микросервисы не совершенны, поэтому ими нельзя злоупотреблять вслепую, они имеют много недостатков и вносят определенную сложность в систему.Сопутствующая проблема распределенных транзакций — это болевая точка, с которой необходимо иметь дело в рамках системы микросервисной архитектуры, и это также область, на которую обращает внимание отрасль, поэтому также появились такие теории, как CAP и BASE.
В начале этого года Alibaba открыла промежуточное программное обеспечение для распределенных транзакций, которое первоначально называлось Fescar, а затем было переименовано в Seata.Когда исходный код был открыт, я знал, что он определенно станет популярным, потому что это проект с открытым исходным кодом. который решает болевые точки Seata С самого начала он был направлен на невмешательство и высокую производительность бизнеса, что является нашей насущной необходимостью для решения проблемы распределенных транзакций. Потому что те немногие компании, с которыми я работал, все используют микросервисную архитектуру, но они не очень элегантны в решении проблемы распределенных транзакций, поэтому я уделял внимание развитию Seata, и сегодня кратко расскажу о некоторых его Принцип работы, в дальнейшем я проведу глубокий анализ исходного кода различных его модулей, а кому интересно, могут и дальше следить за моим официальным аккаунтом или блогом, и не терять его.
Каковы решения для распределенных транзакций?
В настоящее время решения для распределенных транзакций в основном включают в себя решения для предотвращения вторжений и вторжений в бизнес.Решения для предотвращения вторжений в основном включают решение для двухэтапной отправки (2PC), основанное на протоколе базы данных XA.Его преимущество заключается в том, что оно не имеет вторжений. к бизнес-коду, но его недостатки также очевидны: база данных должна быть обязательной для поддержки протокола XA, а из-за особенностей самого протокола XA это приведет к тому, что ресурсы транзакций не будут освобождены в течение длительного времени, блокировка цикл длинный, и прикладной уровень не может вмешиваться, поэтому его производительность очень плохая, его существование эквивалентно «семи баллам за причинение вреда другим и трем баллам за причинение вреда себе», поэтому это решение не очень популярно в интернет-проектах.
Чтобы компенсировать проблему низкой производительности, вызванную этим решением, большие ребята придумали множество решений для решения этой проблемы, но всеми без исключения ими нужно манипулировать на прикладном уровне, то есть способом вторжения в бизнес, такие как известные Есть много зрелых структур, основанных на TCC, таких как ByteTCC, tcc-транзакция и так далее. И окончательная согласованность на основе надежных сообщений, таких как сообщения о транзакциях RocketMQ.
Решения по взлому кода основаны на существующей ситуации, и являются "обязательными" решениями. На самом деле они очень неэлегантны в реализации. Вызов транзакции обычно сопровождается серией обратных операций, добавленных в интерфейс транзакции , таких как трехэтапная отправка TCC, логика отправки должна сопровождаться логикой отката, такой код сделает проект очень раздутым, а стоимость обслуживания будет высокой.
Взаимосвязь между модулями Seata
Принимая во внимание упомянутые выше болевые точки решения для распределенных транзакций, очевидно, что наше идеальное решение для распределенных транзакций должно иметь более высокую производительность и не вмешиваться в бизнес.Бизнес-уровню не нужно заботиться об ограничениях механизма распределенных транзакций. Он развивается в этом направлении, поэтому его очень стоит ждать, и он принесет качественное улучшение нашей микросервисной архитектуры.
Так как же Seata это сделала? Поговорим о взаимосвязи между различными его модулями.
Идея дизайна Seata заключается в том, что распределенную транзакцию можно понимать как глобальную транзакцию, а несколько ветвей транзакций висят ниже, а ветвь транзакции — это локальная транзакция, которая удовлетворяет ACID, поэтому мы можем оперировать распределенными транзакциями так, как если бы они работали локально транзакции.
Seata определяет три внутренних модуля для управления отношениями и обработкой глобальных транзакций и транзакций филиалов.Три компонента:
- Координатор транзакций (TC): координатор транзакций поддерживает текущее состояние глобальной транзакции и отвечает за координацию и управление фиксацией или откатом глобальной транзакции.
- Диспетчер транзакций (TM): контролирует границы глобальных транзакций, отвечает за открытие глобальной транзакции и, наконец, инициирует глобальную фиксацию или разрешение глобального отката.
- Диспетчер ресурсов (RM): контролирует транзакции филиалов, отвечает за регистрацию филиалов, отчеты о состоянии и получает инструкции от координатора транзакций для управления фиксацией и откатом транзакций филиала (локальных).
Кратко расскажем об этапах выполнения всей глобальной транзакции:
- TM обращается к TC для открытия глобальной транзакции, и TC возвращает глобально уникальный XID после создания глобальной транзакции, и XID будет распространяться в контексте глобальной транзакции;
- RM регистрирует транзакцию ветвления в TC, а транзакция ветвления принадлежит глобальной транзакции с тем же XID;
- TM инициирует глобальную фиксацию или откат к TC;
- TC планирует транзакцию ветвления под XID для завершения фиксации или отката.
Чем она отличается от схемы XA?
Метод отправки транзакции Seata в основном такой же, как и двухэтапная отправка протокола XA, так в чем же между ними разница?
Мы все знаем, что протокол XA полагается на уровень базы данных для обеспечения согласованности транзакций, то есть каждая транзакция ветвления XA управляется на уровне базы данных.Поскольку каждая транзакция ветвления XA требует драйвера XA, с одной стороны, это приведет к связыванию между базой данных и XA-драйвером, а с другой стороны, к длительному циклу блокировки транзакционных ресурсов каждого филиала, что также является немаловажным фактором того, что он не популярен в интернет-компаниях.
Основываясь на проблемах выше протокола XA, Seata выбрала другой подход. Поскольку использование уровня базы данных вызовет так много проблем, я буду делать это на уровне приложения. Это должно начаться с модуля RM Seata. упомянул основную роль RM. Фактически, RM создал внутренний прокси-уровень для операций с базой данных, а именно:
У Seata есть прокси-уровень в источнике данных, поэтому, когда мы используем Seata, используемый нами источник данных фактически использует прокси-сервер источника данных DataSourceProxy, который поставляется с Seata. зеркалирование бизнес-данных до и после обновления в журнал отката и вставка журнала отмены в таблицу undo_log, чтобы убедиться, что каждый бизнес-код SQL, который обновляет данные, имеет соответствующий журнал отката.
Преимущество этого заключается в том, что локальная транзакция может немедленно освободить ресурсы, заблокированные локальной транзакцией, после выполнения локальной транзакции, а затем сообщить о состоянии ветки в TC. Когда TM разрешает глобальную отправку, нет необходимости в синхронной обработке координации. TC будет асинхронно планировать каждую транзакцию ветви RM для удаления соответствующего журнала отмены. Этот шаг можно выполнить очень быстро; когда TM разрешает глобальный откат, RM получает запрос на откат, отправленный ТС, RM находит соответствующий журнал отката через XID, а затем выполняет журнал отката для завершения операции отката.
Как показано на рисунке выше, RM схемы XA размещается на уровне базы данных, который опирается на драйвер XA базы данных.
Как показано на рисунке выше, RM Seata фактически размещается на прикладном уровне в виде промежуточного программного обеспечения, не полагаясь на поддержку протокола базой данных, и полностью лишен требований схемы распределенных транзакций для поддержки протокола базой данных.
Как транзакции филиалов фиксируются и откатываются?
Далее подробно описывается, как транзакции ветвей фиксируются и откатываются:
- Первый этап:
Транзакция филиала использует агент источника данных JDBC в модуле RM, добавляет несколько процессов, интерпретирует бизнес-SQL, организует зеркало бизнес-данных до и после обновления в журнал отката и создает журнал журнала отмены для проверки глобальная блокировка транзакций, а также регистрация транзакций ветвей и т. д., используя функцию ACID локальных транзакций, бизнес-SQL и журнал отмены записываются в одно и то же и отправляются в базу данных вместе, гарантируя, что должен быть соответствующий журнал отката в бизнес-SQL, и, наконец, статус транзакции филиала отправляется в отчет TC.
- вторая стадия:
Глобальное представление TM Resolution:
Когда разрешение TM представлено, нет необходимости в синхронной обработке координации.TC будет асинхронно планировать каждую транзакцию ветви RM для удаления соответствующего журнала журнала отмены.Этот шаг можно выполнить очень быстро. Этот механизм очень важен для повышения производительности. Мы знаем, что во время обычной работы вероятность успешного выполнения транзакции очень высока, поэтому ее можно отправить непосредственно в локальную транзакцию. Этот шаг очень важен для повышения производительности.
Глобальный откат разрешений ТМ:
Когда TM решает выполнить откат, RM получает запрос на откат, отправленный TC.RM находит соответствующий журнал отката через XID, а затем использует функцию ACID локальной транзакции для выполнения журнала отката для завершения операции отката. и удалите журнал отмены. Наконец, сообщите результат отката в TC.
Бизнес не в курсе всех вышеперечисленных процессов, и бизнес не заботится о конкретной подаче и откате глобальной транзакции, а самое главное то, что Seata раскладывает синхронизацию и согласование двухэтапной подачи на каждую транзакцию филиала, и транзакция филиала отличается от обычной транзакции.Нет никакой разницы в локальной транзакции уровня базы данных, что означает, что после того, как мы используем Seata, распределенная транзакция похожа на использование локальной транзакции, а механизм координации транзакций базы данных уровень полностью передан промежуточному уровню Seata, так что, хотя координация транзакций перенесена на прикладной уровень, теперь он доступен, но он по-прежнему может обеспечить нулевое вмешательство в бизнес, тем самым лишив схему распределенных транзакций требований базы данных на поддержку протокола, и Seata напрямую освобождает ресурсы после завершения транзакции ветки, что значительно снижает влияние ресурсов на транзакцию ветки.Это полностью устраняет проблему, связанную с синхронизацией и координацией протокола XA, чтобы вызвать время блокировки ресурсов. быть слишком длинным.
Дополнение к другим программам
Вышеприведенный фактически режим Seata по умолчанию, также называемый режимом AT. Это двухэтапная схема отправки, аналогичная схеме XA, и она не навязчива для бизнеса, но этот механизм по-прежнему должен полагаться на функцию ACID. локальной транзакции базы данных.Вы заметили, что на приведенных выше диаграммах я подчеркнул, что это должна быть реляционная база данных, которая поддерживает функции ACID, тогда возникает проблема, нереляционные или не-ACID базы данных не могут использовать Seata, не не паникуйте, Seata в настоящее время находится на этом этапе. Для нас подготовлен другой режим, называемый режимом MT, который представляет собой навязчивое решение для бизнеса. Такие операции, как фиксация и откат, должны быть определены нами самостоятельно. Бизнес-логика должна быть декомпозируется на три части: Prepare/Commit/Rollback для формирования ветки MT добавляется в глобальную транзакцию, смысл ее существования в том, чтобы достичь большего количества сценариев для Seata.
Тем не менее, это не «основная» модель Seata, ее существование является лишь дополнительным решением.Из приведенных выше официальных перспектив развития видно, что цель Seata всегда быть решением, которое не вторгается в бизнес.
Примечание. Дизайн изображения в этой статье относится к официальному изображению Seata.