Учебная комната Cabbage Java охватывает основные знания
1. Протокол распределенных транзакций
Существуют соответствующие спецификации и протоколы для решения распределенных транзакций. Протоколы, связанные с распределенными транзакциями,2PC,3PC.
1.1 (2PC) Двухфазный протокол фиксации
Двухфазная фиксация (Two-phase Commit, 2PC), за счет введения координатора (Coordinator) для координации поведения участников и, в конечном счете, принятия решения о том, хотят ли эти участники фактически выполнить транзакцию.
1.1.1. Этап подготовки
Координатор спрашивает участника, успешно ли была выполнена транзакция, и участник отправляет обратно результат выполнения транзакции.
1.1.2. Фаза фиксации
Если транзакция выполнена успешно на каждом участнике, координатор транзакции отправляет уведомление участнику о совершении транзакции; в противном случае координатор отправляет уведомление участнику об откате транзакции. Важно отметить, что на этапе подготовки участник выполняет транзакцию, но еще не зафиксировал ее. Фиксация или откат происходит только после получения уведомления от координатора на этапе фиксации.
1.1.3. Проблемы
- Синхронная блокировка: все участники транзакции находятся в состоянии синхронной блокировки, ожидая ответов от других участников, и не могут выполнять другие операции.
- Единственная проблема: координатор играет очень большую роль в 2PC, и неудача будет иметь большое значение. В частности, когда на этапе 2 происходит сбой, все участники будут находиться в состоянии ожидания и не смогут выполнять другие операции.
- Несогласованность данных: на этапе 2, если координатор отправляет только часть сообщения о фиксации, а сеть работает ненормально, то только некоторые участники получают сообщение о фиксации, то есть только некоторые участники отправляют транзакцию, что делает системные данные несогласованными.
- Слишком консервативно: сбой любого узла приведет к сбою всей транзакции, а идеального механизма отказоустойчивости не существует.
1.2. (3PC) Трехфазный протокол фиксации
Трехфазная фиксация (2PC), в отличие от двухфазной фиксации, имеет две точки изменения.
- Внедрить механизм тайм-аута. При этом как у координатора, так и у участников вводится механизм тайм-аута.
- Вставьте этап подготовки между первым и вторым этапом. Гарантируется, что состояние каждого участвующего узла непротиворечиво перед финальной фазой фиксации.
1.2.1 Стадия CanCommit
Фаза CanCommit в 3PC на самом деле очень похожа на фазу подготовки в 2PC. Координатор отправляет участнику запрос на фиксацию, и участник возвращает ответ «Да», если участник может отправить, в противном случае возвращает ответ «Нет».
- Запрос транзакции Координатор отправляет участнику запрос CanCommit. Спросите, можно ли выполнить операцию фиксации транзакции. Затем начните ждать ответа участника.
- Ответная обратная связь После того, как участник получит запрос CanCommit, при нормальных обстоятельствах, если он считает, что транзакция может быть успешно выполнена, он вернет ответ Да и перейдет в состояние готовности. В противном случае отзыв No.
1.2.2 Этап PreCommit
Координатор решает, продолжать ли операцию PreCommit транзакции в соответствии с реакцией участников. В зависимости от ответа возможны следующие две возможности. Если координатор получает ответ Да от всех участников, то выполняется предварительное выполнение транзакции.
- Отправка запроса PreCommit Координатор отправляет участнику запрос PreCommit и переходит в фазу «Подготовлено».
- Предварительная фиксация транзакции После того, как участник получит запрос PreCommit, он выполнит операцию транзакции и запишет информацию об отмене и повторении в журнале транзакций.
- Обратная связь ответа Если участник успешно выполняет транзакционную операцию, он возвращает ответ ACK и начинает ждать финальной команды.
Если какой-либо участник отправляет координатору ответ No или после ожидания таймаута координатор не получает ответа от участника, то транзакция прерывается.
- Отправить запрос на прерывание Координатор отправляет всем участникам запрос на прерывание.
- Прерывание транзакции После того, как участник получит от координатора запрос на прерывание (или по истечении тайм-аута запрос от координатора не поступил), выполнение транзакции прерывается.
1.2.3 Стадия DoCommit
На этом этапе выполняется отправка реальной транзакции, которую также можно разделить на следующие две ситуации.
выполнить фиксацию
- Отправить запрос на фиксацию: координатор получает ответ ACK, отправленный участником, после чего он переходит в состояние фиксации из состояния предварительной фиксации. и отправить запрос на выполнение всем участникам.
- Фиксация транзакции: после того, как участник получает запрос на выполнение транзакции, выполняется формальная фиксация транзакции. И освободите все ресурсы транзакции после завершения транзакции.
- Ответная обратная связь: после фиксации транзакции отправьте ответ Ack координатору.
- Завершить транзакцию: координатор завершает транзакцию после получения ответов подтверждения от всех участников.
прервать транзакцию
Если координатор не получает ответ ACK, отправленный участником (может случиться так, что получатель не отправляет ответ ACK, или время ответа истекло), будет выполнена транзакция прерывания.
- Отправить запрос на прерывание: координатор отправляет всем участникам запрос на прерывание.
- Откат транзакции: после того, как участник получает запрос на отмену, он использует информацию об отмене, записанную на этапе 2, для выполнения операции отката транзакции и освобождает все ресурсы транзакции после завершения отката.
- Результат обратной связи: после того, как участник завершает откат транзакции, он отправляет сообщение ACK координатору.
- Прерывание транзакции: после того, как координатор получит сообщение ACK, возвращенное участником, транзакция прерывается.
2. В режиме
Режим AT — это ненавязчивое решение для распределенных транзакций.
Али Сеата Фреймворк, который реализует шаблон. В режиме AT пользователям нужно обращать внимание только на свой «бизнес-SQL». «Бизнес-SQL» пользователя используется в качестве первого этапа, а платформа Seata автоматически генерирует операции фиксации и отката транзакции второго этапа.
Как режим АТ обеспечивает невмешательство в бизнес:
2.1 Этап первый
На первом этапе Seata перехватит «бизнес-SQL», сначала проанализирует семантику SQL, найдет бизнес-данные для обновления с помощью «бизнес-SQL», сохранит их как «предыдущий образ» до того, как бизнес-данные будут обновлены, а затем выполнит « бизнес-SQL» Обновите бизнес-данные. После обновления бизнес-данных сохраните их как «после изображения» и, наконец, создайте блокировку строки. Все вышеперечисленные операции выполняются в рамках транзакции базы данных, что обеспечивает атомарность одноэтапных операций.
2.2. Двухэтапная фиксация
Если отправлен второй этап, поскольку «бизнес-SQL» был отправлен в базу данных на первом этапе, платформе Seata нужно только удалить данные моментального снимка и блокировки строк, сохраненные на первом этапе, чтобы завершить очистку данных.
2.3. Двухэтапный откат
Если второй этап представляет собой откат, Seata необходимо выполнить откат «бизнес-SQL», который был выполнен на первом этапе, чтобы восстановить бизнес-данные. Способ отката состоит в том, чтобы использовать «образ до» для восстановления бизнес-данных, однако перед восстановлением необходимо сначала проверить наличие грязных записей. Сравните «текущие бизнес-данные базы данных» и «образ после». Если эти два данных точно то же самое, это означает, что нет грязной записи. , вы можете восстановить бизнес-данные. Если они несовместимы, это означает, что есть грязная запись. Если грязная запись происходит, требуется ручная обработка.
Первая фаза, вторая фаза фиксации и откат режима AT автоматически генерируются платформой Seata. Пользователям нужно только написать «бизнес-SQL», чтобы легко получить доступ к распределенным транзакциям. Режим AT — это распределенная транзакция без какого-либо вмешательства в бизнес. Бизнес решения.
3. Режим ТСС
Режим TCC требует, чтобы пользователи реализовали три операции Try, Confirm и Cancel в соответствии со своими бизнес-сценариями; инициатор транзакции выполняет метод Try на одном этапе, отправляет и выполняет метод Confirm на втором этапе и выполняет метод Cancel. на втором этапе отката.
Описаны три метода ТСС:
Try: обнаружение и резервирование ресурсов;
Confirm: бизнес-операция, которую нужно выполнить, отправлена, требуется, чтобы попытка прошла успешно, а подтверждение должно быть успешным;
Cancel: Освобождение зарезервированных ресурсов;
3.1 Бизнес-модель
Когда пользователи получают доступ к TCC, самое важное — подумать о том, как разделить свою бизнес-модель на два этапа для реализации.
Взяв в качестве примера сценарий «вычета», перед доступом к TCC вычитание учетной записи A может быть завершено только одним SQL для обновления баланса учетной записи; но после доступа к TCC пользователю необходимо подумать, как преобразовать исходный. step Операция вывода, которую можно выполнить, разделена на два этапа и реализована тремя методами, и если первый этап Try выполнен успешно, второй этап Confirm будет успешным.
Как показано на рисунке выше, метод Try как одноэтапный метод подготовки требует проверки и резервирования ресурсов. В сценарии вычета Try должен проверить, достаточно ли остатка на счете, и зарезервировать средства для перевода.Способ резервирования — заморозить перевод средств на счете A. После выполнения метода Try, хотя баланс счета A по-прежнему составляет 100, 30 юаней из которых были заморожены и не могут быть использованы для других транзакций.
Двухфазный метод Confirm выполняет фактическую операцию вывода. Confirm будет использовать средства, замороженные на этапе «Попытка», для списания средств со счета. После выполнения метода Confirm 30 юаней, которые были заморожены на первом этапе счета A, были вычтены, и баланс счета A стал 70 юаней.
Если второй этап является откатом, необходимо освободить 30 юаней, замороженных на первом этапе Try в методе Cancel, чтобы аккаунт A вернулся в исходное состояние, и все 100 юаней были доступны.
Когда пользователь получает доступ к режиму TCC, самое главное — подумать, как разделить бизнес-модель на 2 этапа, внедрить 3 метода TCC и убедиться, что попытка будет успешной, а подтверждение будет успешным. По сравнению с режимом AT, режим TCC имеет определенное вмешательство в бизнес-код, но режим TCC не имеет глобальной блокировки строк режима AT, и производительность режима TCC будет намного выше, чем у режима AT. режим.
3.2 Разрешить пустой откат
Интерфейс Cancel предназначен для пустых откатов. Когда интерфейс Try не получен из-за потери пакета, диспетчер транзакций запускает откат. В это время будет запущен интерфейс Cancel. В это время, когда Cancel выполняется и обнаруживает, что нет соответствующего xid транзакции или первичного ключа , он должен вернуть успешный откат. Пусть менеджер службы транзакций считает, что был выполнен откат, иначе он продолжит повторять попытки, а у Cancel нет соответствующих бизнес-данных для отката.
3.3. Защита от зависания
Подвесные средства: Отмена выполнена перед интерфейсом Thry. Причина в том, что попробуйте время из-за заброшенных сетевых заложений. Диспетчер транзакций генерирует откат, запускает интерфейс отмены, и, наконец, получает вызов интерфейса TRY, но отменить, прежде чем попробовать. Согласно предыдущей логике разрешения пустого отката, откат вернет успех, и менеджер транзакций считает, что транзакция была успешно откатана назад, то интерфейс TRY не должен выполняться в это время, иначе мы произойдут несоответствие, поэтому мы произойдут Возврат Успех в Отмена Пустой откат Количество транзакций XID или первичный ключ CHID или Business записывается ранее, указывая, что запись была возвращена назад. Интерфейс Thry Share сначала проверяет транзакцию XID или основной ключ бизнеса. Если он был помечен как успешно откатывается, Попробуйте деловая работа не будет выполнена.
3.4 Идемпотентное управление
Идемпотентность означает, что для одной и той же системы при одних и тех же условиях один и несколько повторяющихся запросов оказывают одинаковое влияние на системные ресурсы. Поскольку джиттер или перегрузка сети могут истечь, диспетчер транзакций повторно попытается использовать ресурс, поэтому вполне вероятно, что бизнес-операция будет вызываться повторно.Чтобы не занимать ресурсы много раз из-за повторных вызовов, при проектировании необходимо использовать идемпотент. Управление, обычно мы можем использовать транзакцию xid или решение первичного ключа для управления.
4. Режим саги
Теория саги основана на статье Гектора и Кеннета «Саги» в 1987 году.
Реализация шаблона саги — решение для длительных транзакций. Saga — это компенсационный протокол.В режиме Saga в распределенной транзакции участвует несколько участников, и каждый участник представляет собой услугу положительной компенсации, которая требует, чтобы пользователи реализовывали свои прямые операции и операции обратного отката в соответствии с бизнес-сценариями.
При выполнении распределенной транзакции форвардные операции каждого участника выполняются по очереди, и если все форвардные операции выполнены успешно, то распределенная транзакция фиксируется. Если какая-либо прямая операция завершается сбоем, распределенная транзакция выполняет откат для выполнения операции обратного отката предыдущих участников, откатывает зафиксированных участников и возвращает распределенную транзакцию в исходное состояние.
Служба переадресации Saga и служба компенсации также должны быть реализованы разработчиками бизнеса. Так что это вторжение в бизнес.
Распределенные транзакции в режиме Saga обычно управляются событиями, и каждый участник выполняется асинхронно.Режим Saga — это решение для длинных транзакций.
4.1. Сценарии использования
Режим Saga подходит для бизнес-систем с длительными бизнес-процессами, где необходимо гарантировать возможную согласованность транзакций.Режим Saga отправляет локальные транзакции в один этап и может гарантировать производительность без блокировок и длительных процессов.
Участниками транзакции могут быть сервисы других компаний или унаследованные системы, которые нельзя трансформировать и предоставить интерфейс, требуемый TCC, и можно использовать паттерн Saga.
Преимущество:
- Фиксация транзакций локальной базы данных в один этап, без блокировок и с высокой производительностью;
- Участники могут использовать управляемое транзакциями асинхронное выполнение с высокой пропускной способностью;
- Компенсационная услуга — это «обратная сторона» форвардной услуги, которую легко понять и легко реализовать;
недостаток: В режиме Saga, поскольку транзакция локальной базы данных была зафиксирована в одной фазе и не было выполнено действие «резервирования», изоляция не может быть гарантирована. В продолжении будет рассказано о реакции на отсутствие изоляции.
Аналогично практическому опыту TCC, в режиме Saga обратные и обратные операции каждого участника транзакции должны поддерживать:
4.2 Разрешить нулевую компенсацию
Разрешить пустую компенсацию: исходная услуга не выполняется, выполняется компенсационная услуга;
4.3. Защита от зависания
Управление анти-приостановкой: услуга компенсации выполняется до исходной услуги, а прямая операция отклоняется после того, как компенсация пуста;
4.4 Идемпотентное управление
Идемпотентное управление: исходный сервис и компенсационный сервис обеспечивают идемпотентность;
4.5. Стратегия восстановления пользовательской транзакции
Пользовательская стратегия восстановления транзакций:
Как упоминалось ранее, режим Saga не гарантирует изоляцию транзакций, и в крайних случаях может происходить грязная запись. Например, когда распределенная транзакция не зафиксирована, данные предыдущего сервиса изменены, а последующий сервис имеет исключение и его нужно откатить, может случиться так, что операция компенсации не может быть выполнена после данных предыдущего сервиса. служба изменена. Решение в это время может состоять в том, чтобы «повторить попытку», чтобы продолжить выполнение распределенной транзакции. Поскольку весь бизнес-процесс управляется конечным автоматом, он может продолжать повторять попытки даже после восстановления. Таким образом, пользователь может настроить стратегию обработки транзакций процесса в соответствии с бизнес-характеристиками, чтобы отдать приоритет «откату» или «повторной попытке».По истечении времени ожидания транзакции сервер продолжит повторную попытку в соответствии с этой стратегией.
Поскольку Saga не гарантирует изоляцию, нам необходимо реализовать принцип «предпочитаю долгосрочный, а не краткосрочный» при разработке нашего бизнеса.Долгосрочный относится к ситуации, когда с нашей стороны больше денег, когда что-то идет не так, Если денег меньше, это короткий платеж, потому что, если длинный платеж может быть возвращен клиенту, но короткий платеж может не вернуть деньги, то есть, когда бизнес разработан, клиент счет должен быть сначала вычтен, а затем зачислен.Проблемы с изоляцией вызывают обновления покрытия, и не будет недостатка в деньгах.
5. Режим ХА
XA — это двухэтапный протокол фиксации, определенный группой X/Open DTP. XA изначально поддерживается многими базами данных (такими как Oracle, DB2, SQL Server, MySQL) и инструментами, такими как промежуточное ПО (такими как CICS и Tuxedo).
Модель X/Open DTP (1994 г.) включает приложение (AP), диспетчер транзакций (TM) и диспетчер ресурсов (RM). Функции интерфейса XA предоставляются поставщиками баз данных. В основе спецификации XA лежит протокол двухфазной фиксации 2PC. JTA (Java Transaction API) — это расширенный интерфейс спецификации XA, реализованный Java.
В режиме XA должен быть [глобальный] координатор.После завершения каждой транзакции базы данных выполняется первый этап предварительной фиксации, координатор уведомляется и результат передается координатору. После того, как координатор и другие операции транзакций ветвей завершены и все предварительно зафиксированы, выполняется второй шаг; второй шаг: координатор уведомляет каждую базу данных о фиксации/откате одну за другой. Среди них глобальный координатор — это роль TM в модели XA, а соответствующая база данных каждой транзакции филиала — это RM.
Фреймворк с открытым исходным кодом в режиме XA — это атомикос, и его компания-разработчик также имеет коммерческую версию.
Недостатки режима XA: степень детализации транзакций велика. При высокой степени параллелизма доступность системы низкая. Поэтому используется редко.
6. (AT, TCC, Saga, XA) сравнение режимов
В разное время были предложены четыре режима распределенных транзакций, и каждый режим имеет свои применимые сценарии:
- В режимеЭто неинтрузивное решение для распределенных транзакций, подходящее для сценариев, в которых не требуется трансформация бизнеса, с практически нулевыми затратами на обучение.
- режим ТССЭто высокопроизводительное решение для распределенных транзакций, подходящее для сценариев с высокими требованиями к производительности, таких как базовые системы.
- Режим сагиЭто решение для длинных транзакций, подходящее для бизнес-систем с длинными бизнес-процессами и необходимостью обеспечения возможной согласованности транзакций.Режим Saga будет отправлять локальные транзакции на одном этапе, без блокировок, а производительность может быть гарантирована в случае длинных процессов. , Он в основном используется на уровне канала и бизнес-системе на уровне интеграции. Участниками транзакции могут быть сервисы других компаний или унаследованные системы, которые не могут быть трансформированы и предоставляют требуемый TCC интерфейс, а также могут использовать паттерн Saga.
- XA-режимРаспределенное решение строгой согласованности, но с низкой производительностью и менее используемое.