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

В прошлом году я написал статью о распределенных транзакциях.Если кто-то снова спросит вас о распределенных транзакциях, киньте ему это. В этой статье я прошу всех не использовать распределенные транзакции без распределенных транзакций, потому что это внесет много сложностей. Когда я сказал это, на самом деле была еще одна причина: не было зрелых решений с открытым исходным кодом от крупных производителей.Хотя в Интернете было много сред распределенных транзакций с открытым исходным кодом, они не были слишком зрелыми и не прошли много бизнес-проверки. У него нет большого количества зрелых решений, как у других распределенных промежуточных программ, таких как промежуточное ПО распределенных очередей сообщений: Apache Kafka, Apache RocketMQ и Apache Pulsar — ​​все это проекты верхнего уровня Apache; такие как распределенное планирование задач, их также много. программ с открытым исходным кодом, таких как XXL-JOB, Elastic-Job, используются многими компаниями.

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

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

2. Первое знакомство с Fescar

Прежде чем говорить о Fescar, вот краткое введение в знаменитые транзакции 2PC:XA. В протоколе XA есть две фазы:

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

Этап 2: Координатор транзакций просит каждую базу данных зафиксировать данные или откатить данные.

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

недостаток:

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

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

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

В своей статье я представил несколько распределенных транзакций на уровне приложений, но более или менее влияющих на бизнес. Например, в нашем TCC некоторые часто используемые фреймворки TCC требуют написания интерфейсов, таких как try, confirm, cancel и т. д., чтобы преобразовать готовый бизнес. Если используется режим локальной таблицы сообщений, необходимо добавить дополнительные таблицы. Если используются транзакционные сообщения, такие как RocketMQ, некоторым предприятиям, которые не используют очередь сообщений, потребуется заменить очередь сообщений. Если принят режим Saga, нам также необходимо написать прямой и обратный интерфейсы. Можно видеть, что независимо от того, какая схема распределенных транзакций будет принята, будут определенные затраты на трансформацию бизнеса и вмешательство в бизнес.

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

2.1 Фескар и XA

Хотя Fescar является распределенной транзакцией протокола двухфазной фиксации, он решает некоторые недостатки вышеупомянутого XA:

• Проблема с одной точкой: хотя Fescar (0.4.1) в настоящее время по-прежнему является единым сервером, Fescar официально планирует запустить HA-Cluster в версии 0.5.x, и тогда проблема с одной точкой может быть решена.
• Синхронная блокировка: второй этап Fescar, локальная транзакция уже зафиксировала и освободила ресурсы на первом этапе, в отличие от XA, где ресурсы блокируются на двух этапах подготовки и фиксации, и Fescar, фиксация — это асинхронная операция, также ключ к улучшению производительности.
• Несогласованность данных: если частичная фиксация завершается неудачно, fescar-server реализует различные стратегии повторных попыток в соответствии с текущим режимом транзакции и результатом статуса возврата транзакции ветки. И локальная транзакция fescar будет зафиксирована в одну фазу.На самом деле, просто взглянув на базу данных, она уже непротиворечива на момент фиксации.
• Может использоваться только с одной базой данных: Fescar предлагает два режима: AT и MT. В режиме AT ресурсами транзакций может быть любая база данных, поддерживающая ACID, в режиме MT ресурсы транзакций не ограничены, это могут быть кэши, файлы и т.д. Конечно, эти два режима также можно смешивать.

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

3. Общий дизайн Fescar

В основе дизайна Фескара лежит его классификация персонажей. И XA, и Fescar в базе данных имеют две роли TM (менеджер транзакций) и RM (менеджер ресурсов), а у Fescar также есть TC (координатор транзакций). Давайте сначала посмотрим, что будет, если ТС не будет, а только ТМ и РМ? Здесь я привожу простой пример, Сяомин зашел на сайт, чтобы купить товар, как показано на следующем рисунке:

Здесь Сяомин на самом деле является TM (менеджером транзакций), а товары и счета на самом деле являются нашим RM (менеджером ресурсов).При нормальных обстоятельствах может не быть заданных вопросов, и учетная запись и инвентарь могут быть успешно вычтены. Если Сяомину удастся вычесть инвентарь, но не удастся вычесть учетную запись, нам нужно откатить наши ресурсы инвентаря в это время. В это время Сяо Мин уведомит инвентарь, чтобы восполнить товары, вычтенные на предыдущем этапе. Однако при откате инвентаризации служба инвентаризации работала нестабильно, и на этот раз откат завершился неудачно. Вообще говоря, Сяомин будет продолжать попытки, пока не добьется успеха. Таким образом, возникает проблема, что Сяомин заблокирован и ничего не может сделать. Это также можно увидеть, поскольку двухэтапная фиксация/откат всегда будет блокировать TM, а протокол XA NetEase DDB будет выполнять асинхронную операцию потока для этой ситуации. Но в Fescar все делает ТС.Конечно, ТС будет делать не только повторную попытку отказа второго этапа, но и все коммиты и откаты РМ на втором этапе, так что наши ТМ может сделать меньше работы.

Отношения между TM, RM и TC в Fescar показаны на следующей официальной диаграмме:

• ТМ: Инициатор транзакции. Говорил ТС, начало мировых дел, подавай, и откатись.
• RM: Для конкретных ресурсов транзакций каждый RM будет зарегистрирован в TC как транзакция филиала.
• ТК: Координатор сделки. Его также можно рассматривать как Fescar-servr, который используется для получения регистрации, фиксации и отката наших транзакций.

Четкое разделение труда между этими тремя ролями — настоящая суть нашего Fescar.Ниже я покажу вам, как использовать Fescar, чтобы лучше понять эти три роли.

4. Быстрый старт Фескар

Простой пример был предоставлен на github Fescar https://github.com/fescar-group/fescar-samples, здесь нам нужно скачать этот пример.

4.1 Сборка TC Fescar-сервера

Прежде всего, мы создаем координатор транзакций, который также можно назвать созданием Fescar-Server, Пример официального веб-сайта - использовать Nacos и пакет Jar, который был создан fescar-server для запуска. Здесь, для нашего удобства, мы можем напрямую скачать код fescar https://github.com/alibaba/fescar.

Найдите наш сервер:

Запускаем метод main напрямую, что поможет нам локально запустить службу fescar-server с номером порта 8091. Если мы хотим выполнить регистрацию службы, мы можем изменить тип в реестре.conf

Видно, что в версии 0.4.1 поддерживаются четыре регистрации сервисов, nacos, eureka, redis, zk. На данный момент есть проблема с использованием redis для регистрации сервисов, так же отправил PR официалам на исправление. Конечно, для удобства собственно выбора файла нам удобнее всего подключаться напрямую.

После повторного запуска основного метода, если появится журнал «Сервер запущен», это означает, что наш TC (координатор транзакций) успешно стартовал.

4.2 Знакомство с ТМ

Вышеупомянутый координатор транзакций создан, и теперь нам нужно запустить TM и RM и передать соответствующие операции нашему координатору транзакций. В это время нам нужно открыть проект fescar-samples: поскольку RPC, используемый в этом проекте, — Dubbo, а его центр регистрации служб по умолчанию — Nacos, нам нужно установить Nacos локально, и конкретную установку можно найти самостоятельно. , который здесь обсуждаться не будет.

В официальном примере здесь деловые отношения выглядят следующим образом:

Вы можете увидеть, что Business — это наша торговая марка, и найти соответствующий код:

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

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

Что именно делает эта аннотация GlobalTranscational? На самом деле те, кто добавляет эту аннотацию, возьмут раздел под названием GlobalTransactionalInterceptor, а затем этот раздел войдет в метод execute в классе TrascationTemplate, который также является основным методом TM:

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

1. Получить, есть ли уже транзакция в текущем контексте.Этот шаг реализуется через ThreadLocal.Если есть, то получить текущую, а если нет, то получить транзакцию по умолчанию.
2. Чтобы начать транзакцию, этот шаг заключается в отправке запроса TC (координатору транзакции) для регистрации GloabTranscation, тайм-аут здесь означает, что нет ни отката, ни фиксации больше этого периода времени, и TC поможет нам сделать откат.
3. заниматься бизнесом.
4. Откат, если метод выдает исключение. Здесь следует отметить, что когда выбрасывается исключение, мы много раз перехватываем исключение, так что у нас вообще не выбрасывается исключение, поэтому отката не будет. Откат здесь тоже для того, чтобы инициировать запрос отката к ТС, который поможет нам откатить РМ.
5. Если нет исключения, инициируйте фиксацию в TC, и TC поможет нам асинхронно инициировать отправку запроса в RM.

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

4.3 Знакомство с РМ

Когда мы запустили вышеприведенный запрос на бизнес-сервис пришел к процессам RM US, наше хранилище и заказ знают, как услуги теперь в распределенной транзакции? Это необходимо выполнить с помощью RPC Framework, мы использовали здесь, это Dubbo, fegar dubbo, чтобы обеспечить фильтр, как показано ниже:

Здесь мы получим наш xid из rpcContext, который является нашим идентификатором распределенной транзакции.Если он есть, это докажет, что запрос находится в распределенной транзакции, затем XID будет помещен в наш RootContext (локальный контекст fescar). Если вы не Dubbo, вы также можете адаптировать свой RPC по этому методу.

Что нам делать в РМ? Просто выполните следующие два шага:

1. Изменить источник данных на прокси Fescar

   

2. Undolog добавить таблицу в текущую базу данных для записи лога прокрутки.

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

Мы все знаем, что конкретное выполнение нашего SQL должно полагаться на оператор.В фескаровском StatementProxy есть следующий код:

Можно увидеть, как работает метод ExecuteTemplate.execute, который будет записывать наш Undolog в соответствии с типом, который мы выполняем в методе выполнения, с конкретной ссылкой на следующий официальный процесс реализации изображения:

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

5. Резюме

Цель написания этой статьи состоит не только в том, чтобы все узнали о Fescar, но и в том, чтобы больше людей узнали, что должна делать превосходная структура распределенных транзакций. В настоящее время номер версии Fescar — 0.4.1, и многие функции, такие как HA-Cluster, интеграция SpringCloud, еще не выпущены. Поэтому, если вы используете его в Интернете в настоящее время, вы можете столкнуться с проблемой одной точки Fescar, поэтому не рекомендуется использовать его в Интернете. Текущий план Fescar — запустить HA-Cluster в версии 0.5.x, после чего будет решена его проблема с одной точкой.

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

Наконец, эта статья была включена в JGrowing-Java Distributed Transactions, всеобъемлющий и отличный маршрут изучения Java, совместно созданный сообществом.Если вы хотите участвовать в обслуживании проектов с открытым исходным кодом, вы можете создать его вместе.Адрес github:GitHub.com/Java растет…Пожалуйста, дайте мне маленькую звезду.

Если вы считаете, что эта статья полезна для вас, то ваше внимание и пересылка - самая большая поддержка для меня, O(∩_∩)O:

Справочная статья

Решение Fescar для распределенных транзакций Ali с открытым исходным кодом:Tickets.WeChat.QQ.com/Yes/TF GRC HV6E…