Микросервисы выступают за разбиение сложных монолитных приложений на несколько сервисов с простыми функциями и слабосвязанными сервисами, но при этом будет введена проблема распределенных транзакций между несколькими сервисами.
Как мы все знаем, база данных может реализовывать локальные транзакции, то есть в той же базе данных может быть гарантирована атомарность транзакций, то есть все успехи или неудачи.В предыдущей статье также был написан простойРешения для транзакций с несколькими источниками данных(аналогично 2PC)
Однако текущая система часто использует архитектуру микросервисов, а бизнес-система имеет независимую базу данных, поэтому существует требование транзакции между несколькими базами данных, что называется «распределенной транзакцией».
Обычно используемые решения для таких проблем:
- 2PC/3PC (протокол двухфазной фиксации/протокол трехфазной фиксации)
- ТСС (компенсированный)
- Распределенная транзакция на основе надежной службы сообщений (асинхронный гарантированный тип)
Общий процесс
Распределенная транзакция на основе надежной службы сообщений, я реализовал промежуточное ПО для распределенных транзакций на основе rabbitmq,shine-mq
В начале изначально предполагалось инкапсулировать работу mq для простоты использования, а последующие итерации добавили функцию распределенных транзакций. Давайте представим это промежуточное ПО:
- Перед тем, как сервис А обработает задачу А, он сначала отправляет запрос Координатору (Нести чек обратно) запись, указывающая, что эта распределенная задача должна быть запущена
- Координатор отвечает службе A после сохранения записи о подготовке.
- После того, как служба A получит подтверждение, служба A обработает задачи A, после успешной отправки готовой записи координатор удалит соответствующую предыдущую запись и постоянство готово к записи и завершению сообщения.
- После того, как служба A получит готовую запись и ответ о сохранении сообщения, она может отправить сообщение промежуточному программному обеспечению сообщений, которое можно установить для rabbitmq.
setPublisherConfirms(true)и реализоватьsetConfirmCallbackОбратный вызов для реализации службы постоянного ответа промежуточного программного обеспечения сообщений A. После этого сервис А может удалить предыдущую готовую запись и обработать другие задачи. - Промежуточное ПО для сообщений (rabbitmq может обеспечить высокую доступность за счет зеркального отображения очередей) может доставлять сообщения в службу B после определения того, что сообщение помещено на диск.
- Служба B получает сообщение и успешно обрабатывает задачу B. Служба B возвращает промежуточному программному обеспечению сообщения подтверждающий ответ, сообщая промежуточному программному обеспечению сообщений, что сообщение было успешно обработано.На этом этапе распределенная транзакция завершена.
Выше описан весь процесс После того, как служба А завершит задачу А, будет определенная разница во времени между завершением выполнения задачи Б. В течение этой разницы во времени вся система находится в состоянии несогласованности данных, но эта кратковременная несогласованность допустима, поскольку через небольшой промежуток времени система может снова поддерживать непротиворечивость данных, что удовлетворяет теории BASE.
БАЗОВАЯ теория:
- BA: базовый доступный
- S: мягкое состояние: состояние разных копий одних и тех же данных не обязательно должно быть согласованным в реальном времени.
- E: Непротиворечивость в конечном итоге: Непротиворечивость в конечном итоге Статус различных копий одних и тех же данных может не обязательно быть непротиворечивым в режиме реального времени, но его согласованность должна быть гарантирована по прошествии определенного периода времени.
ненормальная ситуация
Вышеупомянутый процесс является идеальным, но в реальной среде будет много непредвиденных ситуаций, например, если обработка задачи А не удалась, она должна войти в процесс отката.
Поскольку исключение задачи А может быть непосредственно перехвачено службой А, после отката исключения запись о подготовке удаляется.После удаления службы А можно считать, что откат завершен, и можно выполнять другие действия. .
Если сообщение не доставлено промежуточному программному обеспечению сообщений, служба B не действует. В этот момент система снова находится в согласованном состоянии, потому что ни задача A, ни задача B не выполняются.
Координатор предоставляет интерфейс, который может быть реализован сам по себе.Моей реализацией по умолчанию является использование Redis. Если вы хотите использовать другие методы, вы можете реализовать интерфейс самостоятельно.
На картинке выше видно, что при отправке готовой записи произошел сбой. В это время служба А получит исключение или не получит ответа.В это время можно напрямую откатить предыдущую задачу А. При откате задачи А будет запущена операция удаления готовности. Точно так же, если исключение возникает при отправке prepare, не имеет значения, не выполнила ли служба A задачу в это время.
Проанализировав некоторые ситуации между службой A, координатором и промежуточным программным обеспечением сообщений, теперь проанализируйте некоторые особые ситуации между промежуточным программным обеспечением сообщений и службой B.
После того, как сообщение будет успешно опубликовано в промежуточном программном обеспечении сообщений, служба A может заниматься своими делами, а промежуточное программное обеспечение сообщений гарантирует, что сообщение может быть успешно доставлено службе B. Это гарантия надежности промежуточного программного обеспечения сообщения в случае доставки сообщения.Специфический процесс заключается в том, что промежуточное программное обеспечение сообщения входит в состояние ожидания блокировки после доставки сообщения в нижестоящую систему.Нижестоящая система немедленно обрабатывает задачу и отправляет сообщение к сообщению после обработки задачи.Промежуточное ПО возвращает ответ. После того, как промежуточное программное обеспечение сообщений получает ответ с подтверждением, оно считает, что транзакция завершена! Если сообщение потеряно во время процесса доставки или ответ подтверждения сообщения потерян на обратном пути, промежуточное программное обеспечение сообщения будет повторно доставлено после ожидания тайм-аута ответа подтверждения, пока нижестоящий потребитель не вернет успешный ответ потребления.
Вы можете установить количество повторных попыток сообщения и временной интервал между ними, если это не удается все время, будет использоваться очередь недоставленных сообщений. В частности, посмотрите на следующий рисунок:
Когда сообщение не может быть обработано в обычном режиме, оно будет доставлено в очередь недоставленных сообщений, если оно превысит установленный порог повторных попыток.Обмен по умолчанию и routeKey очереди недоставленных сообщений@DistributedTransзначение установлено в .
Эта нештатная ситуация обрабатывается потреблением сообщений в очереди недоставленных сообщений (можно настроить напоминания по СМС или электронной почте, ручное вмешательство), а откат сервиса А здесь пока не реализован, т.к. сервис А заранее предоставляет интерфейс отката , что, несомненно, добавляет дополнительные затраты на разработку бизнес-системы. Целью проектирования бизнес-системы является минимизация сложности системы при условии обеспечения производительности, чтобы снизить затраты на эксплуатацию и обслуживание системы.
Идеи дизайна
Наконец, разберитесь с идеями дизайна всего промежуточного программного обеспечения.
Некоторые исключения были проанализированы выше.Для атомарности нижестоящих служб и промежуточного программного обеспечения сообщений мы можем обеспечить надежность доставки промежуточного программного обеспечения сообщений (то есть режим ACK, сбой или неполучение ответа на повторную попытку). Затем нам нужно реализовать распределенные транзакции, а остальное — обеспечить атомарность задач, выполняемых вышестоящим сервисом, и доставку сообщений в промежуточное ПО сообщений.
В настоящее время обычно используются две схемы: синхронная и асинхронная связь. Из предыдущей диаграммы последовательности видно, что между вышестоящей системой и промежуточным программным обеспечением сообщений используется асинхронная связь, то есть, когда вышестоящая служба отправляет сообщение, она может делать другие вещи, и тогда отправка и откат полностью передан промежуточному программному обеспечению Message для завершения, и полностью доверять промежуточному программному обеспечению сообщений, что оно должно быть в состоянии правильно завершить фиксацию или откат транзакции. Это в основном для улучшения параллелизма системы.Кроме того, бизнес-система напрямую взаимодействует с пользователями, и особенно важен пользовательский опыт.Поэтому этот асинхронный метод связи может значительно сократить время ожидания пользователей.
Rabbitmq фактически предоставляет механизм транзакций, который реализуется с помощью txSelect(), txCommit() и txRollback().В ходе захвата тестового пакета обнаруживается, что Tx.Commit-Ok отправляется сразу после Tx.Commit, а временной интервал между ними будет относительно долго. Простой тест может достигать 300 мс, что занимает очень много времени. Поэтому я не стал использовать этот способ, а ввел Coordinator (координатор) для достижения.
Существует также более важный демон (поток демона), который должен обрабатывать некоторые записи об ошибках тайм-аута в координаторе (аналогично механизму запросов тайм-аута Rocketmq). Следовательно, в дополнение к реализации обычных бизнес-процессов служба А также должна предоставлять интерфейс для запросов транзакций, который координатор должен вызывать, чтобы убедиться, что служба А не работает при выполнении задач. Когда есть тайм-аут подготовки, он инициирует доступ к этому интерфейсу обратной связи, который возвращает три результата:
- Отправить Опубликовать это сообщение
- Откат Непосредственно удалить сообщение
- Обработка Продолжайте ждать и сбросьте время.
Сообщение о готовности к тайм-ауту принимается напрямую и отправляется промежуточному программному обеспечению сообщений, поскольку до тех пор, пока сообщение о готовности сохраняется для координатора, это означает, что задача службы А выполнена.
Это обеспечивает атомарность вышестоящих сервисов и ПО промежуточного слоя сообщений (подробности см.Распределенные транзакции: сообщения отправляются надежно), а затем благодаря надежной доставке промежуточного программного обеспечения сообщений в сочетании с нижестоящими службами распределенная транзакция завершается.
Если это было полезно для вас, то, пожалуйста, помогите мне, поставив звезду ^.^
адрес гитхаба:GitHub.com/7/Да, нет...
GithubНе скупитесь на свою звезду ^.^Более захватывающе нажмите на меня