Поговорим о распределенных транзакциях, поговорим о решениях

база данных .NET сервер API

предисловие

В последнее время давно не вел блог, с одной стороны потому что компания в последнее время была занята, а с другой потому чтоCAPОчередной этап опытно-конструкторских работ подошёл к концу.

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

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

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

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

Эта статья не предназначена для представления этих транзакций базы данных, если вы заинтересованы, вы можете выполнить поиск соответствующей информации. Однако есть один момент, который нам нужно понять, то есть, если база данных внезапно теряет мощность при фиксации транзакции, как она восстанавливается? Зачем упоминать эту точку знаний? Поскольку ядро ​​​​распределенной системы состоит в том, чтобы справляться с различными нештатными ситуациями, что также является сложной частью распределенной системы, потому что распределенная сетевая среда очень сложна, и этот вид отказа «сбой питания» намного больше, чем сбой одна машина, поэтому мы делаем распределенную систему Это первое, что нужно учитывать при настройке системы. Этими аномалиями могут быть время простоя машины, сетевые аномалии, потеря сообщений, сообщения не по порядку, ошибки данных, ненадежный TCP, потеря сохраненных данных, другие аномалии и т. д.

Давайте продолжим разговор о ситуации, когда локальная база данных транзакций отключена, как она обеспечивает согласованность данных? Мы используем SQL Server в качестве примера, мы знаем, что мы используем базу данных SQL Server, состоящую из двух файлов, файла базы данных и файла журнала, обычно файл журнала намного больше, чем файл базы данных. Когда база данных выполняет какую-либо операцию записи, журнал должен быть записан в первую очередь.По той же причине, когда мы выполняем транзакцию, база данных сначала записывает журнал операции повтора транзакции, а затем начинает фактически работать с базой данных. log на диск, затем при внезапном сбое питания, даже если операция не завершена, при перезапуске базы данных база данных выполнит откат отмены или повторный откат в соответствии с текущей ситуацией с данными, что обеспечивает надежность данных. , консистенция.

Далее поговорим о распределенных транзакциях.

распределенная теория

Когда производительность нашей единой базы данных является узким местом, мы можем разделить базу данных. Упомянутый здесь раздел относится к физическому разделу. После разделения разные библиотеки могут находиться на разных серверах. ACID больше не может адаптироваться к этой ситуации, и в этом ACID кластерной среде почти сложно обеспечить ACID кластера, а если и удастся добиться, то эффективность и производительность будут сильно снижены.Самое главное, что этого трудно добиться.Новый раздел расширяется. В это время, если мы будем следовать ACID кластера, наша система станет очень бедной.В это время нам нужно ввести новый теоретический принцип, чтобы адаптироваться к ситуации этого кластера, то есть Принцип CAP или теорема CAP, тогда к чему относится теорема CAP?

Теорема CAP

Теорема CAP была предложена профессором Эриком Брюэром из Калифорнийского университета в Беркли, который указал, что WEB-сервисы не могут одновременно удовлетворять следующим трем свойствам:

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

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

Эта теорема верна для распределенных систем до сих пор!Почему ты это сказал?

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

Учащиеся, имеющие представление о распределенных транзакциях базы данных, должны знать 2PC, поддерживаемые базой данных, также известные как транзакции XA.

MySQL поддерживается с версии 5.5, поддерживается SQL Server 2005 и Oracle 7.

Среди них XA — это двухэтапный протокол фиксации, который делится на следующие две фазы:

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

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

Если теорема CAP верна, то она должна влиять на доступность.

Если доступность системы представляет собой сумму доступности всех компонентов, участвующих в выполнении операции. Затем в двухэтапном процессе фиксации доступность представляет собой сумму доступности в каждой задействованной базе данных. Мы предполагаем, что каждая база данных имеет доступность 99,9 % во время процесса двухэтапной фиксации, тогда, если двухэтапная фиксация включает две базы данных, результат составляет 99,8 %. Согласно формуле расчета доступности системы, исходя из 43 200 минут в месяц, доступность 99,9 % составляет 43 157 минут, а доступность 99,8 % — 43 114 минут, что эквивалентно увеличению времени простоя на 43 минуты в месяц.

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

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

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

  • В основном доступно
  • Мягкое состояние
  • В конечном итоге последовательный

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

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

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

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

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

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

Двухфазная фиксация — это решение, которое жертвует некоторой доступностью ради согласованности. Что касается реализации, в .NET можно использовать API, предоставленный TransactionScop, для программной реализации двухфазной фиксации в распределенной системе.Например, эта часть функции реализована в WCF. Однако между несколькими серверами необходимо полагаться на DTC для полной согласованности транзакций.У Microsoft есть служба MSDTC под Windows, и это более трагично под Linux.

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

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

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

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

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

  • Этап пробы в основном предназначен для тестирования бизнес-системы и резервирования ресурсов.

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

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

Например, если Боб хочет перевести деньги Смиту, идея, вероятно, будет следующей:
У нас есть нативный метод, который, в свою очередь, вызывает
1. Во-первых, на этапе «Попытка» необходимо вызвать удаленный интерфейс, чтобы заморозить деньги Смита и Боба.
2. На этапе подтверждения выполните операцию передачи удаленного вызова, и передача будет успешно разблокирована.
3. При успешном выполнении второго шага передача прошла успешно, при неудаче второго шага вызывается метод разморозки (Cancel), соответствующий удаленному интерфейсу заморозки.

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

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

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

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

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

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

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

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

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

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

недостаток:Таблица сообщений связана с бизнес-системой, если нет хорошего пакета решения, необходимо будет адресовано много работ.

4. Сообщение транзакции MQ

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

Взяв в качестве примера промежуточное ПО Ali RocketMQ, идея примерно такова:

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

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

К сожалению, у RocketMQ нет клиента .NET. Для получения дополнительных новостей о RocketMQ вы можете проверитьэтот блог

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

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

5. Модель транзакций Sagas

Модель транзакций Saga, также известная как Long-running-transaction, была предложена H.Garcia-Molina и др. из Принстонского университета, которая описывает другое решение при отсутствии двухфазной фиксации Сложные проблемы бизнес-транзакций в распределенных системах. ты сможешьздесьСм. документ, связанный с сагами.

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

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

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

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

Поскольку длинная транзакция разделена на множество бизнес-потоков, наиболее важной частью модели транзакций Sagas является рабочий процесс, или его также можно назвать диспетчером процессов (Process Manager), хотя механизм рабочего процесса и диспетчер процессов — это не одно и то же. , но Здесь их обязанности одинаковы. После выбора механизма рабочего процесса окончательный код может выглядеть так:

SagaBuilder saga = SagaBuilder.newSaga("trip")
        .activity("Reserve car", ReserveCarAdapter.class) 
        .compensationActivity("Cancel car", CancelCarAdapter.class) 
        .activity("Book hotel", BookHotelAdapter.class) 
        .compensationActivity("Cancel hotel", CancelHotelAdapter.class) 
        .activity("Book flight", BookFlightAdapter.class) 
        .compensationActivity("Cancel flight", CancelFlightAdapter.class) 
        .end()
        .triggerCompensationOnAnyError();

camunda.getRepositoryService().createDeployment() 
        .addModelInstance(saga.getModel()) 
        .deploy();скопировать код

здесьСуществует пример, связанный с C#, на который могут взглянуть заинтересованные студенты.

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

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

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

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

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

Github CAP: CAP здесь — это не теория CAP, а название решения для распределенных транзакций .NET.

Подробное введение:
woo woo woo.cn blog on.com/savor board/…
Связанные документы:
woo woo woo.cn blog on.com/savor board/…

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

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

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

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

Как вы думаете, этого достаточно? Нет, гораздо больше, чем:

  • CAP также поддерживает RabbitMQ, Kafka и другие очереди сообщений.
  • CAP также поддерживает SQL Server, MySql, PostgreSql и другие базы данных.
  • CAP Dashboard поддерживает два языка интерфейса на китайском и английском языках, маме больше не нужно беспокоиться о том, что я не понимаю
  • CAP предоставляет множество интерфейсов для расширения, что касается сериализации, пользовательской обработки, пользовательской отправки.
  • CAP основан на MIT с открытым исходным кодом, вы можете использовать его для вторичной разработки. (Не забудьте сохранить лицензию MIT)

Теперь вы думаете, что я закончил? Нет!

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

Сказав так много, во рту пересохло, ты неStarРазве не имеет смысла оказать некоторую духовную поддержку? ^_^

Портал 2:GitHub.com/точка сетевого ядра/…

Неважно, если ты не будешь звездой, я прощу тебя~

Суммировать

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

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

Если вас интересует .NET Core, вы можете подписаться на меня, я буду регулярно делиться своим опытом обучения в блоге.

Адрес этой статьи:woo woo woo.cn blog on.com/savor board/…
Блог автора:Savorboard
Добро пожаловать на перепечатку, пожалуйста, укажите источник и ссылку на видном месте

Категории