Возможности RocketMQ и интервью (ниже)

Восемь, стратегия активной синхронизации: синхронная двойная запись, асинхронная репликация.

8.1 Режим Multi-Master-Multi-Slave, асинхронная репликация

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

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

• Недостатки: Мастер не работает, диск поврежден, небольшое количество сообщений будет потеряно.

8.2 Режим Multi-Master-Multi-Slave, синхронная двойная запись

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

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

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

9. Стратегия очистки новостей

9.1 Асинхронная очистка (ASYNC_FLUSH)

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

Когда есть карта RAID, тест диска SAS 15000 RPM записывает файлы последовательно, и скорость может достигать около 300 МБ в секунду, в то время как сетевые карты онлайн обычно представляют собой гигабитные сетевые карты, и скорость записи на диск значительно выше, чем у скорость входа в сеть данных.Возможно ли это сделать?При записи памяти пользователь возвращается и фоновый поток сбрасывает диск?

Поскольку скорость диска больше скорости сетевой карты, процесс очистки диска определенно может идти в ногу со скоростью записи сообщения. Если в это время давление в системе слишком велико, сообщения могут накапливаться.В дополнение к записи IO, есть также чтение IO.В случае задержки чтения с диска, Приведет ли это к переполнению системной памяти?Ответ отрицательный по следующим причинам: а) При записи сообщений в pagecache, если памяти не хватает, попытаться отбросить чистые страницы, чтобы освободить память для новых сообщений.Стратегия LRU. б) Если чистых страниц недостаточно, запись в кэш страниц в это время будет заблокирована, и система попытается сбросить некоторые данные, примерно по 32 страницы каждый раз, чтобы найти больше чистых страниц.

Таким образом, ситуации переполнения памяти не возникнет.

9.2 SYNC_FLUSH

К тому времени, когда он возвращает статус успеха, сообщение уже записано на диск.

После того, как сообщение записано в pagecache памяти, немедленно уведомляется поток сброса, после завершения сброса возвращается статус успешной записи сообщения.

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

1. После записи в pagecache поток ожидает и уведомляет поток очистки о необходимости очистки диска.
2. После того, как поток сброса сброшен, разбудите ожидающий интерфейсный поток, который может быть пакетом потоков.
3. Фронтенд ждет, пока поток успешно вернет пользователя обратно.

10. Сохранение сообщения

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

Одиннадцать, хранилище сообщений

11.1 Модель хранилища RocketMQ:

Хранение сообщений RocketMQ осуществляется при сотрудничестве ConsumeQueue и CommitLog.В ConsumeQueue хранится лишь небольшой объем данных, а тело сообщения читается и записывается через CommitLog.

Журнал фиксации:Это тело хранилища тела сообщения и метаданных.ConsumeQueue устанавливается для CommitLog, и каждая ConsumeQueue соответствует MessageQueue (в концептуальной модели), поэтому, пока существует журнал фиксации, очередь потребления все еще может быть восстановить, даже если данные потеряны.Потребление очереди:Это логическая очередь сообщений, в которой хранится начальное смещение очереди в CommitLog, размер журнала и хэш-код MessageTag. Каждая очередь в каждой теме имеет соответствующий файл ConsumerQueue. Например, в теме есть три очереди, и индекс сообщения в каждой очереди будет иметь номер. Номер начинается с 0 и увеличивается вверх. И из этой концепции смещения сайта, с этой концепцией, вы можете определить очередь для ситуации потребления на стороне Потребителя.

• Брокерская сторона RocketMQ не несет ответственности за отправку сообщений и хранит сообщения независимо от того, потребляют ли их потребители или нет. Тот, кто хочет использовать сообщение, отправляет запрос брокеру на получение сообщения, и запись потребления сохраняется потребителем. RocketMQ предоставляет два метода хранения для хранения записей о потреблении: один хранится на сервере, где находится потребитель, а другой — на сервере брокера. Пользователи также могут самостоятельно реализовать соответствующий интерфейс хранения прогресса потребления.

• По умолчанию при использовании кластера (CLUSTERING) записи сохраняются на стороне брокера, а при широковещательном потреблении (BROADCASTING) записи потребления сохраняются локально.

• RocketMQ использует Topic для управления сообщениями различных приложений. Для производителя для отправки сообщения необходимо указать тему сообщения, для потребителя после запуска необходимо подписаться на соответствующую тему, после чего можно потреблять соответствующее сообщение. Тема — это логическое понятие. С точки зрения физической реализации тема состоит из нескольких очередей. Преимущество использования нескольких очередей заключается в том, что можно распределять хранилище брокера и повышать производительность системы.

• В RocketMQ, когда производитель отправляет сообщение брокеру, ему необходимо указать, в какую очередь отправлять.По умолчанию производитель отправляет сообщение в каждую очередь путем опроса (все очереди под брокером объединяются в список для опрос).

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

11.2 Возможности хранилища RocketMQ:

Принцип нулевого копирования: Потребитель потребляет сообщения с использованием нулевого копирования.Нулевое копирование включает следующие два метода:

1. Используйте метод mmap + write
   • Преимущества: даже при частых вызовах передача файлов небольшими блоками очень эффективна.
   • Недостатки: метод прямого доступа к памяти нельзя использовать должным образом, он будет потреблять больше ресурсов процессора, чем sendfile, контроль безопасности памяти сложен, и необходимо избегать проблемы сбоя JVM.
2. Использовать метод sendfile
   • Преимущества: можно использовать DMA, меньшее потребление ЦП, высокая эффективность передачи больших файлов и отсутствие новых проблем с безопасностью памяти.
   • Недостатки: Небольшие блочные файлы менее эффективны, чем в режиме mmap, и могут передаваться только в режиме BIO, а NIO использовать нельзя. RocketMQ выбрал первый метод, метод mmap+write, потому что есть необходимость в передаче данных небольшими блоками, эффект будет лучше, чем sendfile.

11.3 Структура хранения данных RocketMQ:

12. Накопление новостей

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

Поддерживает накопление сообщений на уровне 1 миллиарда и не влияет на производительность из-за накопления сообщений.
Если сообщения накапливаются и производительность значительно падает, сначала проверьте консоль RocketMQ, проверьте состояние потребителя, чтобы найти узел снижения производительности, проверьте информацию о стеке, а затем проверьтеConsumeMessageThreadсостояние и стек.

13. Надежность сообщения

Гарантия надежности производителя: Производитель возвращает SendResult после отправки сообщения.Если isSuccess возвращает true, это означает, что сообщение было подтверждено для отправки на сервер, получения и сохранения сервером. Весь процесс отправки является синхронным процессом.

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

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

14. Фильтрация сообщений

Потребитель может фильтровать сообщения в соответствии с тегом сообщения (Tag), чтобы гарантировать, что Потребитель в конце получит только отфильтрованные типы сообщений. Фильтрация сообщений выполняется на стороне сервера очереди сообщений RocketMQ.

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

15. Срежьте пики и заполните долины

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

Процесс обработки seckill выглядит следующим образом:

1. Пользователи инициируют массовые запросы seckill к системе обработки бизнес-данных seckill.
2. Система обработки seckill отправляет запросы, соответствующие условиям seckill, в очередь сообщений RocketMQ в соответствии с логикой обработки seckill.
3. Нисходящая система уведомлений подписывается на сообщения, связанные с RocketMQ seckill, в очереди сообщений, а затем отправляет сообщения об успешном завершении seckill соответствующим пользователям.
4. Пользователь получает уведомление об успешном выполнении seckill.

Синхронизация кэша для крупномасштабных машин

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