предисловие

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

Конкретное определение транзакции

Транзакции обеспечивают механизм включения всех операций, участвующих в операции, в неделимую исполнительную единицу.Все операции, составляющие транзакцию, могут быть зафиксированы, только если все операции могут выполняться нормально.Вызывает откат всей транзакции. Проще говоря, транзакции обеспечивают механизм «все или ничего».

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

ACID

Когда дело доходит до транзакций базы данных, нужно сказать, что четыре основные характеристики транзакций базы данных, ACID:

• A: атомарность

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

Точно так же, когда вы что-то покупаете, вы должны заплатить и получить это, или, если вы не можете отправить это, вы получите свои деньги обратно.

• С: Консистенция

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

• Я: Изоляция

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

Например, когда вы что-то покупаете, это не влияет на других людей.

• Д: долговечность

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

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

Принцип реализации InnoDB

InnoDB — это механизм хранения mysql.Большинство людей знакомы с mysql.Вот краткое введение в некоторые основные принципы реализации транзакций базы данных.В локальных транзакциях службы и ресурсы можно рассматривать как одно целое в пакете транзакций:

Нашими локальными транзакциями управляет менеджер ресурсов:

ACID транзакции гарантируется журналами и блокировками InnoDB. Изоляция транзакций реализуется через механизм блокировок базы данных, сохраняемость реализуется через журнал повторов (redo log), а атомарность и непротиворечивость реализуются через журнал отмены. Принцип UndoLog очень прост: чтобы удовлетворить атомарность транзакций, прежде чем оперировать какими-либо данными, сначала создайте резервную копию данных в определенном месте (место, где хранится резервная копия данных, называется UndoLog). Затем измените данные. Если возникает ошибка или пользователь выполняет оператор ROLLBACK, система может использовать резервную копию в журнале отмены для восстановления данных в состояние до начала транзакции. В отличие от Undo Log, RedoLog записывает резервную копию новых данных. Перед тем, как транзакция будет зафиксирована, пока RedoLog сохраняется, данные не нужно сохранять. Когда система дает сбой, хотя данные не сохраняются, RedoLog сохраняется. Система может восстановить все данные до последнего состояния в соответствии с содержимым RedoLog. Учащиеся, заинтересованные в конкретном процессе реализации, могут искать и расширять самостоятельно.

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

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

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

Причины распределенных транзакций

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

обслуживать несколько узлов

С бурным развитием Интернета широко используются микросервисы, SOA и другие модели сервисной архитектуры, например, внутри компании активы пользователя могут быть разделены на несколько частей, таких как баланс, баллы, купоны и т. д. Подождите. Возможно, функцию баллов поддерживает команда микросервисов внутри компании, а купонов — другая команда.

В этом случае нет гарантии, что купоны могут быть успешно списаны после списания баллов.

несколько узлов ресурса

Точно так же Интернет развивается слишком быстро.Вообще говоря, наша Mysql должна быть подбазой данных и подтаблицей для установки десятков миллионов данных.Для бизнеса по переводу Alipay, если вы переводите деньги другу, возможно, что ваша база данных находится в Пекине, а деньги вашего друга находятся в Шанхае, поэтому мы все еще не можем гарантировать, что они будут успешными одновременно.

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

С вышеупомянутой точки зрения, распределенные транзакции возникли с быстрым развитием Интернета. Это неизбежный факт. Ранее мы говорили, что четыре характеристики ACID базы данных больше не могут удовлетворять нашим распределенным транзакциям. В настоящее время существует какие-то новые большие Гай предлагает несколько новых теорий:

CAP

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

• C (согласованность): для данного клиента операция чтения может вернуть последнюю операцию записи. Для данных, распределенных по разным узлам, если данные обновляются на определенном узле, если последние данные могут быть прочитаны другими узлами, это называется строгой согласованностью.Если узел не читает данные, если вы их получаете, они распределяются непоследовательность.
• A (доступность): исправный узел возвращает разумный ответ (не ответ об ошибке и тайм-ауте) в разумные сроки. Двумя ключами к доступности являются разумное время и разумный ответ. Разумное время означает, что запрос не может быть заблокирован на неопределенный срок и должен быть возвращен в разумные сроки. Разумный ответ означает, что система должна явно возвращать результат, и результат правильный, где правильный означает, что она должна возвращать, например, 50, а не 40.
• P (Partition Tolerance): система может продолжать работу при возникновении сетевого раздела. Например, в кластере несколько машин, и есть проблема с сетью одной машины, но кластер все еще может нормально работать.

Любой, кто знаком с CAP, знает, что три нельзя разделить.Если вам интересно, вы можете поискать доказательство CAP.В распределенной системе сеть не может быть на 100% надежной, и разделение на самом деле является неизбежным явлением.Если мы выбираем CA и отказываемся от P, Тогда, когда происходит разделение, для обеспечения согласованности запрос должен быть отклонен в это время, но A не разрешает это, поэтому для распределенной системы теоретически невозможно выбрать архитектуру CA , только архитектура CP или AP.

Для CP, чтобы отказаться от доступности и добиться согласованности и отказоустойчивости разделов, наш zookeeper на самом деле является стремлением к строгой согласованности.

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

Кстати, теория CAP игнорирует сетевую задержку, то есть когда транзакция совершается, она копируется с узла A на узел B, но в реальности это заведомо невозможно, поэтому всегда будет какое-то несоответствие времени. В то же время, выбирая два CAP, например, вы выбираете CP, это не говорит вам отказаться от A. Поскольку вероятность появления P очень мала, большую часть времени вам все равно нужно гарантировать CA. Даже если раздел появится, вы должны подготовиться к более позднему A, например, с помощью некоторых журналов другие машины будут восстановлены в рабочем состоянии.

BASE

BASE — это аббревиатура от «основно доступный» (в основном доступный), «мягкое состояние» (мягкое состояние) и «в конечном счете согласованное» (конечная согласованность) трех фраз. Это расширение AP в CAP

1. Базовая доступность: при сбое распределенной системы часть доступных функций может быть потеряна, а основные функции гарантированно доступны.
2. Мягкое состояние: допускает существование промежуточных состояний в системе, которые не влияют на доступность системы, что относится к несоответствиям в CAP.
3. Согласованность в конечном счете. Согласованность в конечном итоге означает, что через определенный период времени все данные узла будут согласованы.

BASE решает теорию об отсутствии сетевой задержки в CAP и использует мягкое состояние и согласованность в конечном счете в BASE для обеспечения согласованности после задержки. BASE и ACID являются противоположностями, они полностью отличаются от модели строгой согласованности ACID, но обеспечивают доступность, жертвуя строгой согласованностью, и позволяют данным быть несогласованными в течение определенного периода времени, но в конечном итоге достигают согласованного состояния.

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

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

Вам действительно нужны распределенные транзакции?

Прежде чем говорить о решении, прежде всего вы должны уточнить, действительно ли вам нужны распределенные транзакции?

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

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

2PC

Когда дело доходит до 2PC, мы должны говорить о транзакциях XA в распределенных транзакциях базы данных.

В протоколе XA есть две фазы:

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

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

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

недостаток:

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

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

TCC

Концепция TCC (Try-Confirm-Cancel) была впервые предложена Пэтом Хелландом в статье под названием «Жизнь за пределами распределенных транзакций: мнение отступника», опубликованной в 2007 году. По сравнению с XA, представленным выше, механизм транзакций TCC устраняет несколько недостатков: 1. Решается единая точка координатора, а основная деловая сторона инициирует и завершает эту деловую активность. Менеджер деловой активности также стал многоточечным, представив кластеры. 2. Синхронная блокировка: введите время ожидания, компенсируйте время ожидания и не блокируйте весь ресурс, преобразуйте ресурс в форму бизнес-логики и уменьшите степень детализации. 3. Согласованность данных, с механизмом компенсации, согласованность контролируется менеджером деловой активности.

Пояснение к ТСС:

• Пробная фаза: попытка выполнить, завершить все бизнес-проверки (согласованность), зарезервировать необходимые бизнес-ресурсы (квазиизоляция).

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

• Стадия отмены: отмените выполнение и освободите бизнес-ресурсы, зарезервированные на стадии пробной версии. Операция Cancel удовлетворяет идемпотентности Исключение фазы Cancel в основном такое же, как и решение для обработки исключений фазы Confirm.

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

Если произошел сбой, отмените (отпустите 100 юаней и эту бутылку воды), а если отмена не удалась, повторите попытку отмены независимо от сбоя, поэтому он должен оставаться идемпотентным.

Если оба успешны, подтвердите, подтвердите, что вычет 100 юаней и бутылка воды проданы, если подтверждение не удается, независимо от того, что не удается, повторите попытку (для повторной попытки будет полагаться на журнал активности)

Некоторые подходят для TCC:

• Активный бизнес с жесткой изоляцией и строгими требованиями согласованности.
• Бизнес с более коротким сроком исполнения

Ссылка на реализацию: ByteTCC:GitHub.com/Лю Янмин…

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

Схема локальной таблицы сообщений изначально была предложена eBay как полная схема eBay https://queue.acm.org/detail.cfm?id=1394128.

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

Ядром локальной очереди сообщений является преобразование больших транзакций в небольшие. Возьмем пример покупки бутылки воды за 100 юаней выше.

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

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

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

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

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

MQ-транзакция

Распределенная транзакция реализована в RocketMQ, который на самом деле является инкапсуляцией локальной таблицы сообщений, которая перемещает локальную таблицу сообщений внутрь MQ. Ниже кратко представлена ​​транзакция MQ. Если вы хотите узнать о ней больше, вы можете Ссылаться на:woohoo.brief.com/afraid/453 из 6 или 7 методов…

Основной процесс выглядит следующим образом: На первом этапе «Подготовленное сообщение» будет получен адрес сообщения.

На втором этапе выполняются локальные транзакции.

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

Если сообщение с подтверждением не удается, брокер RocketMq обеспечивает регулярное сканирование сообщений, которые не были обновлены. Если сообщение не подтверждено, он отправит сообщение отправителю, чтобы определить, отправлять ли его. В Rocketmq оно отправляется на отправитель в виде слушателя., для обработки.

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

Сага дела

Сага — это концепция, упомянутая в статье об этике баз данных 30 лет назад. Основная идея состоит в том, чтобы разбить длинную транзакцию на несколько локальных коротких транзакций, которые координируются координатором транзакций Saga. Если она завершается нормально, она будет завершена нормально. Если шаг терпит неудачу, операция компенсации вызывается один раз в обратном порядке. . Состав саги:

Каждая сага состоит из серии подтранзакций Ti Каждый Ti имеет соответствующее компенсационное действие Ci, и компенсационное действие используется для отмены результатов, вызванных Ti.Каждое T здесь является локальной транзакцией. Видно, что по сравнению с TCC у Saga нет действия «зарезервированная попытка», и его Ti напрямую передается в библиотеку.

Для Саги есть два приказа на выполнение:

T1, T2, T3, ..., Tn

T1, T2, ..., Tj, Cj,..., C2, C1, где 0

Восстановление назад, то есть второй порядок выполнения, упомянутый выше, где j — подтранзакция с ошибкой, результатом этого подхода является отмена всех предыдущих успешных подтранзакций, так что результат выполнения всей саги отменяется. . Прямое восстановление, подходящее для сценариев, которые должны завершиться успешно, порядок выполнения аналогичен следующему: T1, T2, ..., Tj (сбой), Tj (повторная попытка), ..., Tn, где j - ошибка, возникшая под- сделка. Ci в этом случае не требуется.

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

Или возьмем, к примеру, покупку бутылки воды за 100 юаней, вот определение

T1=вычесть 100 юаней T2=добавить пользователю бутылку воды T3=убрать бутылку воды со склада

C1=Добавить 100 юаней C2=Уменьшить пользователю бутылку воды C3=Добавить бутылку воды в инвентарь

Мы делаем T1, T2, T3 за один раз.Если возникает проблема, выполняем обратную операцию C, в которой возникла проблема. Возникнет упомянутая выше проблема изоляции.Если выполнение дойдет до Т3, нужно выполнить откат, но пользователь уже выпил воду (другая транзакция), при откате обнаружится, что пользователь не может быть сокращен на 1. Бутилированная вода. Это проблема отсутствия изоляции между транзакциями

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

Конкретный пример: вы можете обратиться к сервисному чату Huawei.

Наконец

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

1. Являются ли CAID и CAP одним и тем же?
2. Каковы плюсы и минусы широко используемых решений для распределенных транзакций? К какому сценарию относится?
3. Причина появления распределенных транзакций? Для решения какой болевой точки он используется?

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

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