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

В этой статье впервые представлены соответствующие изосновные теория,Затем придумали самое классическое решение издела.,Наконец, выдается внеочередное выполнение поддела (Идемпотент, нулевая компенсация, проблема зависания) и зрешение.,Поделитесь этим со всеми.

основная теория

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

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

дела

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

делаиметь 4 Свойства: атомарность, согласованность, изоляция и долговечность. Эти четыре свойства часто называют ACID характеристика.

• Атомарность (атомарность): все операции в одном делеиз,или сделай все это,Или не завершить все это,Оно не закончится существование где-то посередине. Произошла ошибка во время выполнения деласуществовать.,будет восстановлено состояние до начала делаиз,Как будто это дело никогда не было исполнено.
• Консистенция: существуютдела Перед запуском、в ходе выполнения、По окончании целостность библиотеки данных не нарушается. Целостность включает ограничения внешнего ключа、Ограничения, такие как определение приложения, не будут нарушены.
• Изоляция: Библиотека данных позволяет нескольким параллельным делам одновременно читать, записывать и изменять свои возможности данных. Изоляция может предотвратить несогласованность данных, вызванную перекрестным выполнением, когда несколько дел выполняются одновременно.
• Долговечность: после окончания обработки дела,Изменения данных являются постоянными.,Он не будет потерян, даже если система выйдет из строя.

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

Распределенные дела

Бизнес по межбанковским переводам является типичным Распределенные деласцена,Предположим, A необходимо перевести деньги B через банки.,Так задействованы два банка изданные,Невозможно передать библиотеку данных из местных дел, гарантированная передача изACID,Возможно только через Распределенные деларешить。

Распределенные Дела относятся к инициатору делаиз, ресурсам и менеджерам ресурсов и координатору дел, которые расположены на разных узлах распределенной системы В. существуют Вышеуказанный перенос находится в процессе,Операция пользователя А-100 и операция пользователя В+100 не расположены на одном и том же узле. По сути,Распределенные дела призваны гарантировать, что существование распределяется по распределенным сценариям.,Операция с данными выполнена правильно.

ACID

Распределенные дела частично последуют ACID спецификация:

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

Потому что в процессе дел,Не единогласно,Но дела в конечном итоге будут сделаны,Наконец пришли к консенсусу,Итак, мы положили Распределенные деланазывается“окончательный консенсус”

Окончательное объяснение согласованности

Особый акцент,здесьизокончательный консенсуссексуальная гармонияCAP（C:последовательность,А: Наличие,P: толерантность к разделению) в конечном итоге согласованность отличается,В настоящее время большая часть книг и материалов,Путаница этих двух,Ниже мы остановимся на последовательности объяснения.

C CAP относится к согласованности при чтении данных из нескольких реплик в распределенной системе. Проще говоря, если я обновляю кусок данных с v1 до v2, то читаются любые данные:

• Сильная согласованность: если версию 2 можно читать каждый раз, то это сильная согласованность.
• Слабая согласованность: он может читать v1 или v2, тогда он слабо согласован.
• Окончательная согласованность: по прошествии определенного периода времени убедитесь, что версия 2 может быть прочитана каждый раз, тогда она в конечном итоге будет согласованной.

Предложена теория CAP,Распределенные системы не могут одновременно удовлетворять трем характеристикам.,Вы можете выбрать максимум 2,Столкнулся с такими проблемами,Есть такая классикаиз ПланBASEтеория,Этот тип программы преследует AP,Тогда смягчите требования к Cиз. AWSиз Динамо – именно такая система,предоставил окончательный вариантпоследовательное чтение,Подробности см.Dynamo последовательное чтение

В последние годы теория распределенности получила дальнейшее развитие, и многие системы используют не решение BASE, а решение CP+HA (Highly-Available). Протоколы распределенного консенсуса, такие как Paxos и Raft, полностью соответствуют CP. С точки зрения A-доступности, хотя она не доступна на 100%, в сочетании с обновлениями стабильности оборудования в последние годы можно достичь высокой доступности. Публичные данные распределенной блокировки Google Chubby показывают, что кластер может обеспечить среднюю доступность 99,99958% с перерывами в работе всего 130 секунд в год, что может соответствовать очень строгим требованиям приложений. Сегодняшнее программное обеспечение баз данных SQL использует CP+HA, но HA будет ниже, чем экстремальные данные Google, но обычно может достигать четырех девяток.

CP+HA означает не BASE, а это означает, что при успешной записи при следующем чтении разработчикам не придется беспокоиться о чтении не самых последних данных при чтении и записи нескольких копий. , это то же самое, что и «Одна машина согласована».

потому что Распределенные дела Исследуйте и решайтеиз В основном с участиемимногоданные Библиотекаизданныепоследовательность,Актуальные данныеиз хранилища основные существующие библиотеки,Следовательно, это тоже CP+HA. Таким образом, распределенные дела удовлетворяют требованиям CAPizC.,Но это не удовлетворяет ACIDизC,Также известный как в конечном итоге последовательный

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

Зависит от ВРаспределенные делаплан,Полной гарантии ACIDиз не существует.,Идеального решения не существует,Способен решить все бизнес-задачи. Поэтому существуют в практическом применении,Будет варьироваться в зависимости от особенностей бизнеса,Выберите наиболее подходящийиз Распределенные делаплан。

Одно- и двухэтапная подача/XA

XAда Зависит отX/Openпредложено организациейиз Распределенные делаизспецификация,Спецификация XA в основном определяет интерфейс между (глобальным) Менеджером дел™ и (локальным) Менеджером ресурсов (RM). Локальные изданные библиотеки, такие как mysqlсуществоватьXA, играют роль RM.

XA делится на два этапа:

Первый этап (подготовка): то есть все участники RM готовы выполнить дела и заблокировать необходимый изресурс. Когда участник готов, он сообщает TM, что готов. второй этап (фиксация/откат): когда Менеджер дел™ подтвердит, что все участники (RM) готовы, отправьте команду фиксации всем участникам. В настоящее время основные изданные библиотеки в основном поддерживают такие задачи, как mysql, oracle, sql server и postgresql.

XA дела состоят из одного или нескольких менеджеров ресурсов (RM), менеджера дел (TM) и приложения (ApplicationProgram).

Три роли RM, TM и AP здесь являются классическими ролевыми подразделениями, которые будут действовать в последующих режимах Saga, Tcc и других делах.

Если взять приведенный выше пример передачи, успешно завершенная диаграмма последовательности XAдела выглядит следующим образом:

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

Особенности XAделаиз:

• Просто и понятно, легче разрабатывать
• ресурс давно заблокирован,Низкий параллелизм

Если читатели хотят дальше изучать XA,goязык сиPHP、Python、Java、C#、NodeВы можете обратиться к немуDTM

2.САГА

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

Если взять приведенный выше пример передачи, то успешно завершенная диаграмма последовательности действий SAGAдела выглядит следующим образом:

Как только Saga достигает стадии отмены, Cancel не может потерпеть неудачу с точки зрения бизнес-логики. Если успех не возвращается из-за сетевых или других временных сбоев, TM будет продолжать повторять попытки, пока Отмена не вернет успех.

Сагаделаиз Особенности:

• Высокий параллелизм,Никакой долгосрочной блокировки, как у XAdel
• Необходимо определить нормальные операции и компенсационные операции, а объем разработки больше, чем у XA.
• Менее последовательный,Трансфер в В,Может случиться так, что пользователь А списал деньги,Окончательный перенос снова не удался.

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

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

Если читатели захотят изучить SAGA дальше,Можно ссылатьсяDTM,Он включает примеры отката успеха и неудачи SAGA.,Он также включает в себя различные типы обработки сетевых аномалий.

3. ТСС

Концепция TCC (Try-Confirm-Cancel) была впервые предложена Пэтом Хелландом в статье «Жизнь за пределами распределенных транзакций: мнение отступника», опубликованной в 2007 году.

TCC делится на 3 этапа

• Этап «Попытка»: попробуйте выполнить, выполните все бизнес-проверки (согласованность), зарезервируйте необходимые бизнес-ресурсы (квазиизоляция).
• Confirm Этап: Подтвердить, что исполнитель фактически выполняет бизнес, без каких-либо бизнес-проверок, только с помощью Try Стадия резервирования избизнесресурса, Подтвердить Для работы требуется конструкция Идемпотент. Подтвердите. Необходимо повторить попытку после неудачи.
• Cancel Фаза: отмена выполнения, выпуск Try Резервирование этапа из бизнесресурса. Отмена Стадия из Исключения и Confirm этап Обработка Планы исключений в основном те же, а требования соответствуют конструкции Идемпотент.

Возьмем приведенный выше трансфер в качестве примера.,Обычно сумма замораживается внутри существования. Попробуйте,Но без вычета,Вычет в подтверждении,Разморозить сумму в Отменить,Успешно завершенная временная диаграмма изTCCдела выглядит следующим образом:

Фаза подтверждения/отмены TCC не может возвращать ошибку из-за бизнес-логики. Если она не может вернуть успех из-за сетевых или других временных сбоев, TM будет продолжать повторять попытки до тех пор, пока подтверждение/отмена не вернется успешно.

Особенности TCC следующие:

• Высокий уровень параллелизма и отсутствие долгосрочной блокировки ресурсов.
• Объем разработки большой, и необходимо предоставить интерфейс Try/Confirm/Cancel.
• Согласованность хорошая, и не будет ситуации, когда SAGA списала деньги, а затем не смогла их перевести.
• TCC подходит для бизнеса заказного типа,Предприятия с ограничениями на промежуточные состояния

Если читатели хотят дальше изучать TCC,Можно ссылатьсяDTM

4. Таблица локальных сообщений

Решение о локальной таблице сообщений изначально было статьей, опубликованной архитектором eBay Дэном Притчеттом в ACM в 2008 году. Суть конструкции — асинхронное обеспечение выполнения задач, требующих распределенной обработки, посредством сообщений.

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

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

Механизм отказоустойчивости:

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

Особенности таблицы локальных сообщений:

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

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

5. новости дела

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

дела Отправка и отправка сообщений:

• Отправить сообщение (половина сообщения)
• Сервер сохраняет сообщение и записывает результат в ответ на сообщение.
• Выполнять локальные дела на основе отправленного результата (если запись не удалась),В настоящее время половина сообщения не видна компании.,Локальная логика не выполняется)
• Выполнить фиксацию или откат в соответствии со статусом локальных дел (операция фиксации публикует сообщения,Сообщение видно потребителям)

Блок-схема обычной отправки выглядит следующим образом:

Процедура компенсации:

Если нет сообщения Commit/Rollback издела (ожидающий статус из сообщения), инициируйте «проверку возврата» с сервера. Производитель получает сообщение обратного подтверждения, и возвращенное сообщение соответствует локальному статусу, то есть фиксации или отката. Схема сообщений дел очень похожа на механизм локальной таблицы сообщений. Основное отличие состоит в том, что исходная операция, связанная с локальной таблицей, была заменена интерфейсом обратного запроса.

Особенности сообщения дела следующие:

• Длинные дела нужно только разбить на несколько задач,И предоставить интерфейс обратной проверки,Простота в использовании
• Нет хорошего решения для проверки новостей,ошибки данных могут возникнуть в крайних случаях

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

Если читатели хотят дальше изучать новости дела,Можно ссылатьсяDTM,Вы также можете обратиться кRocketmq

6. Уведомление о наилучших возможностях

Уведомляющая сторона прилагает все усилия, чтобы уведомить принимающую сторону о результатах бизнес-обработки посредством определенного механизма. В частности, включите:

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

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

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

С точки зрения решения, уведомление о максимальных усилиях требует:

• Предоставьте интерфейс, чтобы получатели уведомлений могли запрашивать результаты бизнес-обработки через интерфейс.
• Механизм подтверждения очереди сообщений,Очередь сообщений следует интервалу 1мин, 5мин, 10мин, 30мин, 1ч, 2ч, 5ч, 10ч.,Постепенно увеличивайте интервал уведомлений, пока не будут достигнуты требования к уведомлению и верхний предел временного окна. Больше никаких уведомлений

Уведомление о максимальных усилиях подходит для типов бизнес-уведомлений. Например, о результатах транзакций WeChat сообщается каждому продавцу через уведомление о максимальных усилиях. Существуют как уведомления об обратном вызове, так и интерфейсы запроса транзакций.

7. Режим АТдела

Это проект Alibaba с открытым исходным кодом.seataсерединаиз Что-то вродеделамодель,существует Ant Financial также известна как FMT. Преимущество в том, что режим дела используется в,Аналогично режиму XA,Бизнесу не нужно писать различные компенсационные операции,Откат выполняется автоматически платформой,Эта модель также имеет много недостатков,С одной стороны, это похоже на XA.,Сохранить на более длительное время из замка,С другой стороны, он не соответствует сценариям с высоким уровнем параллелизма, существуют такие проблемы, как грязный откат;,Легко вызвать несогласованность данных. Сравнительное исследование о АТ и XA,Вы можете обратиться к: XA vs AT

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

https://github.com/dtm-labs/dtmсуществоватьизучал классикуиз Различныйрешениепосле,По опыту многих компаний, использующих дтмиз,Предложено новое решение, более удобное и простое в использовании.,Помогите каждому решить проблемы согласованности между базами данных и службами лучше и быстрее.

сообщение второго этапа

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

Схема работы сообщения второго этапаиз выглядит следующим образом:

Сравнивая таблицы локальных сообщений и сообщения дел, сообщение второго этапа имеет следующие преимущества:

• Очередь не требуется,Так что нет необходимости в потребителях,Пользователь просто вызывает API
• сообщение второго этапа Также есть обратная проверка,Но отзыв автоматически обрабатывается фреймворком,И убедитесь, что данные верны

осообщение второго этапы Подробнее см. здесь сообщение второго этапа

Схема рабочего процесса

Ранее мы представили XA, Saga, Tcc и другие режимы.,Каждый режим имеет соответствующие преимущества и недостатки.,Подходит для разных видов бизнеса. Есть ли способ объединить их преимущества?,Используйте разные режимы для разных сервисов,А потом объединить их в глобальные дела?

Первый режим рабочего процесса dtm может поддерживать смешанное использование трех вышеупомянутых режимов.,Также позволяет смешанное использование HTTP/gRPC/локальных дел.,Имеет большую гибкость,Он может решать различные бизнес-сценарии.

Подробную информацию о рабочем процессе можно найти здесь. Workflow

Обработка исключений

существовать Распределенные делаиз Могут быть проблемы с сетью в каждой ссылкеи Бизнес-провалждатьвопрос,Эти проблемы требуют от деловых кругов распределенных дел по осуществлению отката ПВО.,Идемпотент,Три характеристики антизависания.

ненормальная ситуация

Следующее объясняет такую ​​ненормальную ситуацию с ТССдела:

Пустой откат:

Без вызова метода Try ресурса TCC вызывается двухэтапный метод Cancel. Метод Cancel должен распознать, что это пустой откат, а затем напрямую вернуть успех.

Причина в том, что в филиале «деласуществовать» не работает служба или сеть неисправна.,Вызов филиала зарегистрирован как неудачный,В настоящее время фаза Try фактически не выполняется.,После восстановления неисправности,Когда распределенные дела откатятся, будет вызван метод второй фазы —Cancel.,Это приводит к пустому откату.

Идемпотент：

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

приостановка:

Подвеска правильная Водин Распределенные дела,Второйэтап Cancel соотношение интерфейсов Try Интерфейс выполняется первым.

Причина в том, что RPC При вызове ветки дела сначала зарегистрируйте ветку дела, а затем в это время выполните вызов RPC If. RPC Вызывающая сеть перегружена, RPC По истечении таймаута TM уведомит RM о необходимости отката распределенных дел. Возможно, после завершения отката попробуйте. из RPC Запрос фактически выполняется до того, как достигнет участника.

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

• Запрос на обработку бизнеса 4из времени,Отменитьсуществовать Попробовать перед выполнением,Необходимо обработать пустой откат
• Запрос на обработку бизнеса 6из времени,Отменить повторное выполнение,Нужен Идемпотент
• Запрос на обработку бизнеса 8из времени,Выполнить после TryСуществоватьCancel,Нужно разобраться с подвеской

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

под дела барьер

существоватьпроектhttps://github.com/dtm-labs/dtmсередина,Появилась субделовая барьерная технология,использовать эту технологию,можно добиться такого эффекта,Посмотрите на схему:

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

func (bb *BranchBarrier) CallWithDB(db *sql.DB, busiCall BusiFunc) error

бизнес-разработчик,существуют, напишите свою собственную логику в busiCall,Вызовите эту функцию. Гарантия CallWithDB,существуют пустой откат, зависание и другие сценарии,busiCall не будет вызываться, если существующий бизнес вызывается повторно;,Есть Идемпотентный контроль,Гарантировано, что будет отправлено только один раз.

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

под дела барьерпринцип

под дела барьертехнологияизпринципда,существоватьместныйданные Библиотека,Создать таблицу статуса дел филиала sub_trans_barrier,Уникальным ключом является глобальное имя ветки делаid-sub-id-sub-дела (попробуйте|подтвердите|отмените)

1. Включите местные дела
2. Для текущей операции op(try|confirm|cancel) вставьте ignoreодин кусочекданныеgid-branchid-op,Если вставка не удалась,Отправить дела успешно возвращается (общий метод контроля из Идемпотент)
3. Если текущая операция отменена, то вставьте ignoreодин кусочекданныеgid-branchid-try,Если вставка прошла успешно (обратите внимание, что она прошла успешно),Затем отправьте дела и верните успех
4. Вызов бизнес-логики внутри барьера,Если бизнес возвращается успешно,Тогда подчинение дела возвращает успех, если дело возвращает неудачу;,Затем откат дела возвращает неудачу

существуют. В рамках этого механизма решаются проблемы, связанные с сетевыми аномалиями.

• пустая компенсацияконтроль–еслиTryНе выполнено,Отмена выполняется напрямую,ТакCancelвставлятьgid-branchid-tryдобьется успеха,Не следуйте логике внутри барьера,Гарантированная пустая компенсацияконтроль
• Идемпотентный контроль – ни один уникальный ключ не может быть вставлен повторно в любую ветку, что гарантирует, что он не будет выполняться повторно.
• Антиприостановочный контроль – выполняется после TryсуществоватьCancel,Таквставлятьизgid-branchid-tryнеудачный,Не выполнено,Гарантированный антиподвесочный контроль

Для ВСАГА и других механизм аналогичен из.

под дела барьеркраткое содержание

под дела барьертехнология,дляhttps://github.com/dtm-labs/dtmпервый,Его значение «существует» призвано быть простым и легким в реализации с помощью алгоритма.,Обеспечивает простой и удобный в использовании интерфейс.,существоватьпервый,Его значение «существует» призвано быть простым и легким в реализации с помощью алгоритма.,Обеспечивает простой и удобный в использовании интерфейс.,существовать с помощью этих двух предметов,Разработчики полностью освобождены от обработки сетевых исключений.

Должентехнология На данный момент необходимо сопоставитьdtm-labs/dtmдела Менеджер,В настоящее время SDK предоставляется разработчикам языков Go, Python, C# и Java. Другие языки изсдк планируются. Другое из фреймворка распределенных дел,Если предоставляется соответствующая информация о распространяемых делах.,может следовать вышеуказанным принципам,Внедрите эту технологию быстро.

dtmИмеет не только базовое ВSQLданные Библиотекаизпод дела барьер,Также реализована база ВРедис, Барьер Монгоиззидела.,Таким образом, можно объединить библиотеки данных Redis, Mongo и SQL.,и другая поддержка для движков хранения данных,сформировать глобальные дела,Обеспечивает большую гибкость.

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

У нас есть еще много статей,Через практические примеры,Начните быстро разрабатывать распределенные дела,Включает различные языковые версии,если вам интересно,Доступен：dtm Учебное пособие

Подвести итог

В этой статье представлены Распределенные делаиз Некоторыйосновная теория,Он также объясняет общую схему распределенных дел; во второй половине статьи также даются исключения для дел по причинам, классификации и элегантности и, наконец, дается работоспособный пример распределенных дел;,Продемонстрируйте ранее представленное содержание в короткой программе.

dtm-labs/dtmПоддерживаетсяTCC、XA、SAGA、сообщение второго этапа、Уведомление о лучших усилиях (сообщение второго этапа）,Обеспечивает поддержку протоколов HTTP и gRPC.,Очень легко получить доступ.

dtm-labs/dtmуже ПоддерживаетсяPython、Java、PHP、C#、Nodeждатьязыкизклиент,Видеть：SDK для каждого языка。

Приглашаем всех посетитьhttps://github.com/dtm-labs/dtmпроект,Поставьте звезду за поддержку!

Заключение

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