На общие вопросы интервью об очередях сообщений отвечают в сочетании с их собственными проектами... Лучше всего иметь проект с промежуточным программным обеспечением для очередей сообщений.Этот проект использует RocketMQ
контур
Что такое очередь сообщений? Какова основная функция очереди сообщений?
Мы можем сравнить очередь сообщений сконтейнер для хранения сообщений, когда нам нужно использовать сообщение, мы можем извлечь его для собственного использования. Очередь сообщений является важным компонентом в распределенной системе.Основной целью использования очереди сообщений является передачаАсинхронная обработка повышает производительность системы и отсечение пиков, а также снижает связанность системы..
- Асинхронная обработка: асинхронные неосновные процессы для повышения производительности системного отклика.
-
Разделение приложений:
- Система не является сильно связанной, и получатели сообщений могут быть добавлены по желанию без изменения кода отправителя сообщения. Успех отправителя сообщения не зависит от получателя сообщения (например, некоторые банковские интерфейсы нестабильны, но звонящему не нужно полагаться на эти интерфейсы)
- Успех отправителя сообщения не зависит от получателя сообщения (например, некоторые банковские интерфейсы нестабильны, но звонящему не нужно полагаться на эти интерфейсы)
-
окончательная согласованность: Консистентность в конечном счете не является необходимой функцией очередей сообщений, но вы действительно можете полагаться на очереди сообщений, чтобы выполнять действия с согласованностью в конечном счете.
- Сначала напишите сообщение, а затем обработайте его, а затем измените статус сообщения после завершения операции. Механизм компенсации задачи синхронизации обеспечивает надежную отправку и получение сообщений и надежное выполнение бизнес-операций.Обратите внимание на дизайн повторения сообщений и идемпотентность
- Все очереди сообщений, которые не гарантируют 100%-ную потерю сообщений, теоретически не могут обеспечить окончательную согласованность.
- транслировать: нужно только заботиться о том, доставлено ли сообщение в очередь, а кто хочет подписаться, это вопрос нижестоящего
- Отсечение пиков трафика и мониторинг: при наличии пробела в возможностях обработки вышестоящей и нижестоящей систем используйте очередь сообщений в качестве общей «воронки». Распространять, когда нисходящий поток способен к обработке.
- обработка журнала: Используйте очереди сообщений при обработке журналов, такие как приложения Kafka, чтобы решить проблему большого количества передач журналов.
- Новостная рассылка: Очереди сообщений обычно имеют встроенные эффективные механизмы связи, поэтому их также можно использовать для простого обмена сообщениями, например, для реализации двухточечных очередей сообщений или чатов.
Рекомендуются понятные объяснения:
В чем разница между kafka, activemq, RabbitMQ, RocketMQ?
- Сообщество ActiveMQ относительно зрелое, но по сравнению с текущим состоянием производительность ActiveMQ относительно низкая, а итерация версий очень медленная, поэтому не рекомендуется.
- Хотя RabbitMQ немного уступает Kafka и RocketMQ с точки зрения пропускной способности, поскольку он разработан на основе erlang, он обладает сильными возможностями параллелизма, чрезвычайно хорошей производительностью и низкой задержкой, достигающей уровня микросекунд. Однако, поскольку RabbitMQ разработан на основе erlang, немногие отечественные компании имеют возможность проводить исследования и настройку на уровне исходного кода erlang. Если бизнес-сценарий не требует слишком много параллелизма (100 000, миллионы), тогда RabbitMQ должен быть вашим первым выбором среди этих четырех очередей сообщений. Если это вычисления в реальном времени, сбор логов и другие сценарии в области больших данных, то использование Kafka является отраслевым стандартом, здесь нет абсолютно никаких проблем, сообщество очень активное, и оно никогда не будет желтым, не говоря уже о факт, что это почти норма де-факто в этой области во всем мире.
- RocketMQ производится Alibaba.Это проект с открытым исходным кодом на Java.Мы можем напрямую читать исходный код, а затем настраивать MQ нашей собственной компании, а RocketMQ фактически тестирует реальные бизнес-сценарии Alibaba. Сообщество RocketMQ относительно активно, но ничего страшного, документация относительно проста, а интерфейс не соответствует стандартной спецификации JMS.Некоторым системам для миграции требуется модифицировать много кода. Существует также технология, представленная Али. Вы должны хорошо справляться с этой технологией. Если технология будет заброшена, сообщество станет желтым. Если у вашей компании есть техническая мощь, я думаю, что очень хорошо использовать RocketMQ.
- Характеристики kafka на самом деле очевидны, то есть он предоставляет лишь несколько основных функций, но обеспечивает сверхвысокую пропускную способность, задержку на уровне мс, чрезвычайно высокую доступность и надежность, а дистрибутив можно произвольно расширять. При этом Kafka желательно поддерживать небольшое количество тем, чтобы обеспечить ее сверхвысокую пропускную способность. Единственным недостатком Kafka является возможность повторного потребления сообщений, что очень незначительно повлияет на точность данных.В области больших данных и сбора журналов это небольшое влияние можно игнорировать.Эта функция, естественно, подходит для больших данных. вычисления и регистрация в реальном времени.
В случае высокого параллелизма, как предотвратить потерю сообщений, если очередь заполнена?
- Производители могут использовать механизм повторных попыток. Поскольку потребители продолжат потреблять сообщения, они могут повторить попытку поместить сообщения в очередь.
- Очередь недоставленных сообщений, которую можно понимать как запасное колесо (рекомендуется)
- То есть, когда срок действия сообщения истекает, очередь заполнена, а сообщение отклонено, его можно отправить в очередь недоставленных сообщений.
- Если и очередь недоставленных сообщений, и обычная очередь заполнены, учитывая, что потребляемая мощность потребителя недостаточна, потребитель может быть многопоточным для обработки.
Поговорим об очередях недоставленных писем
Очереди недоставленных сообщений используются для обработки сообщений, которые невозможно использовать в обычном режиме, т. е. недоставленных сообщений..
Когда сообщение не может быть использовано в первый раз,Версия Message Queuing RocketMQ будет автоматически повторять сообщения; После достижения максимального количества повторных попыток, если потребление все еще не удается, это означает, что потребитель не может правильно использовать сообщение при нормальных обстоятельствах.В это время версия очереди сообщений RocketMQ не будет немедленно отбрасывать сообщение, а отправит его в вВ специальной очереди, соответствующей потребителю, эта специальная очередь называетсяочередь недоставленных сообщений.
Особенности недоставленных сообщений:
- Он больше не будет нормально потребляться потребителями.
- Срок действия такой же, как у обычных сообщений, которые составляют 3 дня, и будут автоматически удалены через 3 дня. Поэтому, пожалуйста, обработайте сообщение о недоставленном письме незамедлительно в течение 3 дней после его создания.
Особенности очередей недоставленных писем:
- Очередь недоставленных сообщений соответствует идентификатору группы, а не отдельному экземпляру потребителя.
- Если идентификатор группы не генерирует сообщение о недоставленных сообщениях, версия очереди сообщений RocketMQ не создаст для него соответствующую очередь недоставленных сообщений.
- Очередь недоставленных сообщений содержит все недоставленные сообщения, сгенерированные соответствующим идентификатором группы, независимо от того, к какой теме относится сообщение.
Консоль Message Queuing RocketMQ предоставляет функции запроса, экспорта и повторной отправки недоставленных сообщений.
Как обеспечить идемпотентность MQ, когда потребители потребляют сообщения?
идемпотентность
Когда потребитель потребляет сообщение в mq, mq отправил сообщение потребителю, и потребитель возвращает подтверждение mq, когда сеть прерывается, поэтому mq не получает подтверждающую информацию, сообщение будет повторно отправлено другим потребителям, или отправить его потребителю снова после повторного подключения к сети, но на самом деле потребитель успешно использовал сообщение, в результате чего потребитель потреблял дубликаты сообщений;
решение
- Решение для идемпотентной строки потребителей MQ обычно использует глобальный идентификатор или записывает уникальный идентификатор, такой как метка времени, UUID или заказ.
- Вы также можете использовать идентификатор mq для оценки или создать глобально уникальный идентификатор в соответствии со своими собственными правилами и использовать этот идентификатор для определения того, было ли сообщение использовано каждый раз, когда сообщение потребляется.
- Назначьте глобальный идентификатор сообщению и запишите
в redis в форме K-V, пока сообщение потребляется. Прежде чем потребители начнут потреблять, они могут зайти в Redis, чтобы проверить, есть ли записи о потреблении.
Как обеспечить согласованность данных при использовании асинхронных сообщений
- Сделки с помощью базы данных: Как использование асинхронных сообщений может также зависеть от транзакций базы данных? Это требует созданиялокальная таблица сообщений, это можно сделать с помощьюТранзакция для управления обновлениями локальной бизнес-логикии этоЗапись в таблицу сообщений выполняется в той же транзакции, как только сообщение не попадет в базу данных, оно будет отброшено напрямую. Если сообщение успешно добавлено в базу данных, сообщение может быть преобразовано на основе данных сообщения в локальной базе данных в зависимости от ситуации. Что касается того, как поддерживать согласованность состояния в локальной таблице сообщений и очереди сообщений, можно использовать метод 2PC. Отбросьте базу данных перед отправкой сообщения, затем отправьте сообщение и обновите статус сообщения в таблице локальной базы данных при получении результата синхронизации или обратного вызова сообщения. Тогда просто пройдиГолосование по времениДостаточно способа повторной доставки сообщения, статус которого не записан, но не отправлен. Но есть посылка этой схемы, то есть требуется потребитель сообщенияХорошо справляйтесь с идемпотентным управлениемНа самом деле обычно необходимо учитывать потребителей асинхронных сообщений.
- Помимо использования базы данных, вы также можете использоватьRedisДождитесь кеша. Таким образом, невозможно использовать откат транзакций, который поставляется с реляционной базой данных.
Причины, по которым RocketMQ не использует Zookeeper в качестве реестра, а также преимущества и недостатки самодельного NameServer?
- ZooKeeper в качестве поддержкипоследовательная согласованностьпромежуточное ПО, в некоторых случаях для обеспечения согласованности оно теряет определенный период времениДоступность, RocketMQ нужен реестр только для того, чтобынайти адрес компонента, в некоторых случаях реестр RocketMQ может иметь несогласованность данных, что такжеНедостаток NameServer, поскольку кластеры NameServer не взаимодействуют друг с другом, регистрационная информация между ними может быть несогласованной..
- Кроме того, при подключении нового сервераNameServer не сразу уведомляет производителя, но поПроизводитель регулярно запрашивает сервер имен для получения последней информации о брокере/потребителе.(Эта ситуация решается балансировкой нагрузки при отправке сообщений через Producer)
- Включает пользовательские протоколы, использующие Netty для связи компонентов.
- Стратегия балансировки нагрузки повторных попыток сообщения (подробности см. в стратегии балансировки нагрузки Dubbo)
- Фильтр сообщений (производитель отправляет сообщения брокеру, брокер хранит информацию о сообщениях, потребитель запрашивает у брокера запрос файлов сообщений из файлов на диске при потреблении, использует сервер фильтров для фильтрации на брокере)
- Взаимодействие между Master и Slave в синхронной двойной записи брокера и асинхронной двойной записи
Это не легко создать, если вы найдете это полезным, дайте маленькую звезду.GitHub.com/кошки мечты/J…
Небольшой демонстрационный проект объединяет очередь сообщений RocketMQ:GitHub.com/кошки мечты/ это…