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

Схема статьи

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

Причина этого обмена

Реконструкция платежа

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

Итак, представьте, темы, которыми мы хотим поделиться и обсудить сегодня:Как решить проблемы согласованности данных в распределенных сценариях, на данный моментРаспределенная транзакцияДавайте определим это.

Та же проблема существует и в других сценариях:

Подарок:

1. 调用支付服务：先扣送礼用户的金币，然后给主播加相应的荔枝
2. 确认第一步成功后，播放特效，发聊天室送礼评论等

Сообщение об успешной перезарядке:

Завершить заказ пополнения
Отправить kafka сообщение о завершении заказа

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

Как в настоящее время решается распределенная транзакция?

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

отУспешная покупка основного продуктаЗаднийОтправить сообщение о завершении платежного порученияНапример:

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

Прочитайте этот процесс:

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

Отправить работу на JobController (для восстановления неудачи)
После успешной отправки начните обработку логики заказа.
После обработки логики заказа начните отправлять сообщения kafka
После того, как сообщение также будет успешно отправлено, удалите задание, отправленное на первом шаге.

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

Контроллер задач JobController регулярно обращается к Redis для запроса списка отложенных задач (каждая задача имеет метку времени, которая сортируется и фильтруется по метке времени)
Возобновить выполнение задачи (вызов метода обработки, определенного при регистрации задания)
Задача выполнена успешно, что указывает на то, что процесс завершен; в противном случае повторите попытку в следующем временном цикле.

проблема:

Основываясь на задачах восстановления хранилища Redis, может существовать риск потери данных.
В системе архитектуры нет единой спецификации распределенных транзакций.Может ли этот уровень логики быть независимым от промежуточного программного обеспечения распределенных транзакций?
Отсутствие управления политикой выполнения транзакций, например: контроль максимального количества повторных попыток и т. д.
Статус выполнения транзакции не фиксируется, и для отслеживания нужно смотреть лог.

Какие есть решения в отрасли

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

Обоснование (посылка для обсуждения)

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

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

Сильная согласованность, слабая согласованность, окончательная согласованность

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

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

N — количество копий данных
W — Количество узлов, которые должны быть гарантированно записаны при обновлении данных
R — количество узлов для чтения при чтении данных

Если W+R>N, узел записи и узел чтения перекрываются, это строгая согласованность. Например, для типичной синхронно реплицируемой реляционной базы данных «один главный — один резервный» N = 2, W = 2, R = 1, независимо от того, читаются ли данные основной базы данных или резервной базы данных, она непротиворечива.

Если W+R

теория CAP

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

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

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

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

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

гибкие дела

В отличие от жесткой транзакции ACID, концепция гибкой транзакции появляется в распределенном сценарии, основанном на теории BASE. Для достижения конечной непротиворечивости за счет гибких транзакций необходимо опираться на некоторые характеристики, которые не обязательно должны выполняться в конкретных схемах, так как разные схемы предъявляют разные требования, но если они не выполняются, невозможно вести гибкий бизнес.

Видимость (внешний запрос)

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

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

идемпотентная операция

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

f(f(x)) = f(x)

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

Отраслевые решения

Двухэтапная фиксация (2PC)

XA — это интерфейс для связи между TM (диспетчером транзакций) и RM (менеджером ресурсов), определенным в модели спецификации X/Open CAE (распределенная обработка транзакций).

В спецификации XA база данных играет роль RM, а приложение должно играть роль TM, то есть генерировать глобальный txId, вызывать интерфейс XAResource и координировать несколько локальных транзакций в глобально унифицированную распределенную транзакцию.

Двухфазная фиксация — это стандартная реализация XA. Он разделяет фиксацию распределенных транзакций на 2 фазы: подготовка и фиксация/откат.

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

saga

Сага была впервые предложена для решения проблемы долго выполняющихся процессов, которые могут выполняться в течение длительного времени. Так называемая длительная распределенная транзакция относится к тем корпоративным бизнес-процессам, которым необходимо выполнить транзакцию между приложениями и предприятиями, и даже требуют ручного участия в процессе транзакции.Время выполнения таких транзакций может быть разбито на минуты, часы. , может быть, даже в днях. Если этот тип транзакции разработан в соответствии с требованиями ACID транзакции, доступность системы будет значительно снижена. Представьте себе транзакцию, в которой участвуют два сервера, сервер A инициирует транзакцию, сервер B участвует в транзакции, а транзакция B требует ручного участия, поэтому время обработки может быть очень большим. В соответствии с принципом ACID для обеспечения изоляции и согласованности транзакции ресурсы транзакции, используемые в транзакции, инициированной сервером А, будут заблокированы, а другим приложениям не будет разрешен доступ к промежуточным результатам в процессе транзакции до тех пор, пока вся транзакция является фиксацией или откатом. Это приводит к тому, что ресурсы в транзакции A будут заблокированы на долгое время, и доступность системы будет неприемлемой.

иSaga, с другой стороны, представляет собой основанное на компенсации решение для длительных процессов, управляемое сообщениями. Цель состоит в том, чтобы обеспечить максимально возможную согласованность данных на основе обеспечения высокой доступности системы.. В приведенном выше примере, если для его реализации используется saga, процесс выглядит следующим образом: сначала выполняется транзакция сервера A. Если выполнение успешно, то первой будет отправлена транзакция A, если отправка успешна, то транзакция B будет выполнено Если транзакция B также Если выполнение выполнено успешно, транзакция B также фиксируется, и вся транзакция завершается. Однако, если транзакция B не выполняется, необходимо выполнить откат самой транзакции B. В это время, поскольку транзакция A была зафиксирована, необходимо выполнить операцию компенсации, чтобы отменить операцию, выполненную транзакцией A, которая была зафиксирована, и восстановить к транзакции A до того, как она не была выполнена.Такая идея реализации, основанная на сообщениях, — это сага.. Мы видим, что сага жертвует строгой согласованностью данных и обеспечивает только окончательную согласованность, но повышает общую доступность системы.

Компенсационная транзакция (TCC)

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

Этап пробы в основном предназначен для тестирования бизнес-системы и резервирования ресурсов.
Фаза подтверждения в основном предназначена для подтверждения и отправки бизнес-системы.Когда фаза попытки успешно выполнена и начинается фаза подтверждения, фаза подтверждения по умолчанию не пойдет не так. То есть: пока попытка успешна, подтверждение должно быть успешным.
Этап «Отмена» в основном предназначен для отмены выполнения бизнеса в состоянии ошибки выполнения бизнеса, и его необходимо откатить, а также высвободить зарезервированные ресурсы.

Ниже приведен пример перевода 100 юаней со счета A на счет B в режиме TCC и подробный анализ трансформации бизнеса:

Службы денежных переводов и службы сбора были необходимы для достижения интерфейсов Try-Confirm-Cancel и фазы бизнес-инициализации, которая вводится в диспетчер транзакций TCC.

[汇款服务]
Try：
    检查A账户有效性，即查看A账户的状态是否为“转帐中”或者“冻结”；
    检查A账户余额是否充足；
    从A账户中扣减100元，并将状态置为“转账中”；
    预留扣减资源，将从A往B账户转账100元这个事件存入消息或者日志中；
Confirm：
	不做任何操作；
Cancel：
    A账户增加100元；
	从日志或者消息中，释放扣减资源。

[收款服务]
Try：
	检查B账户账户是否有效；
Confirm：
    读取日志或者消息，B账户增加100元；
    从日志或者消息中，释放扣减资源；
Cancel：
	不做任何操作。

Из этого видно, что модель TCC имеет сильное вторжение в бизнес и ее трудно трансформировать.

Локальная таблица сообщений (обеспечена асинхронность)

Реализация локальной таблицы сообщений должна быть наиболее часто используемой в отрасли.Основная идея состоит в том, чтобы разделить распределенные транзакции на локальные транзакции для обработки.Эта идея исходит от eBay. Мы можем увидеть некоторые из этих деталей на блок-схеме ниже:

Основная идея такова:

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

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

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

сообщение о транзакции

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

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

Есть некоторые сторонние MQ, которые поддерживают транзакционные сообщения, такие как RocketMQ, но некоторые основные MQ на рынке не поддерживают транзакционные сообщения, такие как RabbitMQ и Kafka.

сделать все возможное, чтобы уведомить

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

Внедрение схемы уведомления Best Effort

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

Особенности схемы уведомления Best Effort

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

сравнить план

Атрибуты	2PC	TCC	локальная таблица сообщений	сообщение о транзакции	сделать все возможное, чтобы уведомить
Транзакционная согласованность	мощный	слабый	слабый	слабый	слабый
Сложность	середина	высокий	Низкий	Низкий	Низкий
деловой навязчивый	маленький	Большой	середина	середина	середина
Использовать ограничения	Большой	Большой	маленький	середина	середина
представление	Низкий	середина	высокий	высокий	высокий
стоимость технического обслуживания	Низкий	высокий	Низкий	середина	середина

что делают другие люди

Сервис распределенных транзакций Alipay DTS

Woohoo.cloud.Ali боится, что is.com/docs/2/4688…

Служба распределенных транзакций (DTS) — это структура распределенных транзакций, используемая для обеспечения возможной согласованности транзакций в крупномасштабной распределенной среде. С точки зрения архитектуры DTS делится на две части: xts-client и xts-server: первая представляет собой встроенный в клиентские приложения пакет Jar, который в основном отвечает за запись и обработку данных транзакций, вторая представляет собой самостоятельную систему, в основном несет ответственность за аномальные транзакции.

основная концепция

Внутри DTS мы разделяем связанные стороны распределенной сделки на две категории: инициаторы и участники:

Инициатор:Инициатор распределенной транзакции отвечает за запуск распределенной транзакции и инициирование создания соответствующей записи основной транзакции. Инициатор — это координатор распределенной транзакции, ответственный за вызов службы участника, запись соответствующего журнала транзакций и определение состояния всей распределенной транзакции, чтобы определить, является ли вся транзакция COMMIT или ROLLBACK.

**Участник: **Участник — это элементарная единица в распределенной транзакции. Все участники должны аннотировать (Аннотация) идентификатор участника в интерфейсе первой фазы (Подготовка), который определяетprepare,commit,rollback3 основных интерфейса, бизнес-система должна реализовать эти 3 интерфейса и обеспечить идемпотентность своих бизнес-данных, а также должна обеспечитьprepareОперации с данными могут быть зафиксированы (COMMIT) или откатываться (ROLLBACK). По структуре хранения данные о состоянии транзакций DTS можно разделить на две категории: запись основной транзакции (Действие) и запись транзакции ветвления (Действие):

**Основная запись транзакции Действие:** Основная запись транзакции является основной частью всей распределенной транзакции, а ее основной структурой данных являются номер транзакции (TX_ID) и статус транзакции (СОСТОЯНИЕ), которые сохраняются, когда распределенная транзакция При записи в базу данных ее состояние определяет состояние распределенной транзакции.

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

Это должно принадлежать режиму TCC, о котором мы упоминали выше.

eBay Локальная форма сообщения

woohoo.info Q.com/talent/articles… Weibo.com/Статья TT/Боюсь…

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

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

Обычно есть два пути:

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

Куда идти, Mogujie похоже на использование локальной таблицы сообщений + уведомление о сообщении

Различные сторонние платежные обратные вызовы

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

как мы можем сделать это

2PC/3PC требует, чтобы менеджер ресурсов (mysql, redis) поддерживал протокол XA, а ресурсы транзакции должны быть заблокированы во время выполнения всей транзакции, что снизит производительность. Так что исключите его в первую очередь.

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

Тип уведомления с наилучшими усилиями, применяемый к разнородным или сервисным платформам.

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

Q&A

Обсудить DDD (в недоумении)
сага падает

Ссылаться на

Шардинг-сфера:Tickets.WeChat.QQ.com/Yes/l Учитель физкультуры hu3…

RocketMQ официально распространяет сообщения о транзакциях с открытым исходным кодом:Tickets.WeChat.QQ.com/Yes/K-line, чтобы посмотреть акции 2A-7…

Уведомление о лучших усилиях:blog.CSDN.net/Это 2050 год/искусство…

Расскажите о распределенных транзакциях:woo woo woo.cn blog on.com/savor board/…

saga: Блог Woohoo.cn на.com/net focus/afraid/…