Брат Хуа имеет честь участвовать в деятельности Nuggets по отправке периферийных устройств. Спасибо за вашу постоянную поддержку мне и Nuggets. Оставьте сообщение в области комментариев ниже и отправьте случайные подарки~
Программное обеспечение для лотереи:лотерейное программное обеспечение, введите в порядке комментариев
Розыгрыш призов:Случайным образом выберите двух друзей и получите 1 значок Nuggets
предисловие
Прошел почти месяц с момента последнего поста, а в последнее время я был занят всякими вещами.Мне посчастливилось получить официальную квалификацию на событие [Бесплатное приложение для Nuggets Periphery] от Nuggets в начале месяца , Это не для того, чтобы послать пользу моим друзьям сегодня В конце концов, ваше счастье - моя мотивация, ахахахаха.
После долгих размышлений я, наконец, решил сегодня поделиться с вами некоторыми знаниями, связанными с распределенными операциями, и на простых примерах рассказать о связанных решениях для распределенных транзакций.Это также часто задаваемый вопрос в интервью.После изучения этой статьи, у вас будет2PC,TCC,本地消息表,最终一致性,最大努力通知И соответствующая сцена имеет лучшее понимание.
единая системная транзакция
Оставим здесь раздачу, просто поговорим о транзакции, что такое транзакция? Я думаю, каждый может сказать что-то, типа атомарности, непротиворечивости, изолированности, долговечности, которые чаще всего слышатся, то есть ACID-характеристики.Как это объяснить официальными словами?Википедия использует пример переноса.Пояснение,счет А переводит 100 юаней на счет B. Этот бизнес включает в себя две операции: счет A минус 100 юаней и счет B плюс 100 юаней.Для системы, которая поддерживает транзакции, независимо от ситуации, необходимо обеспечить выполнение этих двух операций.Он может быть завершена, но вычет со счета А не может быть успешным, а счет Б не увеличивает деньги.
Вот обзор ACID с небольшим партнером Nuggets уровня 1 и ниже:
- Атомарность:Транзакция выполняется целиком, а операции, содержащиеся в транзакции, либо не выполняются, либо выполняются все. То есть в сценарии переноса вычитание счета A и увеличение счета B должны быть выполнены успешно или все не удастся.
- Последовательность:Данные должны удовлетворять ограничениям целостности для перехода из одного непротиворечивого состояния в другое. То есть в сценарии передачи нет вычета 100 юаней со счета А, но нет увеличения счета Б.
- Изоляция:Когда несколько транзакций выполняются одновременно, они не мешают друг другу.
- Прочность:После завершения транзакции изменения в базе данных будут сохранены навсегда, и другие операции после этого не повлияют на результаты совершенной транзакции.
Далее, давайте используем общий сценарий оплаты, чтобы поговорить о том, как выглядит транзакция в автономной системе.
Теперь, друзья мои, я считаю, что все часто покупают онлайн. Вы когда-нибудь задумывались о том, как работает система торгового центра после того, как мы завершим оплату, чтобы завершить модификацию заказа, вычет инвентаря, вычет купона и уведомление о сообщении?, ведение журнала и так далее. На картинке выше распространенный способ записи в автономной системе.За одну транзакцию выполняются следующие операции:
- Пользователь инициирует и завершает платеж
- Обратный звонок об оплате
- открытая транзакция
- Изменение статуса заказа
- Вычет купона
- протоколирование
- уведомление
- совершить транзакцию
В этом процессе мы использовалидела, при выходе из строя одной из ссылок система откатывает завершенные операции, например, после сбоя записи в логе операции первых двух шагов (изменение статуса заказа, списание купона) будут откатываться до состояния до модификации, таким образом Обеспечить правильность работы системы.
Несмотря на четкую логику и простую реализацию вышеуказанного метода написания, он также имеет очевидные недостатки и высокую связанность кода, например, если позже добавляется новая интегральная система, ее необходимо продолжать добавлять к исходной логике, кроме того, этот режим не подходит для высокой параллелизма.Для бизнес-сценариев, как решить эту проблему, которая является распределенной транзакцией, о которой мы поговорим сегодня.
Распределенная транзакция
Когда дело доходит до распределенных систем, первое впечатление, которое у вас возникает, это: вау, ты такой высокий, давай посмотрим, какую острую курицу тебе нужно писать каждый день. Как мы должны понимать распределенные транзакции, которые являются важными аспектами распределения? Как мы все знаем об автономной системе, каждый модуль последовательно оперирует локальной базой данных, чтобы завершить добавление и изменение данных, и откатывает все операции при возникновении исключения. Распределенные транзакции на самом деле похожи, сначала посмотрите на следующую картинку:
В распределенной системе каждый модуль исходной автономной системы будет разобран на независимые системы и развернут на разных серверах.Каждая подсистема может работать независимо, не полагаясь на другие подсистемы.
После того, как пользователь завершает платеж, весь процесс в основном такой же, как и в автономной системе: система заказов сначала получает уведомление об успешном платеже, а при работе с базой данных также информирует все остальные подсистемы о начале работы. После того, как другие подсистемы получат сообщение, завершат свою собственную бизнес-обработку и, наконец, запишут в базу данных. Если все подсистемы успешно завершат свою работу, весь процесс завершится идеально, но если подсистема выйдет из строя из-за дефекта или тайм-аута сети, например, модуль сообщений не работает, пользователь не будет уведомлен вовремя, что приведет к сбою. всего бизнеса.Полностью замкнутый цикл, что нам тогда делать? Собственно, здесь используетсяРаспределенная транзакция.
Затем проанализируйте несколько часто используемых решений для распределенных транзакций.
2PC
2PCдаTwo-phase commit protocolАкроним, переводыдвухэтапная фиксация, что такое двухфазный коммит? Как следует из названия, это управление фиксацией транзакции в два этапа (этап подготовки,этап фиксации), в 2PC также вводятся две важные роли, одна — координатор транзакции, а другая — участник. Для простого примера в нашем бизнесе мы должны столкнуться с тем, что для выполнения определенного требования нам нужно добавить две части данных в две базы данных (основную базу данных и подбазу данных), В настоящее время нам нужно выполнить это в одной транзакции эти две операции.
Если вы не понимаете, не волнуйтесь.Далее брат Хуа будет использовать схему, чтобы постепенно разобрать процесс.
На этапе подготовки координатор транзакции отправляет запрос на подготовку всем участникам, чтобы узнать, может ли быть выполнена операция фиксации.Участник получает запрос и возвращает результат подготовки координатору.Полная блок-схема выглядит следующим образом.
- этап подготовки
- этап фиксации
Когда координатор получает сообщение обратной связи, полученное всеми участниками, «подготовка прошла успешно», координатор уведомит каждого участника о переходе к фазе фиксации; в это время узел-участник завершает операцию и освобождает ресурсы, занятые во время всей транзакции, и Инициируйте обратную связь [Отправить успешно] координатору; координатор, наконец, завершит транзакцию.
Здесь возникает другая ситуация:На этапе подготовки, если участник возвращает ошибку подготовки, координатор уведомит всех участников и попросит каждого участника выполнить операцию отката.После успешного отката участник уведомит координатора [откат успешен].
- этап подготовки
- этап фиксации
Посмотрев на приведенные выше фотографии, мы знаем, что,2PC может гарантировать, что, когда все участники на первом этапе готовы к успеху (отказу), координатор завершает уведомление о отправке транзакции (откате) каждой базе данных (участнику), и, наконец, каждая роль сотрудничает для завершения отправки всего распределенного сделка.
У серьезных друзей возникнет вопрос,Что делать, если участник не отправил заявку на этапе отправки?Поскольку на этапе подготовки есть две ситуации, на этапе подачи она будет разделена на две ситуации и обсуждена отдельно:
- Если вторая стадиясовершить транзакцию: Непрерывно повторяя попытки, пока все участники не завершат отправку, если она все еще не может быть успешно выполнена в конце, в нее можно активно вмешаться только вручную...
- Если вторая стадиятранзакция отката: Также будут продолжаться повторные попытки, пока все участники не завершат откат, иначе участники на первом этапе всегда будут заблокированы.
TCC
TCCВесь процесс разделен на три этапа: попробовать, подтвердить, отменить,
- Пробный этап: этот этап посвящен обнаружению ресурсов каждой службы и блокировке или резервированию ресурсов.
- Подтвердить этап: Этот этап относится к операции подтверждения, которая фактически была выполнена.
- Отменить этап: если при выполнении бизнес-метода службы возникает ошибка, успешно выполненная бизнес-логика будет отброшена.
Если взять пример перевода в качестве примера, при переводе денег между банками должны быть задействованы распределенные транзакции между двумя банками.Чтобы перевести 100 юаней из банка А в банк Б, весь процесс выглядит следующим образом:
- Пробный этап: заморозить банковский счет А на 100 юаней и заранее увеличить банковский счет Б на 100 юаней;
- Стадия ПОДТВЕРЖДЕНИЯ: выполнение фактической операции перевода средств на банковский счет A, увеличение средств на банковских счетах B;
- Стадия отмены: если какая-либо операция банка не удалась, то вам нужно откатиться, чтобы компенсировать это, то есть, если банковский счет A был вычтен, но средства банковского счета B не удалось, то вы должны добавить средства банковского счета A. .
TCC более навязчива для бизнеса и тесно связана с бизнесом., если честно, эта схема редко используется людьми, но есть и сценарии, где она применима.
более подходящая сцена: Требования к согласованности чрезвычайно высоки.Например,распространенный сценарий-это категория капитала.Вы можете использовать решение TCC,чтобы самостоятельно написать много бизнес-логики,чтобы судить,каждая ссылка в транзакции выполняется нормально,и выполнить откат эксплуатация в случае возникновения нештатной ситуации.
Но вообще говоря, откат транзакции в этой схеме сильно зависит от написанного от руки кода для отката и компенсации, что приведет к огромному коду компенсации, и его не рекомендуется использовать легко.
Локальная таблица сообщений
Механизм заключается в добавлении таблицы сообщений в базу данных каждой системы.После работы бизнес-таблицы этой системы (например, шаг 1/5) будет добавлена и сохранена в сообщении новая запись сообщения, связанная с бизнесом. table (Как и в шаге 2 и шаге 6), целостность всей распределенной транзакции окончательно гарантируется по всей ссылке.
Как показано на рисунке ниже, чтобы гарантировать, что все операции системы A и системы B выполняются в одной транзакции, мы сохраним уникальную идентификационную информацию (например, идентификатор) данных в таблице сообщений после вставки бизнес-данных. в системе A. Запись должна быть подтверждена, а затем система A уведомляет MQ, затем система B получит сообщение в MQ и начнет свою собственную обработку бизнес-логики, то есть сначала вставит данные бизнес-таблицы, а затем вставит сообщение данные таблицы.
Следует обратить внимание на одну вещь: когда система B вставляет данные таблицы сообщений, ей необходимо обратить внимание на некоторые характеристики MQ, то есть на проблему повторного потребления.Поэтому, когда система B вставляет таблицу сообщений, она должна убедиться, что операция выполняется в первый раз, что можно сделать через бизнес-таблицу системы B. в уникальном идентификаторе, чтобы определить.
Затем система B перезванивает системе A, чтобы сообщить ей, что работа этой системы прошла успешно, и после того, как система A получит сообщение, она изменяет состояние таблицы сообщений системы A на завершенное состояние, и на этом вся раздача заканчивается.
Чтобы убедиться, что система B может нормально получать сообщения, система A может добавить операцию опроса для опроса всех сообщений, которые должны быть подтверждены каждую 1 секунду, чтобы проверить, не был ли получен ответ в течение заданного времени (например, 1 минуты). или откатиться.
Недостатком этой схемы является то, что она сильно зависит от таблицы сообщений базы данных, и в параллельных сценариях будут узкие места, и система должна допускать несогласованность данных в течение определенного периода времени.
транзакция сообщения
Этот режим предназначен для выполнения распределенных транзакций через ПО промежуточного слоя сообщений, такое как RocketMQ.
Сначала система A отправит MQ подготовленное сообщение. Этот тип сообщения невидим для подписчиков, поэтому оно не будет использовано; после успешной отправки сообщения система A продолжит выполнение локальной транзакции. выполняется нормально, будет отправлено подтверждающее сообщение, информирующее mq о том, что выполнение локальной транзакции завершено, и система B может быть уведомлена о завершении потребления. RocketMQ будет опрашивать сообщения в подготовленном состоянии.Если сообщение с подтверждением не будет получено в течение определенного периода времени, он предпримет инициативу для выполнения обратной проверки, чтобы подтвердить, успешно ли получено сообщение.
Когда шаг 3 будет завершен, система B получит сообщение MQ в это время и начнет выполнять локальную транзакцию.После завершения выполнения сообщение будет использовано; если система B имеет исключение при выполнении локальной транзакции, можно принять несколько решений.Решить проблему, например, координировать повторную передачу MQ, информировать систему A о повторной передаче, добавить другое промежуточное программное обеспечение (например, zk) и т. д.
Кроме того, обратите внимание на проблему идемпотентности, когда система B потребляет сообщения, которая аналогична локальной таблице сообщений и здесь повторяться не будет.
уведомление о лучших усилиях
Самый интуитивный способ сказать об этом плане таков: я сделал все возможное, чтобы уведомить другие системы. Если это все еще не может быть выполнено, то у меня нет выбора. В настоящее время я могу вмешаться только вручную. Это решение подходит для ситуаций, когда требования к распределенным транзакциям не являются строгими, например, логирование и SMS-уведомление об успешных покупках.
Для системы A давление этой схемы относительно невелико, пока она завершает локальную транзакцию и отправляет сообщение в MQ, даже если транзакция завершается, остальное будет передано [Службе уведомлений Best Effort] для координации. , Усилия по уведомлению службы не получили обратной связи от системы B, и может быть выполнен определенный порог (вроде 20 раз), когда порог превышен, ручное вмешательство может быть уведомлено или отменено напрямую.
Процесс выглядит следующим образом:
- Система А завершает выполнение локальной транзакции и отправляет сообщение в MQ;
- Сделайте все возможное, чтобы уведомить службу о необходимости использования MQ, а затем записать его в базу данных для записи или поместить в очередь памяти, а затем вызвать интерфейс системы B;
- Если система B завершается успешно, транзакция завершается нормально, однако, если система B терпит неудачу, служба уведомлений с наилучшими усилиями попытается снова вызвать систему B, повторив это N раз, и, наконец, сдастся или уведомит работника в случае неудачи.
Суммировать
В этом разделе объясняется несколько распространенных схем распределенной обработки транзакций, которые в практических приложениях следует выбирать разумно в соответствии с их собственным бизнесом.
Например, 2PC применим к уровню базы данных.TCC относится к идее компенсационной транзакции, которая заключается в завершении транзакции на бизнес-уровне, но код является более интрузивным и его следует выбирать тщательно.Последние три типа локальных сообщений, сообщения о транзакциях и уведомления о максимальных усилиях имеют общую идею: если вы хотите обеспечить согласованность в конечном итоге, они подходят для сценариев, которые не чувствительны ко времени, а требования к распространению не являются строгими.
Наконец, я оставляю вопрос для моих друзей. Какие решения вы использовали в своем ежедневном развитии? Вы можете поделиться с вами подводными камнями в области комментариев. Наконец, два друга будут случайным образом выбраны для отправки сегодняшних подарков Nuggets.