Во все времена к людям, способным учиться, не будут относиться плохо.
Всем привет, меня зовут да.
Сегодня я хочу поделиться с вами диском распределенных транзакций, познакомлю вас с распространенными схемами реализации распределенных транзакций, их преимуществами и недостатками, применимыми сценариями, а также приведу некоторые варианты их реализации.
Я также рассмотрю улучшенную модель распределенной базы данных для 2PC и посмотрю, как это делает распределенная база данных.
Затем проанализируйте конкретную реализацию волны распределенных транзакций Seata, чтобы увидеть, как реализованы распределенные транзакции.В конце концов, внедрять протоколы полезно.
Сначала давайте упомянем, что такое транзакции и распределенные транзакции.
дела
ACID транзакций должен быть знаком всем, это на самом деле определение в строгом смысле, означающее, что реализация транзакций должна иметь атомарность, непротиворечивость, изоляцию и долговечность.
Однако транзакций в строгом смысле добиться трудно.Базы данных, подобные нашим известным базам данных, имеют различные уровни изоляции.Чем выше уровень изоляции, тем ниже производительность.Часто мы найдем собственный баланс и не будем следовать строгому смыслу вещей..
И в наших повседневных обсуждениях так называемая транзакция часто просто означает, что серия операций выполнена успешно или все терпят неудачу, и не будет ни успеха, ни неудачи.
Уточнив наше определение транзакции в рабочие дни, давайте посмотрим, что такое распределенная транзакция.
Распределенная транзакция
Из-за стремительного развития Интернета предыдущая монолитная архитектура не могла выдержать такое количество требований, такой сложный бизнес и такой большой объем трафика.
Преимущество монолитной архитектуры в том, что ее можно быстро построить на ранней стадии, и ее можно быстро запустить, и есть внутренние вызовы между методами и модулями, что более эффективно без накладных расходов на сеть.
В некотором смысле, это также легко развернуть, ведь это всего лишь мешок, подкинь его.
Однако с развитием предприятия сложность бизнеса становится все выше и выше, а внутренняя связанность крайне серьезна.
И невозможно динамическое масштабирование по горячим сервисам.Например, объем доступа товарных сервисов особенно велик.Если это монолитная архитектура, мы можем только реплицировать все приложение в несколько кластеров и развертывать его, тратя ресурсы.
Следовательно, разделение является обязательным, и именно так возникает микросервисная архитектура.
После разделения границы между службами становятся четкими, и каждая служба может работать независимо и развертываться независимо, поэтому ее можно эластично масштабировать на уровне службы.
Локальные вызовы между службами становятся удаленными вызовами, связь становится длиннее, а вызов занимает больше времени, но общая пропускная способность выше.
Однако после разделения появятся другие сложности, такие как мониторинг служебных каналов, общий мониторинг, меры отказоустойчивости, эластичное масштабирование и другие вопросы мониторинга эксплуатации и обслуживания, а также вопросы, связанные с бизнесом, такие как распределенные транзакции и распределенные блокировки. Подождите.
Часто решение болевой точки приводит к появлению других болевых точек, поэтому эволюция архитектуры является результатом компромиссов., это зависит от того, какие болевые точки ваша система лучше переносит.
Сегодня мы говорим о болевой точке распределенных транзакций.
Распределенные транзакции состоят из нескольких локальных транзакций., Распределенные транзакции охватывают несколько устройств и проходят между ними через сложную сеть.Понятно, что путь к строгой реализации транзакций долог и труден.
Одномашинная версия транзакции не будет строго следовать строгой реализации транзакции, не говоря уже о распределенной транзакции, поэтому в действительности мы можем реализовать только неполную версию транзакции.
После разъяснения транзакций и распределенных транзакций давайте рассмотрим распространенные схемы распределенных транзакций: 2PC, 3PC, TCC, локальные сообщения, сообщения транзакций.
2PC
2PC, Two-phase commit protocol, то есть двухфазный протокол фиксации. Он вводит роль координатора транзакций для управления каждым участником (то есть каждым ресурсом базы данных).
Все разделено на две фазы, а именно фазу подготовки и фазу фиксации/отката.
Давайте взглянем на первый этап, этап подготовки.
Координатор транзакции отправляет команду подготовки каждому участнику, и каждый участник после получения команды выполнит соответствующую транзакционную операцию.Можно считать, что все сделано, кроме отправки транзакции.
Затем каждый участник вернет ответ, сообщающий координатору, готов он или нет.
Координатор переходит ко второму этапу после получения ответа от каждого участника, по собранным ответам, если один участник не отвечает на подготовку, то отправить всем участникам команду отката, в противном случае отправить команду фиксации.
Это соглашение на самом деле соответствует нормальному мышлению: точно так же, как когда мы созываем класс в нашем университете, преподаватель на самом деле является координатором, а мы все участники.
Учитель звонил один за другим, и мы звонили один за другим Наконец, учитель начал сегодняшнюю лекцию после того, как все студенты прибыли.
В отличие от переклички,Учитель обнаруживает, что некоторые ученики отсутствуют и могут продолжить занятие, а наши дела не позволяют этого.
Если координатор транзакций не получит ответа от отдельных участников на первом этапе, он посчитает транзакцию неудачной после ожидания определенного периода времени и отправит команду отката, поэтому координатор транзакций имеет механизм тайм-аута в 2PC. .
Давайте еще раз проанализируем преимущества и недостатки 2PC.
Преимущества 2PCВозможно использование функций самой базы данных для отправки и отката локальных транзакций, то есть реальную операцию отправки и отката нам реализовывать не нужно, а бизнес-логика не навязчива.
2PC имеет три основных недостатка: блокировка синхронизации, единая точка отказа и проблемы с несогласованностью данных.
синхронная блокировка
Видно, что после выполнения команды подготовки на первом этапе мыКаждый локальный ресурс заблокирован, потому что делается все, кроме фиксации транзакции.
Таким образом, в это время, если другие локальные запросы хотят получить доступ к тому же ресурсу, например, для изменения данных с идентификатором товарной таблицы, равным 100, то он в это время блокируется и должен ждать завершения предыдущей транзакции для получить команду фиксации/отката. После выполнения ресурса освобождения запрос может быть продолжен.
Итак, предположим, что в этой распределенной транзакции участвует много участников, и некоторые из участников особенно сложны и медленны в обработке, тогда тем узлам, которые обрабатывают быстро, придется ждать, поэтому эффективность немного ниже.
единая точка отказа
могу видеть этоЕдинственная точка — это координатор, если координатор зависает всю транзакцию, она не будет выполнена..
Если координатор зависает до отправки команды prepare, ведь каждый ресурс еще не выполнил команду, то ресурс не заблокирован.
Страшно то, что он зависает после отправки команды подготовки.В это время каждый локальный ресурс находится в заблокированном состоянии после выполнения, и все это зависает.Это очень жестко.Если горячий ресурс блокируется, считается, что К ГГ.
несогласованность данных
Потому что общение между координатором и участниками происходит через сеть, а сеть иногда страдает конвульсиями или локальными сетевыми аномалиями.
Тогда возможно, что некоторые участники не могут получить запрос координатора, а некоторые получают. Например, подается запрос, а затем участники, получившие команду, подают транзакцию, и в это время возникает проблема несоответствия данных.
Резюме 2PC
Итак, давайте подытожим некоторые 2PC, которые представляют собой двухэтапный протокол фиксации с синхронной блокировкой и строгой согласованностью, который является фазой подготовки и фазой фиксации/отката.
Преимущество 2PC в том, что нет вторжения в бизнес, а для фиксации и отката транзакций можно использовать собственный механизм базы данных.
Его недостатки: это протокол синхронной блокировки, что приведет к высокой задержке и падению производительности, и будет единая точка отказа координатора, а в крайних случаях будет несогласованность данных.
Конечно, это всего лишь соглашение, и конкретная реализация может быть гибкой., такие как проблема с одной точкой координатора, я сделаю мастер и всегда реализую координатор, правильно.
2PC Модель улучшения распределенной базы данных
Может быть, некоторые люди незнакомы с распределенными базами данных, это не имеет значения, мы в основном учимся думать, давайте посмотрим на идеи других людей.
Кратко расскажу о модели Percolator,Это модель, основанная на распределенной системе хранения BigTable., неважно, если BigTable — одноклассник, который ничего об этом не знает.
Возьмем пример перевода.У меня сейчас 200 юаней, а у вас сейчас 100. Чтобы выделить ключевые моменты, я не буду рисовать эту таблицу в соответствии с обычной структурой.
Тогда я переведу тебе 100 юаней.
В этот момент менеджер транзакций инициирует запрос на подготовку, после чего на моем счете становится меньше денег, на вашем счету больше денег, иМенеджер транзакций также записывает журнал этой операции..
В настоящее время данные все еще являются частной версией, и другие транзакции не могут их прочитать.Просто поймите, что в замке есть значение, и оно все еще является частным.
Вы видите, что моя запись Lock отмечена ПК, а ваша запись отмечена указателем на мою запись, этот ПК выбран случайным образом.
Затем менеджер транзакций выполнит фиксацию записи, выбранной в качестве PK.
В этот момент блокировка моей записи будет стерта, что означает, что моя запись больше не является частной версией, и другие транзакции могут получить к ней доступ.
Так у тебя все еще есть блокировка на твоей записи? Не нужно обновлять?
Эй, вам не нужно обновлять ее вовремя, потому что, когда вы получаете доступ к своей записи, вы найдете мою запись на основе указателя и обнаружите, что запись была отправлена, поэтому ваша запись может быть доступна.
Кто-то говорит, что эффективность неплохая, ее надо находить каждый раз, не переживайте.
Будет поток в фоновом режиме для сканирования, а затем обновления записи блокировки.
Разве это не стабильно.
Улучшения по сравнению с 2PC
Прежде всего, Percolator не нужно взаимодействовать со всеми участниками на этапе коммита, мастеру нужно иметь дело с одним участником, так что этот коммит является атомарным!Решены проблемы с несогласованностью данных.
Затем менеджер транзакций будет записывать журнал операций, так что, когда менеджер транзакций кладет трубку, выбранный новый менеджер транзакций может узнать текущую ситуацию через журнал и продолжить работу.Решена проблема единой точки отказа.
Кроме того, в Percolator есть фоновый поток, который сканирует статус транзакции и откатывает транзакции для каждого участника после того, как диспетчер транзакций выходит из строя.
Видно, что сделано много улучшений по сравнению с 2PC, что тоже гениально.
На самом деле существуют и другие модели транзакций для распределенных баз данных, но я с ними не слишком знаком, поэтому не буду сильно пищать, заинтересованные студенты могут ознакомиться с ними самостоятельно.
Это все еще заставляет задуматься.
Спецификация XA
Вернемся к 2PC. Раз уж мы заговорили о 2PC, давайте вкратце упомянем спецификацию XA, которая основана на двухфазной фиксации, которая реализует протокол двухфазной фиксации.
Прежде чем говорить о спецификации XA, мы должны упомянуть модель DTP, а именно распределенную обработку транзакций, которая регулирует структуру модели распределенных транзакций.
Спецификация XA ограничивает взаимодействие между менеджером транзакций (TM) и менеджером ресурсов (RM) в модели DTP.Проще говоря, вы оба должны общаться в соответствии с определенной спецификацией формата!
Давайте сначала рассмотрим модель DTP с ограничениями XA.
- Приложение AP — это наше приложение, инициатор транзакции.
- Менеджер ресурсов RM считается просто базой данных с возможностями отправки и отката транзакций, а 2PC выше — участником.
- Менеджер транзакций TM, который является координатором, связывается с каждым RM.
Проще говоря, AP определяет операцию транзакции через TM, а TM и RM взаимодействуют через спецификацию XA для выполнения двухфазной фиксации, а ресурсы AP берутся из RM.
Из модели есть три роли, но фактическая реализация может быть реализована одной ролью для достижения двух функций, таких как AP для достижения функции TM, TM не нужно извлекать и развертывать отдельно.
MySQL XA
Познакомившись с DTP, давайте посмотрим, как XA работает в MySQL, но поддерживает его только InnoDB.
Проще говоря, необходимо сначала определить глобально уникальный XID, а затем информировать каждую ветвь транзакции об операциях, которые необходимо выполнить.
Видно, что на рисунке выполняются две операции, а именно изменение имени и вставка журнала, что эквивалентно регистрации действий, которые необходимо выполнить в первую очередь, и перенос SQL для выполнения через XA START XID и XA END XID.
Затем необходимо отправить команду подготовки для выполнения первой фазы, на которой выполняется все, кроме фиксации транзакции.
Затем выберите выполнение команды фиксации транзакции или команды транзакции отката в соответствии с подготовкой.
В основном это процесс, но нужно отметить, что производительность MySQL XA не высока.
Видно, что хотя у 2PC есть недостатки, он по-прежнему реализован на основе 2PC, и введение 3PC призвано устранить некоторые недостатки 2PC, но в целом он стоит дороже и не может решить проблему сетевого разделения. нашел.реализация 3PC.
Но я все же немного упоминаю об этом, просто знайте, чистая теория.
3PC
Внедрение 3PC призвано устранить блокировку синхронизации 2PC и уменьшить несогласованность данных.
3PC — это дополнительный этап, этап запроса, представляющий собой три этапа подготовки, предварительной подачи и подачи.
Этап подготовки заключается в том, что координатор посещает участников, как у вас? Может принять запрос.
Предварительная фиксация на самом деле является подготовительной фазой 2PC, за исключением фиксации транзакции.
Этап фиксации такой же, как и у 2PC.
3PC имеет дополнительный этап для подтверждения того, что участники являются нормальными, перед выполнением транзакции, чтобы предотвратить выполнение транзакций другими участниками и блокировку ресурсов, когда отдельные участники ненормальны.
Хорошая отправная точка, ноВ большинстве случаев это должно быть нормально, поэтому нерентабельно иметь каждый раз дополнительный этап взаимодействия.
Затем 3PC также ввел механизм тайм-аута для участников, так что если координатор зависнет, если фаза фиксации уже достигнута, если участник долго не получит координатора, то транзакция будет автоматически зафиксирована.
Но что, если координатор пошлет команду отката? Вы видите, что это неправильно, данные противоречивы.
В Википедии также говорится, что после этапа подготовки участников 2PC, если координатор кладет трубку, участники не могут знать общую ситуацию, потому что общая ситуация контролируется координатором, поэтому участники не имеют четкого представления о статусе друг друга. .
3PC прошел первый этап подтверждения, даже если координатор зависает, участники знают, что находятся на этапе pre-submission, потому что они были одобрены всеми участниками на этапе подготовки.
Проще говоря, это похоже на добавление забора, чтобы сделать состояние каждого участника единым.
Резюме 2PC и 3PC
Из вышеизложенного известно, что 2PC — строго согласованный протокол синхронной блокировки, и его производительность уже относительно низкая.
Отправной точкой 3PC является устранение недостатков 2PC, но еще один этап увеличит накладные расходы на связь, и в большинстве случаев это бесполезная коммуникация.
Хотя таймаут участника введен для решения проблемы блокировки, которую зависает координатор, данные все равно будут несогласованными.
Видно, что внедрение 3PC не имеет фактического прорыва, а производительность еще хуже, поэтому фактически реализовано только 2PC.
Опять же, 2PC или 3PC — это соглашение, которое можно рассматривать как руководящую идеологию, которая все же отличается от реального десанта.
TCC
Не знаю, все ли это заметили.Как 2PC, так и 3PC полагаются на фиксацию и откат транзакций базы данных.
А иногда некоторые предприятия не только используют базу данных, это может быть отправка короткого сообщения или загрузка изображения.
Следовательно, отправку и откат транзакций необходимо продвигать на бизнес-уровень, а не на уровень базы данных.TCC — это двухэтапная фиксация на уровне бизнеса или прикладного уровня..
TCC делится на три метода, которые относятся к Try, Confirm и Cancel, т. е. три метода, которые должны быть написаны на бизнес-уровне. Они в основном используются для проблем согласованности данных бизнес-операций между базами данных и между сервисами.
TCC делится на два этапа.Первый этап-этап проверки резервирования ресурсов,а именно Try,и второй этап-отправка или откат.Если он будет отправлен, он выполнит реальную бизнес-операцию.Если он откатится, он будет выполнить зарезервированные ресурсы. Отмените, чтобы восстановить исходное состояние.
Например, если есть дебетовая служба, мне нужно написать метод Try, чтобы заморозить списанные средства, и метод Confirm, чтобы выполнить фактическое списание. Наконец, мне нужно предоставить Cancel, чтобы откатить операцию заморозки, соответствующую Все сервисы должны поддерживать эти три метода.
Видно, что метод всего один, но теперь его нужно развернуть на три метода, поэтому TCC имеет большое вмешательство в бизнес, например, если нет замороженного поля, нужно изменить структуру таблицы.
Давайте посмотрим на процесс.
Несмотря на то, что это навязчиво для бизнеса, TCC не блокирует ресурсы, и каждый метод напрямую отправляет транзакцию, в случае ошибки она компенсируется через Cancel на бизнес-уровне, поэтому его также называют компенсационным методом транзакции.
Некоторые люди здесь говорят, что если все преуспеют в Try и выполнят Confirm, но что, если индивидуальное Confirm завершится ошибкой?
В настоящее время вы можете только повторять попытку подтверждения, которая не отладилась, пока она не будет успешной. Если это действительно не работает, вы можете только записать это, а затем вмешаться вручную.
Примечания для ТСС
Эти моменты очень важны и на них необходимо обращать внимание при их реализации.
идемпотентная проблема, так как сетевой вызов не может гарантировать получение запроса, поэтому будет механизм перенастройки, поэтому три метода Try, Confirm и Cancel должны быть идемпотентными, чтобы избежать ошибок, вызванных повторным выполнением.
Проблема с пустым откатом, что означает, что метод Try не получил тайм-аут из-за проблемы с сетью.В это время менеджер транзакций выдаст команду Cancel, поэтому необходимо поддерживать Cancel для нормальной работы, когда Try не выполняется.
проблема с подвеской, эта проблема также означает, что метод Try запускает диспетчер транзакций для выполнения команды Cancel из-за тайм-аута блокировки сети.Но после выполнения команды Cancel приходит запрос Try, вы не сердитесь.
Это Cancel и у вас есть Try.Для менеджера транзакций транзакция в это время уже завершена, а операция заморозки "приостановлена", поэтому после пустого отката вы должны записать его, чтобы предотвратить вызов try снова.
вариант ТСС
Выше речь идет о ТСС общего назначения, которая должна трансформировать предыдущую реализацию, но есть ситуация, которую трансформировать нельзя, т.е.Вы звоните на интерфейс другой компании.
TCC без попытки
Например, если вам нужно совершить пересадку на самолете, а пересадка выполняется другой авиакомпанией, например, вы летите из А в Б, а затем из В в С, это имеет смысл только в том случае, если и А-В, и В-С купили билеты.
В настоящее время у вас нет выбора. Вы можете напрямую позвонить в отдел покупки билетов авиакомпании. Когда обе авиакомпании успешно купили билет, это будет прямой успех. Если компания не может купить билет, вам нужно позвонить в службу отмены. интерфейс бронирования.
То есть вся бизнес-операция выполняется непосредственно на первом этапе, поэтому сосредоточьтесь на операции отката, если откат не удался, есть напоминание и требуется ручное вмешательство.
Это собственно и есть идея TCC.
Асинхронный TCC
Является ли этот TCC все еще асинхронным? По сути, это тоже своего рода компромисс, например, некоторые сервисы сложно трансформировать, и это не повлияет на основное бизнес-решение, то есть не так уж важно и не требует своевременного внедрения. .
В настоящее время может быть введена надежная служба сообщений, и служба сообщений может использоваться для замены отдельных служб для попыток, подтверждения и отмены.
Когда Try только записывает сообщение, оно еще не может быть использовано.Confirm — это операция для фактической отправки сообщения, а Cancel — отмена отправки сообщения.
Эта надежная служба сообщений фактически аналогична транзакционному сообщению, о котором будет сказано ниже, Это решение эквивалентно комбинации транзакционных сообщений и TCC.
Сводка УТС
можно увидетьTCC реализует отправку и откат транзакций через бизнес-код, который более навязчив для бизнеса и представляет собой двухэтапную отправку на бизнес-уровне..
Его производительность выше, чем у 2PC, потому что нет блокировки ресурсов, а область применения больше, чем у 2PC.Обратите внимание на вышеуказанные моменты при реализации.
Это широко используемый метод реализации распределенных транзакций в отрасли, и из варианта также можно узнать, что он все еще должен бытьГлядя на гибкость бизнеса, это не означает, что если вы хотите использовать TCC, вы должны жестко преобразовать все службы в эти три метода.
локальная таблица сообщений
Локальное сообщение использует локальную транзакцию и будет хранить таблицу сообщений локальной транзакции в базе данных.В операции локальной транзакции добавляется вставка локального сообщения, то естьЗафиксируйте выполнение дела и операцию помещения сообщения в таблицу сообщений в одной и той же транзакции.
Таким образом, если локальная транзакция выполнена успешно, сообщение должно быть успешно вставлено, а затем вызываются другие службы.Если вызов выполнен успешно, состояние локального сообщения будет изменено.
Неважно, если не получится, будет фоновое сканирование потока, и если будут найдены сообщения этих состояний, то соответствующий сервис будет вызываться все время, и вообще будет задано количество повторных попыток.
Видно, что это по-прежнему очень просто, и это также мысль об уведомлении о максимальных усилиях.
сообщение о транзакции
На самом деле, я написал статью о сообщениях о транзакциях, в которой анализировал реализацию сообщений о транзакциях RocketMQ и Kafka на уровне исходного кода, а также разницу между ними.
Не буду здесь подробно останавливаться, потому что предыдущая статья очень подробная, около четырех-пяти тысяч слов. Прикрепляю ссылку:сообщение о транзакции
Внедрение Сеата
Прежде всего, что такое Seata, выдержка с официального сайта.
Seata — это решение для распределенных транзакций с открытым исходным кодом, предназначенное для предоставления высокопроизводительных и простых в использовании сервисов распределенных транзакций. Seata предоставит пользователям режимы транзакций AT, TCC, SAGA и XA, создав универсальное распределенное решение для пользователей.
Вы можете видеть, что предусмотрено много режимов, давайте сначала рассмотрим режим AT.
В режиме
Режим АТ - двухфазный коммит.Ранее мы упоминали о проблеме синхронной блокировки в двухфазном коммите.КПД слишком низкий.Как решает Seata?
На первой фазе АТ транзакция напрямую фиксируется и локальная блокировка снимается напрямую, так ли это коряво и прямолинейно? Конечно нет, это чем-то похоже на локальную таблицу сообщений, то есть, используя локальную транзакцию, журнал отката будет вставлен при выполнении операции реальной транзакции, а затем зафиксирован в транзакции.
Как появился этот журнал отката??
Через фреймворк, проксирующий некоторые классы JDBC, при выполнении SQL анализируйте SQL для получения образа данных перед выполнением, затем выполняйте SQL, а затем получайте образ данных после выполнения, а затем собирайте данные в журнал отката.
При фиксации этой локальной транзакции журнал отката также вставляется в таблицу UNDO_LOG базы данных (поэтому база данных должна иметь таблицу UNDO_LOG).
После этой волны операций транзакцию можно без проблем отправить в один этап.
Затем, если первый этап выполнен успешно, второй этап может асинхронно удалить эти журналы отката, а в случае сбоя первого этапа можно выполнить восстановление обратной компенсации путем отката журнала.
В это время некоторые осторожные студенты подумали, а что, если бы кто-то посередине изменил эти данные? Ваше зеркальное отражение неверно?
Так же есть понятие глобальной блокировки,Перед фиксацией транзакции необходимо получить глобальную блокировку.(это можно понимать как блокировку этих данных), и тогда локальная транзакция может быть успешно отправлена.
Если вы не можете получить его, вам нужно откатить локальную транзакцию.
Пример на официальном сайте очень хорош, сам придумывать не буду, следующая часть взята из примера на официальном сайте Seata:
В это время есть две транзакции, а именно tx1 и tx2, которые обновляют поле m таблицы a соответственно, и начальное значение m равно 1000.
tx1 запускается первым, запускает локальную транзакцию, получает локальную блокировку и обновляет операцию m = 1000 - 100 = 900. Прежде чем локальная транзакция будет зафиксирована, сначала устанавливается глобальная блокировка записи, а локальная фиксация снимает локальную блокировку.
Начните после tx2, откройте локальную транзакцию, получите локальную блокировку и обновите операцию m = 900 - 100 = 800. Прежде чем локальная транзакция будет зафиксирована, попробуйте получить глобальную блокировку записи.До глобальной фиксации tx1 глобальная блокировка записи удерживается tx1, и tx2 должен повторить попытку, чтобы дождаться глобальной блокировки.
Видно, что модификация tx2 заблокирована, и после повторной попытки получить глобальную блокировку он может зафиксировать и снять локальную блокировку.
Если двухэтапный глобальный откат tx1, tx1 необходимо повторно получить локальную блокировку данных, выполнить операцию обновления обратной компенсации и реализовать откат ветви.
В этот момент, если tx2 все еще ожидает глобальной блокировки данных, удерживая при этом локальную блокировку, откат ветвления tx1 завершится ошибкой. Откат ветки будет продолжаться до тех пор, пока глобальная блокировка tx2 и другие блокировки не истечет, отмените глобальную блокировку и откатите локальную транзакцию, чтобы снять локальную блокировку, и откат ветки tx1, наконец, будет успешным.
Поскольку глобальная блокировка всего процесса удерживается tx1 до конца tx1, проблема грязной записи не возникает..
потомГлобальным значением по умолчанию в режиме AT является уровень изоляции незафиксированного чтения., если приложение находится в определенном сценарии, необходимо потребовать, чтобы глобальное чтение было зафиксировано, что может быть передано через прокси оператора SELECT FOR UPDATE.
Конечно, предпосылка заключается в том, что ваш локальный уровень изоляции транзакций зафиксирован на чтении и выше.
Резюме режима AT
Видно, что передний и задний образы данных получаются без вторжения через прокси, а лог отката собирается и подается вместе с локальной транзакцией, что решает проблему блокировки двухфазной синхронизации.
И используйте глобальные блокировки для достижения изоляции записи.
Ради общей производительности по умолчанию используется уровень изоляции чтения незафиксированных, и только SELECT FOR UPDATE проксируется для выполнения зафиксированной изоляции чтения.
На самом деле это вариант реализации двухфазного коммита..
режим ТСС
Ничего особенного, то есть нам нужно сделать три метода в анализе выше,Затем включите пользовательскую транзакцию ветки в управление глобальной транзакцией.
Я разместил изображение на официальном сайте должно быть очень ясно.
Режим саги
Эта Saga представляет собой решение для длинных транзакций, предоставляемое Seata. Оно подходит для случаев, когда существует много и длинных бизнес-процессов. В этом случае, если вы хотите реализовать общий TCC или что-то в этом роде, вам может потребоваться вложить несколько транзакций.
И некоторые системы не могут предоставить эти три интерфейса TCC, например, старые проекты или системы других компаний, поэтому устанавливается режим Saga, который был предложен в статье, опубликованной Hector & Kenneth в 1987 году.
Так как же Сага это делает? Взгляните на эту картинку.
Предполагая, что операций N, транзакция фиксации выполняется непосредственно из T1, а затем выполняется T2.Видно, что это прямая фиксация без блокировок.Когда T3 обнаруживает, что выполнение не выполняется, он входит в стадию Compenstaing и начинает перематывать компенсацию по одному. .
Идея состоит в том, чтобы сделать это с покрытой головой в начале, не будьте трусом, если есть проблема, давайте изменим ее обратно одну за другой.
Видно, что эта ситуация не гарантирует изоляцию транзакций, и у Saga также есть те же точки внимания, что и у TCC, которые требуют нулевой компенсации, анти-приостановки и идемпотентности.
А в крайних случаях данные нельзя откатить, потому что данные были изменены. Например, на первом шаге вы назвали мне 20 000 юаней, а я их достал и потратил.В это время вы их откатываете. Баланс на моем счету уже 0. Как вы думаете? Могу ли я все еще получить отрицательный результат?
Такая ситуация может быть запущена только из бизнес-процесса, на самом деле я всегда писал такой код, возьмем для примера сцену покупки скинов.Я всегда вычитаю деньги перед тем, как отдать скин.
Если предположить, что первый вычет за шкуру провалится, не будет ли это напрасным? Вы собираетесь компенсировать деньги? Как вы думаете, пользователи вернутся и скажут, что скин оплачен, но не вычтен?
Может найдется умненький призрак, который сказал, что я поменяю скин обратно в то время, хе-хе, такое действительно было, тск тск, действительно жалко, когда тебя ругают.
такПравильный процесс должен заключаться в том, чтобы сначала вычесть деньги, а затем отдать скин,деньги кладутся сначала себе в карман,если скин не давать успешным пользователям,то он естественно перейдет,а потом ему отдать,хотя может вы и написали баг,но к счастью это не бесплатный баг .
Так что на этот момент стоит обратить внимание при кодировании.
Наконец
Видно, что с распределенными транзакциями все еще существуют различные проблемы, и реализация общих распределенных транзакций может обеспечить только окончательную согласованность.
В крайних случаях по-прежнему требуется ручное вмешательство, поэтому очень важно хорошее ведение журнала.
Есть еще бизнес-процесс кодинга, он должен быть написан в том направлении, которое выгодно компании, например, сначала получить деньги пользователя, а потом дать пользователю что-то, помните.
Подумайте об этом, прежде чем переходить к распределенным транзакциям, так ли это необходимо, можете ли вы преобразовать его, чтобы избежать распределенных транзакций?
Чтобы быть более экстремальным, необходимо ли вашему бизнесу иметь дела?
В конце концов, личные способности ограничены,Если есть какие-либо ошибки, пожалуйста, свяжитесь со мной немедленно, Если вы считаете, что статья хорошая, нажмите на нее, чтобы поддержать ее.
плечи гигантов
Распределенные протоколы и алгоритмы на практике, Хань Цзянь
Распределенная база данных 30 лекций, Ван Лэй
seata.io
Я да, от мала до миллиарда, увидимся в следующей статье.
🏆 Технический спецвыпуск 5 | Рассказываем о распределенных вещах...