Back-end программисты должны: основы распределенных транзакций

задняя часть MySQL

предисловие

Недавно я прочитал несколько сообщений в блоге о распределенных транзакциях и сделал заметки. ха-ха~

гитхаб-адрес

GitHub.com/Я бы хотел 123/Java…

транзакция базы данных

транзакция базы данных (Аббревиатура: бизнес), является логической единицей в исполнении системы управления базой данных и состоит из ограниченной последовательности операций с базой данных.Либо делай все, либо не делай всеОК, этонеделимыйрабочая единица.

Несколько типичных характеристик транзакций базы данных: атомарность, непротиворечивость, изоляция и долговечность, или сокращенно ACID.

  • Атомарность:Транзакция выполняется как единое целое, и либо все операции над базой данных, содержащиеся в ней, либо ни одна из них не выполняется.
  • последовательность:Это означает, что данные не будут уничтожены до начала транзакции и после ее завершения.Если счет А переводит 10 юаней на счет Б, общая сумма А и Б останется неизменной независимо от того, успешна она или нет.
  • Изоляция:Когда несколько транзакций доступ одновременно, транзакции изолированы друг от друга, то есть одна транзакция не влияет на беговое влияние других транзакций. Короче говоря, это означает, что не существует речной воды между делами.
  • Упорство:Указывает, что после завершения транзакции операционные изменения, внесенные транзакцией в базу данных, будут сохранены в базе данных.

Как работают транзакции

местные дела

Транзакции в традиционной односерверной однореляционной базе данных являются локальными транзакциями. Локальная транзакция управляется диспетчером ресурсов, а транзакция JDBC является очень типичной локальной транзакцией.

Журнал транзакций

Журнал транзакций innodb включает журнал повторов и журнал отмен.

журнал повторов (журнал повторов)

Журнал повторов обычно представляет собой физический журнал, в котором фиксируется физическое изменение страницы данных, а не изменение определенной строки или строк.Он используется для восстановления зафиксированной физической страницы данных.

журнал отмены

Журнал отмен — это логический журнал, который отличается от журнала повторов, в который записывается физический журнал. Можно считать, что при удалении записи в журнал отмен будет записана соответствующая запись вставки, а при обновлении записи будет записана соответствующая противоположная запись обновления.

Реализация идеи характеристики транзакции ACID

  • Атомарность: реализуется с помощью журнала отмены.Если во время выполнения транзакции возникает ошибка или пользователь выполняет откат, система возвращает статус транзакции в начале транзакции через журнал журнала отмены.
  • Постоянство: используйте журнал повторов для достижения, пока журнал журнала повторов является постоянным, когда система дает сбой, данные могут быть восстановлены через журнал повторов.
  • Изоляция: транзакции изолированы друг от друга с помощью блокировок и MVCC.
  • Согласованность. Согласованность достигается за счет отката, восстановления и изоляции в случае параллелизма.

Распределенная транзакция

Распределенные транзакции:Это означает, что участники транзакций, серверы поддержки транзакций, серверы ресурсов и менеджеры транзакций находятся на разных узлах разных распределенных систем. Проще говоря, распределенные транзакции относятся к транзакциям в распределенных системах, которые существуют для обеспечения согласованности данных между различными узлами базы данных.

Зачем нужны распределенные транзакции? Объясняются следующие два аспекта:

Распределенные транзакции в микросервисной архитектуре

С быстрым развитием Интернета, легкого и четкого функционального разделения Micro-Service Soaded этап истории. Например, следующие заказы клиентов покупают подарки Live Service, разделены на три сервиса, а именно сервисы Gold Coniens (Coinservice), сервис заказа (undervice), подарочная служба (Giftservice). Эти услуги развернуты в (узлам) на разных машинах, соответствующая база данных (базы данных монет, база данных заказов, подарочные базы данных) - это разные узлы.

Когда пользователь размещает заказ на покупку подарка, база данных подарков, база данных золотых монет и база данных заказов находятся на разных узлах, и невозможно использовать локальные транзакции.Так как же обеспечить согласованность данных в разных базах данных (узлах)? Это требует распределенных транзакций ~

Распределенные транзакции в подбазе данных и подтаблице

С развитием бизнеса данные базы данных становятся все больше и больше, а количество данных превышает десятки миллионов.Нам нужна подбаза данных и подтаблица (компания использовала mycat для подбазы данных и подтаблицы, а позже использовал sharding-jdbc). Для одной базы данных данные распределены по разным узлам.Например, некоторые находятся в компьютерном зале Шэньчжэня, а некоторые в компьютерном зале Пекина.Если вы хотите использовать локальные транзакции для обеспечения, вам все равно.Вам все равно нужны распределенные транзакции.

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

Теория CAP и теория BASE

Конечно, чтобы изучить распределенные транзакции, вам нужно понимать теорию CAP и теорию BASE.

теория CAP

Как основная теория распределенных систем, теория CAP относится к тому факту, что в распределенной системе непротиворечивость, доступность и устойчивость к разделам могут достигать не более двух точек одновременно.

Консистенция (C: Консистенция):

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

Доступность (A: Доступность):

Доступность означает, что услуги, предоставляемые системой, всегда должны быть доступны, а результаты всегда могут быть возвращены в течение ограниченного времени для каждого запроса операции пользователя. Дело здесь в «за ограниченное время» и «возвращении результата».

Допуск на перегородку (P: Допуск на перегородку):

Когда распределенная система сталкивается с каким-либо сбоем сетевого раздела, она все равно должна иметь возможность предоставлять внешние службы, отвечающие требованиям согласованности и доступности.

выберите инструкция
CA Отказ от отказоустойчивости разделов и повышение согласованности и доступности на самом деле является выбором традиционных автономных баз данных.
AP Отказ от согласованности, устойчивости к разделам и доступности, которые являются выбором во многих проектах распределенных систем.
CP Откажитесь от доступности, стремитесь к согласованности и отказоустойчивости разделов, сетевые проблемы напрямую сделают всю систему недоступной.

БАЗОВАЯ теория

Теория BASE является расширением AP в CAP.Для нашей бизнес-системы мы рассматриваем возможность пожертвовать согласованностью в обмен на доступность системы и отказоустойчивость разделов. BASE — это аббревиатура от фраз «Базово доступный», «Мягкое состояние» и «В конце концов непротиворечивый».

Basically Available

Базовая доступность: достигается за счет поддержки локальных сбоев, а не общесистемных сбоев. Если пользователи разделены на 5 серверов баз данных, сбой одной пользовательской базы данных затронет только 20% пользователей этого конкретного хоста, а других пользователей это не затронет.

Soft State

Мягкое состояние, состояние может не синхронизироваться в течение определенного периода времени

Eventually Consistent

В конце концов согласуются, окончательные данные согласуются, не всегда сильная согласованность.

Несколько решений для распределенных транзакций

Решения для распределенных транзакций в основном включают следующее:

  • Схема 2PC (двухэтапная подача)
  • TCC (попробовать, подтвердить, отменить)
  • локальная таблица сообщений
  • уведомление о лучших усилиях
  • Сага дела

Двухэтапный план подачи

Схема двухэтапной фиксации является широко используемым решением для распределенных транзакций. Фиксация транзакции делится на две фазы: фаза подготовки и план выполнения фиксации.

Успех представления на втором этапе

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

этап выполнения фиксации, если менеджер транзакций получает сообщение об успешном завершении, на которое отвечают все менеджеры ресурсов, он отправляет сообщение фиксации каждому менеджеру ресурсов, а RM выполняет фиксацию в соответствии с инструкциями TM. Как показано на рисунке:

Случаи, когда двухэтапная фиксация терпит неудачу

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

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

Плюсы и минусы двухэтапной фиксации

Схема 2ПК проста в реализации и имеет невысокую стоимость, но в основном имеет следующиенедостаток:

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

TCC (компенсационный механизм)

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

Модель TCC (попробовать-подтвердить-отменить)

TCC (Try-Confirm-Cancel) реализует распределенные транзакции путем декомпозиции бизнес-логики. Для конкретной бизнес-службы модель распределенных транзакций TCC требует, чтобы бизнес-система реализовывала следующие три логические схемы:

пробная фаза: попытаться выполнить, завершить проверку согласованности всех служб и зарезервировать необходимые ресурсы службы.

Подтвердить этап: на этом этапе бизнес подтверждается и отправляется без какой-либо проверки, потому что этап попытки был проверен, и этап подтверждения по умолчанию не пойдет не так.

Отменить этап: если бизнес-выполнение завершается сбоем, перейдите на этот этап, он освободит все бизнес-ресурсы, занятые на этапе попытки, и отменит все операции, выполненные на этапе подтверждения.

Модель распределенных транзакций TCC состоит из трех частей:Master Business Service, Slave Business Service, Менеджер по деловой активности.

  • Основная бизнес-служба: Основная бизнес-служба отвечает за инициирование и завершение всей деловой активности.
  • Подчиненная бизнес-служба. Подчиненная бизнес-служба является участником всей бизнес-деятельности и реализует операции «Попробовать», «Подтвердить» и «Отмена» для вызова основной бизнес-службы.
  • Диспетчер деловой активности: Менеджер деловой активности управляет и контролирует всю коммерческую деятельность, включая запись состояния транзакции, вызов операции подтверждения из бизнес-службы, вызов операции отмены из бизнес-службы и т. д.

Давайте возьмем пользователя, размещающего заказ на покупку подарков, в качестве примера для имитации процесса TCC, реализующего распределенные транзакции:

Предположим, у пользователя А на балансе 100 золотых монет и 5 подарков. A тратит 10 золотых монет, размещает заказ и покупает 10 роз. Остатки, заказы, подарки находятся в разных базах данных.

Попробуйте этап TCC:

  • Создается запись заказа, и статус заказа должен быть подтвержден.
  • Обновите баланс золотых монет в учетной записи пользователя А до 90 и замороженных золотых монет до 10 (зарезервированные бизнес-ресурсы).
  • Установите количество подарков пользователя на 5 и количество до увеличения на 10.
  • После того, как попытка будет успешной, она войдет в стадию подтверждения.
  • Если в процессе Try произойдет какая-либо аномалия, он перейдет в стадию Cancel.

Подтвердить этап TCC:

  • Статус заказа изменен на Оплачен
  • Обновить баланс пользователя до 90, можно заморозить до 0
  • Счетчик подарков пользователей обновлен до 15, предварительно увеличен до 0
  • Если в процессе подтверждения возникает какая-либо аномалия, он переходит в стадию отмены.
  • Процесс Confirm выполняется успешно, после чего транзакция завершается.

Отменить этап TCC:

  • Изменить статус заказа на отмененный
  • Обновить баланс пользователя до 100
  • Обновите количество подарков пользователя до 5

Преимущества и недостатки ТК

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

  • Приложение очень навязчиво, и три этапа попытки, подтверждения и отмены требуют реализации бизнес-логики.
  • Различные стратегии отката должны быть реализованы в соответствии с различными причинами сбоя, такими как сбои сети и системы, которые трудно реализовать.Как правило, используются платформы с открытым исходным кодом TCC, ByteTCC, TCC-транзакция и Himly.

локальная таблица сообщений

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

Основные идеи реализации

отправитель:

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

Потребитель сообщения:

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

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

преимущество недостаток:

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

уведомление о лучших усилиях

Какое максимальное уведомление

Уведомление о лучших усилиях также является решением для распределенных транзакций. Ниже приведен пример корпоративного онлайн-банкинга.

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

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

Лучшие решения для уведомлений об усилиях

Чтобы добиться уведомления с максимальной эффективностью, можно использовать механизм подтверждения MQ.

план

  • 1. Инициатор отправляет уведомление в MQ.
  • 2. Получатель уведомления прослушивает сообщение MQ.
  • 3. После получения уведомления, сообщение получено, дело обработано, ответ ack.
  • 4. Если сторона уведомления не отвечает на ACK, MQ будет неоднократно уведомлен на 1 мин, 5 мин и 10 мин.
  • 5. Получатель уведомления может использовать интерфейс проверки сообщения, чтобы обеспечить согласованность сообщения.

Схема реализации трансферного бизнеса:

Процесс взаимодействия выглядит следующим образом:

  • 1. Пользователь запрашивает систему перевода для перевода денег.
  • 2. Система передачи завершает передачу и отправляет результат передачи в MQ.
  • 3. Корпоративный интернет-банк отслеживает MQ и получает уведомление о результате перевода, если сообщение не может быть получено, MQ повторно отправляет уведомление. После получения результата перевода обновите статус перевода.
  • 4. Корпоративная система онлайн-банкинга также может активно запрашивать интерфейс запроса результатов перевода системы переводов, чтобы обновить статус перевода.

Сага дела

Транзакция Saga была предложена Гектором Гарсиа-Молиной и Кеннетом Салемом из Принстонского университета. Основная идея состоит в том, чтобы разделить длинную транзакцию на несколько локальных коротких транзакций, которые координируются координатором транзакции Saga. Если она завершится нормально, она будет завершена. нормально.Если какой-то шаг On не пройден, компенсационные операции вызываются по одной в обратном порядке.

Введение в сагу

  • Saga = Long Live Transaction (LLT, долгоживущая транзакция)
  • LLT = T1 + T2 + T3 + ... + Ti (Ti — локальная короткая сделка)
  • Каждая локальная транзакция Ti имеет соответствующую компенсацию CI

Порядок исполнения саги

  • Нормальный: T1 T2 T3 ... Tn
  • Исключение: T1 T2 T3 C3 C2 C1

Сага о двух стратегиях восстановления

  • Восстановление в обратном порядке, компенсируя завершенные транзакции в случае сбоя какой-либо локальной подтранзакции. Например, последовательность выполнения ненормальных условий T1 T2 Ti Ci C2 C1.
  • Восстановление в прямом направлении, то есть повторная попытка неудачной транзакции, при условии, что каждая подтранзакция в конце будет успешной. Порядок выполнения: T1, T2, ..., Tj (сбой), Tj (повторная попытка), ..., Tn.

Например, предположим, что пользователь размещает заказ и тратит 10 юаней на покупку более 10 роз, тогда есть

T1=разместить заказ, T2=вычесть 10 юаней с пользователя, T3=добавить пользователю 10 роз, T4=вычесть 10 роз со склада

C1=Отменить заказ, C2=Добавить пользователю 10 юаней, C3=Уменьшить количество роз на 10 для пользователя, C4=Добавить 10 роз на склад

Предположим, транзакция выполняется до T4 и происходит аварийный откат.Когда C4 хочет добавить розы обратно в инвентарь, обнаруживается, что все розы пользователя израсходованы.Недостатки саги, проблема, вызванная отсутствием изоляции между транзакциями.

Эта проблема может быть решена следующими решениями:

  • Добавьте логику логической блокировки на уровне приложения.
  • Изоляция на уровне сеанса для обеспечения сериализации.
  • На уровне бизнеса эта часть средств изолируется путем предварительной заморозки средств.
  • Во время бизнес-операции обновление получается путем считывания текущего состояния во времени.

Ссылка и спасибо

Личный публичный аккаунт

  • Если вы считаете, что это хорошо написано, пожалуйста, поставьте лайк + подпишитесь, спасибо~
  • В то же время, я очень жду, что мои друзья обратят внимание на мой официальный аккаунт, и позже я постепенно представлю более качественные галантерейные товары~ хи хи
  • адрес гитхаба:GitHub.com/Я бы хотел 123/Java…
Категории