[Advanced Road] Надежное решение для согласованности сообщений в конечном итоге

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

предисловие

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

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

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

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

1. Транзакции надежной согласованности сообщений

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

2. Реализовать надежную схему конечной согласованности сообщений.

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

По просьбе одноклассника нарисовал картинку сам.

  • Продюсер выпускает новости
  • Подтверждение сообщения Сервер подтверждает статус сообщения
  • RocketMQ доставляет сообщения
  • Потребители потребляют сообщения

Обработать:

  • 1. Производитель отправляет сообщение на сервер подтверждения сообщений, а сервер подтверждения сообщений сохраняет сообщение и изменяет статус сообщения на ожидающее подтверждения.
  • 2. После того, как производитель отправит сообщение, выполняется локальная база данных, в случае успешного выполнения сообщение будет подтверждено, а в случае неудачи сообщение будет удалено.
  • 3. Если в данный момент это сообщение с подтверждением, сервер подтверждения сообщения обновит статус сообщения в базе данных на «отправлено» и одновременно отправит сообщение в MQ.

Если статус сообщения об обновлении в базе данных дает сбой, то создайте исключение и выйдите, а не доставляйте в MQ.

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

Обе операции должны быть успешными вместе или потерпеть неудачу одновременно.

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

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

3. Как обеспечить надежную доставку сообщений службой производителя

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

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

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

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

Если вышестоящий сервер выполняется успешно, служба надежных сообщений изменяет статус сообщения на «отправлено» и доставляет сообщение в MQ.

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

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

4. Как обеспечить надежный прием сообщений сервером-потребителем

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

Если статус сообщения всегда «отправлено» и не изменился на «завершено», это означает, что служба потребителя не была успешно обработана.В это время сервер деподтверждения может попытаться повторно доставить сообщение в MQ еще раз. , разрешая потребителю Услуга обрабатывается снова.

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

5. Обеспечьте высокую доступность механизма доставки сообщений

1. Высокая доступность RabbitMQ

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

[Расширенная дорога] Очередь сообщений — Принцип RabbitMQ (2)

Во-вторых, высокая доступность RocketMQ.

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

  • 1. Мультимастер режим

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

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

  • 2. Режим асинхронной репликации Multi-Master-Multi-Slave.

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

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

недостаток: синхронный метод асинхронной репликации может привести к потере сообщений.

  • 3. Multi-Master Multi-Slave синхронный режим двойной записи

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

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

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

3. Высокая доступность Кафки

Сама Kafka состоит из нескольких брокеров, каждый брокер является узлом; создайте тему, эту тему можно разделить на несколько разделов, каждый раздел может существовать на разных брокерах, и каждый раздел хранит часть данных.

Итак, кафка — это распределенная очередь сообщений, данные топика распределяются по нескольким машинам, и каждая машина помещает часть данных.

(Найдите картинку, чтобы показать это)

После kafka 0.8 предоставляется механизм HA, который является механизмом реплик. Kafka будет равномерно распределять все реплики раздела по разным машинам для повышения отказоустойчивости.Если брокер не работает и на нем есть лидер раздела, то Kafka автоматически переизберет нового лидера., продолжайте читать и писать нового лидера.

при записи данных: Производитель — это лидер, который записывает данные на локальный диск, а затем другие последователи активно извлекают данные из лидера. Как только все фолловеры синхронизируют свои данные, они отправят подтверждения лидеру.

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

Эпилог

Эта статья представляет собой краткое изложение распределенных транзакций. Я думаю, если вы хотите иметь более глубокое понимание, вы можете нарисовать архитектурную схему, как я, а затем попробовать создать простой сервис самостоятельно. Эффект от этого действительно хороший.Хотя большинство компаний построили свои собственные фреймворки в реальной работе, их всегда нужно постоянно обновлять ~ Однажды мы будем сами по себе, верно?

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

Категории