Распределенные транзакции на основе надежных схем обмена сообщениями: введение в лотерею

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

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

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

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

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

теория CAP

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

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

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

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

Предпосылкой закона CAP является P, и когда P принимается решение, решение может принять CA. Поэтому утверждение «выбери два из трех» несколько вводит в заблуждение.

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

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

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

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

анализ спроса

Функциональные требования

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

нефункциональные требования

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

решение

Сильная схема консенсуса

Организация X/Open (теперь Open Group) определяет модель распределенной обработки транзакций. Модель X/Open DTP (1994 г.) включает четыре части: прикладную программу (AP), менеджер транзакций (TM), менеджер ресурсов (RM) и менеджер коммуникационных ресурсов (CRM).

XA — это спецификация интерфейса (т. е. функция интерфейса) между ПО промежуточного слоя транзакции и базой данных, определяемая X/Open DTP. ПО промежуточного слоя транзакции использует его для уведомления базы данных о начале, завершении, фиксации, откате и т. д. Функции интерфейса XA предоставляются поставщиками баз данных.

2PC

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

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

3PC

Трехфазная фиксация, также известная как протокол трехфазной фиксации, представляет собой улучшенную версию двухфазной фиксации (2PC).

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

гибкие дела

Согласно теории BASE, система не гарантирует, что доступ к непрерывному процессу или потоку вернет последнее обновленное значение. После того, как данные успешно записаны, система не обещает немедленно прочитать вновь записанное значение и не обещает прочитать последнее значение.

Специфическая форма слабой консистенции. Система гарантирует, что система в итоге вернет значение последней операции обновления без последующих обновлений. Если исходить из того, что сбоев не происходит, на время окна несогласованности главным образом влияют задержка связи, загрузка системы и количество реплик. DNS — типичная система конечной согласованности. В инженерной практике, чтобы обеспечить доступность системы, большинство Интернет-систем преобразуют строгие требования согласованности в требования конечной согласованности и реализуют гарантии идемпотентности через систему, чтобы гарантировать окончательную согласованность данных. Однако в таких сценариях, как электронная коммерция, решение для согласованности данных отличается от обычных интернет-систем (таких как синхронизация master-slave MySQL).

Механизм компенсации: TCC

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

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

Сравнение протоколов TCC и 2PC:

• на уровне бизнес-сервисов, а не на уровне ресурсов
• Отдельного этапа подготовки нет, а операция Try имеет возможности как для работы с ресурсами, так и для подготовки.
• Операция Try может гибко выбирать степень детализации блокировки бизнес-ресурсов (определяется бизнесом).
• более высокая стоимость разработки

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

Подобно схеме надежного сообщения.

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

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

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

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

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

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

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

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

Что делать, если сообщение с подтверждением не отправляется? RocketMQ будет регулярно сканировать сообщения о транзакциях в кластере сообщений. Если он найдет сообщение «Подготовлено», он подтвердит отправителю сообщения (производителю), уменьшились ли деньги Боба или нет? Если понижение то откатиться или продолжить присылать подтверждающее сообщение? RocketMQ решит, следует ли откатиться или продолжить отправку подтверждающих сообщений в соответствии с политикой, установленной отправителем. Это гарантирует, что отправка сообщения будет успешной или неудачной одновременно с локальной транзакцией.

Если выполнение метода endTransaction завершается с ошибкой и данные не отправляются брокеру, что приводит к невозможности обновления статуса сообщения о транзакции, брокер будет периодически запускать поток обратной связи (по умолчанию 1 минута) для сканирования каждого табличный файл, в котором хранится статус транзакции, если она была отправлена ​​или отменена. Сообщение пропускается напрямую. Если оно находится в подготовленном состоянии, оно инициирует запрос CheckTransaction к производителю. Производитель вызывает DefaultMQProducerImpl.checkTransactionState() метод для обработки запроса обратного вызова брокера по времени, а checkTransactionState вызовет метод решения наших настроек транзакции, чтобы решить, следует ли откатиться. Транзакция продолжает выполняться, и, наконец, вызывается endTransactionOneway, чтобы позволить брокеру обновить окончательное состояние сообщения.

• Ошибка потребления
  Идея решения проблемы тайм-аута состоит в том, чтобы повторять попытки до тех пор, пока потребитель не обработает сообщение успешно.

• тайм-аут потребления
  Что делать, если потребление не работает? Решение, предоставленное Али: ручное решение. Вы можете подумать об этом.Согласно процессу транзакции, если Смит по какой-то причине не может добавить средства, вам нужно откатить весь процесс. Если система сообщений захочет реализовать этот процесс отката, сложность системы значительно улучшится, а ошибки могут возникнуть.По оценкам, вероятность ошибок будет намного выше, чем вероятность сбоев потребления. Это также является причиной того, что RocketMQ до сих пор не решил эту проблему.При проектировании и внедрении системы сообщений нам нужно измерить, стоит ли тратить такую ​​​​большую цену на решение такой проблемы с очень маленькой вероятностью возникновения , Это также причина, по которой всем нужно решать сложные проблемы Место для размышлений.

Введение в Лоттор

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

Структура лото

Лото состоит из трех частей:

• Lottor Server
• Lottor Client
• Lottor UI

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

Функции

Производственная часть делится на три этапа:

• Для предварительной отправки сообщения сначала будет собрана группа транзакций потребителя (одно или несколько сообщений о транзакциях), которая будет отправлена ​​на сервер Lottor.预发送.
• Выполнить локальную транзакцию: после предварительной отправки будет выполнена локальная транзакция.
• Отправить подтверждающее сообщение: в соответствии с результатом выполнения локальной транзакции подтверждающее сообщение отправляется асинхронно. Если в локальной транзакции возникает исключение, локальная транзакция откатывается, а информация об исключении фиксируется и отправляется на сервер Lottor. Это состояние также сохраняется локально (периодически удаляется).

Лото сервер:

• Получение сообщения о предварительной фиксации: после получения сообщения о предварительной фиксации сохраните сообщения о транзакциях в группе транзакций отдельно со статусомpre-commit.
• Получение подтверждающего сообщения: статус подтвержден, статус соответствующей группы транзакций будет изменен, и сообщение будет отправлено соответствующему потребителю (асинхронная реализация MQ), а статус сообщения транзакции будет помечен какunconsumed. В противном случае откат состояния только изменяет состояние группы транзакций (периодически удаляется).
• Проверьте статус ранее отправленного сообщения: статусpre-commitДля сообщений группы транзакций Lottor Server будет периодически проверять отправителя.
• Проверьте статус сообщения о транзакции: статусunconsumed(обычно 4 часа), Lottor Server будет регулярно проверять потребителя.

Потребитель:

• Получение сообщений о транзакциях: подпишитесь на соответствующие разделы.После завершения потребления ACK будет отправлено на сервер Lottor асинхронно.Если потребление не будет выполнено, на сервер Lottor будет возвращено исключение. Состояние потребления также сохраняется локально (периодически удаляется).

Постоянство клиента Lottor обеспечивает интерфейс SPI, который можно динамически указать в конфигурации. В настоящее время поддерживаются: JDBC, Redis, MongoDB и файловая система.

Механизм сигнализации и компенсация потребления

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

Применимая сцена

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

Скриншот проекта

Суммировать

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

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

Ссылаться на

1. Поговорим о распределенных транзакциях, поговорим о решениях
2. Распределенные транзакции — двухэтапная фиксация и трехэтапная фиксация
3. О распределенных транзакциях, двухфазном протоколе фиксации, трехфазном протоколе фиксации
4. Принцип и практика распределенной открытой системы обмена сообщениями (RocketMQ)
5. Принцип и реализация распределенной транзакции TCC: введение принципа
6. Распределенные транзакции говорят о транзакциях TCC