Краткое изложение интервью по Java, включая ключевые знания Java и общие платформы с открытым исходным кодом, приветствуется к прочтению. В статье возможны ошибки, т.к. личные знания ограничены, прошу указать! Статья постоянно обновляется...
ID заглавие адрес 1 Design Patterns Interview Questions (резюме наиболее полных вопросов для интервью) nuggets.capable/post/684490… 2 Вопросы для собеседования по базовым знаниям Java (сводка наиболее полных вопросов для собеседования) nuggets.capable/post/684490… 3 Вопросы для собеседования по коллекции Java (сводка наиболее полных вопросов для собеседования) nuggets.capable/post/684490… 4 Вопросы для интервью JavaIO, BIO, NIO, AIO, Netty (резюме наиболее полных вопросов для интервью) nuggets.capable/post/684490… 5 Вопросы для собеседования по параллельному программированию на Java (сводка наиболее полных вопросов для собеседования) nuggets.capable/post/684490… 6 Вопросы для собеседования об исключении Java (сводка наиболее полных вопросов для собеседования) nuggets.capable/post/684490… 7 Вопросы для интервью с виртуальной машиной Java (JVM) (сводка наиболее полных вопросов для интервью) nuggets.capable/post/684490… 8 Весенние вопросы для интервью (резюме наиболее полных вопросов для интервью) nuggets.capable/post/684490… 9 Вопросы интервью Spring MVC (сводка наиболее полных вопросов интервью) nuggets.capable/post/684490… 10 Вопросы интервью Spring Boot (обобщите наиболее полные вопросы интервью) nuggets.capable/post/684490… 11 Вопросы интервью Spring Cloud (краткое изложение наиболее полных вопросов интервью) nuggets.capable/post/684490… 12 Вопросы интервью Redis (сводка наиболее полных вопросов интервью) nuggets.capable/post/684490… 13 Вопросы для интервью MyBatis (сводка наиболее полных вопросов для интервью) nuggets.capable/post/684490… 14 Вопросы для собеседования по MySQL (сводка наиболее полных вопросов для собеседования) nuggets.capable/post/684490… 15 TCP, UDP, Socket, HTTP вопросы для интервью (сводка наиболее полных вопросов для интервью) nuggets.capable/post/684490… 16 Вопросы для интервью с Nginx (сводка наиболее полных вопросов для интервью) nuggets.capable/post/684490… 17 ElasticSearch Вопросы на собеседовании 18 кафка вопросы интервью 19 Вопросы для интервью RabbitMQ (сводка наиболее полных вопросов для интервью) nuggets.capable/post/684490… 20 Вопросы для интервью Dubbo (краткое изложение наиболее полных вопросов для интервью) nuggets.capable/post/684490… 21 Вопросы интервью ZooKeeper (резюме наиболее полных вопросов интервью) nuggets.capable/post/684490… 22 Вопросы для интервью Netty (краткое изложение наиболее полных вопросов для интервью) 23 Вопросы для интервью с Tomcat (сводка наиболее полных вопросов для интервью) nuggets.capable/post/684490… 24 Вопросы для собеседования по Linux (сводка наиболее полных вопросов для собеседования) nuggets.capable/post/684490… 25 Вопросы для интервью, связанные с Интернетом (краткое изложение наиболее полных вопросов для интервью) 26 Вопросы для интервью по безопасности в Интернете (краткое изложение наиболее полных вопросов для интервью)
что такое МК
- MQ — это очередь сообщений. Это промежуточный продукт, который взаимодействует между программным обеспечением и программным обеспечением.
Преимущества МК
-
короткий ответ
- Асинхронная обработка — повышает производительность системы по сравнению с традиционными последовательными и параллельными методами.
- Разделение приложений — системы взаимодействуют посредством сообщений, не заботясь об обработке других систем.
- Отсечение трафика — количество запросов можно контролировать с помощью длины очереди сообщений; это может уменьшить количество одновременных запросов за короткий период времени.
- Обработка журналов. Решает массовую передачу журналов.
- Обмен сообщениями. Очереди сообщений обычно имеют встроенные эффективные механизмы обмена данными, поэтому их также можно использовать для простого обмена сообщениями. Например, для реализации одноранговых очередей сообщений, чатов и т. д.
-
Подробный ответ
Что такое развязка, асинхронность и отсечение пиков? .
-
разъединение: Система А отправляет данные трем системам BCD и отправляет их через вызов интерфейса. Что, если E-системе тоже нужны эти данные? Что, если системе C это не нужно сейчас? Человек, отвечающий за Систему А, почти потерпел крах... Система А сильно связана с различными другими запутанными системами.Система А генерирует относительно важную часть данных, и многим системам требуется, чтобы Система А отправляла эти данные. Если используется MQ, система A генерирует часть данных и отправляет их в MQ, какой системе нужны данные для потребления в MQ самостоятельно. Если новой системе нужны данные, их можно использовать непосредственно из MQ; если системе не нужны эти данные, просто отмените потребление сообщений MQ. Таким образом, системе A не нужно учитывать, кому отправлять данные, не нужно поддерживать этот код и не нужно учитывать, был ли вызов успешным, тайм-аут сбоя и т. д.
就是一个系统或者一个模块，调用了多个系统或者模块，互相之间的调用很复杂，维护起来很麻烦。但是其实这个调用是不需要直接同步调用接口的，如果用 MQ 给它异步化解耦。 -
асинхронный: Когда система А получает запрос, ей необходимо записать библиотеку локально, а также необходимо записать библиотеку в трех системах BCD, для локальной записи библиотеки требуется 3 мс, а в трех системах BCD — 300 мс, 450 мс. и 200 мс для записи библиотеки соответственно. Общая задержка финального запроса 3 + 300 + 450 + 200 = 953 мс, что близко к 1 с.Пользователь чувствует, что он что-то сделал, и тормозит до смерти. Пользователь инициирует запрос через браузер. Если используется MQ, то система А непрерывно отправляет в очередь MQ 3 сообщения.Если это занимает 5 мс, общее время от принятия запроса до возврата ответа пользователю составляет 3 + 5 = 8 мс.
-
отсечение пика: Уменьшите нагрузку на сервер в часы пик.
Каковы недостатки очередей сообщений
-
Недостатки следующие:
-
Снижение доступности системы
Первоначально система работала нормально, но теперь вам нужно присоединиться к очереди сообщений, очередь сообщений зависает, и ваша система больше не работает. В результате снижается доступность системы;
-
Повышенная сложность системы
При добавлении очереди сообщений необходимо учитывать множество аспектов, таких как: вопросы согласованности, способы обеспечения того, чтобы сообщения не использовались повторно, и способы обеспечения надежной передачи сообщений. Следовательно, есть больше вещей, которые нужно учитывать, и больше сложности.
-
Проблемы согласованности
После того, как система A завершила обработку, она сразу возвращает успех, и люди думают, что ваш запрос выполнен успешно; но проблема в том, что если есть три системы в BCD, две системы в BD успешно записывают базу данных, и результат в системе C не удается записать базу данных, что мне делать? Ваши данные противоречивы.
-
所以消息队列实际是一种非常复杂的架构，你引入它有很多好处，但是也得针对它带来的坏处做各种额外的技术方案和架构来规避掉，做好之后，你会发现，妈呀，系统复杂度提升了一个数量级，也许是复杂了 10 倍。但是关键时刻，用，还是得用的。
Какое промежуточное программное обеспечение для сообщений использует ваша компания в производственной среде?
-
Прежде всего, вы можете сказать, какое промежуточное ПО для сообщений использует ваша компания, например RabbitMQ, а затем вы можете дать предварительный анализ выбора различных технологий промежуточного ПО MQ.
-
Например: Например, ActiveMQ — это старомодное промежуточное программное обеспечение для обмена сообщениями. Многие отечественные компании широко использовали его в прошлом, и его функции очень эффективны.
-
Но проблема в том, что невозможно подтвердить, что ActiveMQ может поддерживать сложные сценарии высокого параллелизма, высокой нагрузки и высокой пропускной способности интернет-компаний, и он редко внедряется в отечественных интернет-компаниях. Более того, некоторые традиционные предприятия используют ActiveMQ для асинхронных вызовов и разделения системы.
-
Затем вы можете поговорить о RabbitMQ, его преимущество в том, что он может поддерживать высокий параллелизм, высокую пропускную способность, высокую производительность и имеет очень полный и удобный интерфейс управления фоном.
-
Кроме того, он также поддерживает кластеризацию, архитектуру развертывания с высокой доступностью, поддержку с высокой надежностью для сообщений и относительно полные функции.
-
Более того, после исследований известно много случаев, когда крупные отечественные интернет-компании внедряли масштабные кластеры RabbitMQ для поддержки собственного бизнеса, а различные отечественные малые и средние интернет-компании также использовали RabbitMQ на практике.
-
Кроме того, сообщество RabbitMQ с открытым исходным кодом очень активно, и для исправления найденных ошибок и выполнения различных оптимизаций используются высокочастотные итерационные версии, поэтому после всестороннего рассмотрения компания приняла RabbitMQ.
-
Однако у RabbitMQ есть и недостаток, то есть он разработан на основе языка erlang, поэтому анализировать исходный код внутри сложнее, а также сложно проводить глубокую настройку и трансформацию исходного кода. все, требуется относительно твердое знание языка erlang.
-
Затем мы можем поговорить о RocketMQ, который является открытым исходным кодом Alibaba.Он прошел тест на сверхвысокий параллелизм и высокую пропускную способность в производственной среде Alibaba и имеет отличную производительность.Он также поддерживает специальные сценарии, такие как распределенные транзакции.
-
Более того, RocketMQ разработан на основе языка Java, который подходит для углубленного чтения исходного кода, при необходимости может решать задачи онлайн-производства на уровне исходного кода, включая вторичную разработку и преобразование исходного кода.
-
Другой - Кафка. Промежуточное программное обеспечение сообщений, предоставляемое Kafka, имеет значительно меньше функций, то есть намного меньше, чем упомянутое выше промежуточное программное обеспечение MQ.
-
Однако преимущество Kafka заключается в том, что он предназначен для таких сценариев, как сверхвысокопроизводительный сбор журналов в реальном времени, синхронизация данных в реальном времени и вычисление данных в реальном времени.
-
Поэтому Kafka часто используется в связке с технологиями вычислений в реальном времени (такими как Spark Streaming, Storm и Flink) в сфере больших данных. Однако он редко используется в традиционных сценариях использования промежуточного программного обеспечения MQ.
Каковы преимущества и недостатки Kafka, ActiveMQ, RabbitMQ, RocketMQ?
-
Подводя итог, после различных сравнений делаются следующие предложения:
-
Общая бизнес-система должна внедрить MQ. Раньше все использовали ActiveMQ, но сейчас правда, что его используют немногие. Это не было проверено крупномасштабными сценариями пропускной способности, и сообщество не очень активно, поэтому все должны забыть об этом Лично я не рекомендую это делать;
-
Позже все начали использовать RabbitMQ, но язык erlang действительно мешал большому количеству Java-инженеров исследовать и контролировать его, для компании он был практически в неуправляемом состоянии, но это действительно был открытый исходный код, относительно стабильная поддержка и активный высокий;
-
Но сейчас все больше и больше компаний собираются использовать RocketMQ, что действительно хорошо.Ведь он производится Али, но сообщество может иметь риск внезапного пожелтения (в настоящее время RocketMQ передан в дарApache, но активность на GitHub на самом деле невысокая) Если у вас есть абсолютная уверенность в технической мощи вашей компании, рекомендуется RocketMQ. В противном случае возвращайтесь и используйте RabbitMQ. Есть активное open source сообщество, и оно никогда не будет желтым.
-
такМалые и средние компании, техническая мощь относительно общая, технические проблемы не особенно высоки, и RabbitMQ — хороший выбор;большая компания, исследования и разработки инфраструктуры сильны, и RocketMQ — хороший выбор.
-
еслиПоле больших данныхДля вычислений в реальном времени, сбора логов и других сценариев использование Kafka является отраслевым стандартом, абсолютно никаких проблем, сообщество очень активное, и оно никогда не будет желтым, не говоря уже о том, что это почти норма де-факто в это поле по всему миру.
Каковы общие проблемы с MQ? Как решить эти проблемы?
- Общие проблемы с MQ:
- порядок сообщений
- Дублирование сообщений
порядок сообщений
-
Порядок сообщений означает, что сообщения могут потребляться в том порядке, в котором они были отправлены.
-
Предположим, что производитель генерирует 2 сообщения: M1, M2, предполагая, что M1 отправляется в S1, а M2 отправляется в S2.Что нам делать, если мы хотим гарантировать, что M1 потребляется до M2?
- решение:
- Гарантированная связь производитель-MQServer-потребитель один к одному
- дефект:
- Степень параллелизма станет узким местом системы сообщений (недостаточная пропускная способность).
- Больше обработки исключений, например: пока есть проблема на стороне потребителя, весь процесс обработки будет заблокирован, и нам придется тратить больше энергии на решение проблемы блокировки. (2) Избегайте этого с помощью разумного дизайна или декомпозиции проблемы.
- Приложения, которые не заботятся о нарушении порядка, на самом деле существуют в большом количестве.
- Неупорядоченная очередь не означает неупорядоченные сообщения, поэтому это более разумный способ обеспечить порядок сообщений с бизнес-уровня, а не просто полагаться на систему сообщений.
Дублирование сообщений
-
Основной причиной дублирования сообщений является недоступность сети.
-
Таким образом, решение этой проблемы заключается в том, чтобы обойти его. Тогда возникает вопрос: если потребитель получает два одинаковых сообщения, что ему делать?
-
Бизнес-логика обработки сообщений на стороне потребителя остается идемпотентной. Пока поддерживается идемпотентность, независимо от того, сколько придет дубликатов сообщений, окончательный результат будет одним и тем же. Гарантируется, что каждое сообщение имеет уникальный номер и что обработка сообщения прошла успешно, и в то же время появляется журнал таблицы дедупликации. Используйте таблицу журнала для записи идентификатора сообщения, которое было успешно обработано.Если идентификатор нового пришедшего сообщения уже есть в таблице журнала, то это сообщение не будет обработано.
Что такое RabbitMQ?
- RabbitMQ — промежуточное программное обеспечение сообщений с открытым исходным кодом, написанное на Erlang; Самая большая особенность заключается в том, что потреблению не нужно обеспечивать существование провайдера, что обеспечивает высокую степень развязки между услугами. Вы можете использовать его для: развязки, асинхронности, ограничения пиков.
Сценарии использования rabbitmq
(1) Асинхронная связь между службами
(2) Последовательное потребление
(3) Запланированные задачи
(4) Запрос пикового сглаживания
Основные понятия RabbitMQ
- Брокер: Проще говоря, это объект сервера очереди сообщений.
- Обмен: обмен сообщениями, который определяет правила, по которым сообщения направляются в какую очередь.
- Очередь: носитель очереди сообщений, каждое сообщение будет помещено в одну или несколько очередей.
- Binding: Binding, его функция состоит в том, чтобы связать обмен и очередь в соответствии с правилами маршрутизации.
- Ключ маршрутизации: ключевое слово маршрутизации, обмен доставляет сообщения в соответствии с этим ключевым словом
- VHost: под vhost можно понимать виртуального брокера, то есть сервер mini-RabbitMQ. Он содержит независимую очередь, обмен и привязку и т. д., но самое главное, что он имеет независимую систему разрешений, которая может обеспечить контроль пользователя в диапазоне vhost. Конечно, с глобальной точки зрения RabbitMQ виртуальный хост можно использовать как средство для изоляции различных разрешений (типичным примером является то, что разные приложения могут работать на разных виртуальных хостах).
- Производитель: Производитель сообщения — это программа, которая доставляет сообщение.
- Потребитель: Потребитель сообщений — это программа, которая принимает сообщения.
- Канал: канал сообщений, в каждом соединении клиента может быть установлено несколько каналов, каждый канал представляет задачу сеанса.
由Exchange、Queue、RoutingKey三个才能决定一个从Exchange到Queue的唯一的线路。
Рабочий режим RabbitMQ
1. Простой режим (т.е. самый простой режим трансивера)
-
Сообщение производит сообщение, помещает сообщение в очередь
-
Потребитель сообщения слушает очередь сообщений.Если в очереди есть сообщение, он его потребляет.После того как сообщение забрано, оно будет автоматически удалено из очереди (скрытое сообщение может быть неправильно обработано потребитель и исчез из очереди.Если сообщение потеряно, для него можно установить ручное подтверждение, но если оно установлено для ручного подтверждения, сообщение подтверждения должно быть отправлено в очередь вовремя после обработки, иначе это вызовет переполнение памяти).
2. Режим работы (соревнование ресурсов)
- Производитель сообщения помещает сообщение в очередь. Потребителей может быть несколько. Потребитель 1 и потребитель 2 прослушивают одну и ту же очередь в одно и то же время, и сообщение потребляется. C1 и C2 совместно конкурируют за текущее содержимое очереди сообщений, и тот, кто получит его первым, несет ответственность за потребление сообщения (скрытая опасность: в случае высокого параллелизма определенное сообщение будет использоваться несколькими потребителями по умолчанию, вы можете установить переключаться (синхронизировать), чтобы гарантировать, что одно сообщение Сообщение может быть использовано только одним потребителем).
3.публикация/подписка публикация и подписка (общие ресурсы)
-
Каждый потребитель слушает свою очередь;
-
Производитель отправляет сообщение брокеру, биржа пересылает сообщение в каждую очередь, привязанную к этой бирже, и каждая очередь, связанная с биржой, получит сообщение.
Режим маршрутизации Four.routing
-
Производитель сообщения отправляет сообщение коммутатору в соответствии с оценкой маршрутизации, маршрутизация представляет собой строку (информация). В настоящее время сгенерированное сообщение содержит символ маршрутизации (метод объекта), и коммутатор может сопоставить только очередь сообщений, соответствующую ключ маршрутизации в соответствии с ключом маршрутизации. Только потребители могут получать сообщения;
-
Определение строк маршрутизации на основе бизнес-функций
-
Получите соответствующую строку функции из логики кода системы и поместите задачу сообщения в соответствующую очередь.
-
Бизнес-сценарии: уведомление об ошибке; ИСКЛЮЧЕНИЕ; функция уведомления об ошибке; традиционное уведомление об ошибке; уведомление клиента; с помощью ключевой маршрутизации ошибки в программе могут быть инкапсулированы в сообщения и переданы в очередь сообщений, разработчики могут настраивать потребителей, получать ошибки в режиме реального времени ;
5. тематический режим (разновидность режима маршрутизации)
-
Знак фунта звездочки означает подстановочный знак
-
Звездочки обозначают несколько слов, знаки фунта обозначают одно слово.
-
Функция маршрутизации добавляет нечеткое соответствие
-
Производитель сообщений генерирует сообщение и доставляет его коммутатору.
-
Коммутатор нечетко сопоставляется с соответствующей очередью в соответствии с правилами ключа, а наблюдающий потребитель очереди получает потребление сообщений.
（在我的理解看来就是routing查询的一种模糊匹配，就类似sql的模糊查询方式）
Как гарантировать порядок сообщений RabbitMQ?
-
Разделение нескольких очередей (очередей сообщений), один потребитель (consumer) на очередь (очередь сообщений), — это просто больше очередей (очередей сообщений), что действительно является неприятным моментом;
-
Или просто очередь (очередь сообщений), но соответствующая потребителю (потребителю), а затем потребитель (потребитель) внутренне использует очередь памяти для постановки в очередь, а затем распределяет ее по разным базовым рабочим процессам для обработки.
Как распространяется сообщение?
- Если на очередь подписан хотя бы один потребитель, сообщения будут отправляться потребителям в циклическом режиме. Каждое сообщение будет рассылаться только одному подписанному потребителю (при условии, что потребитель может нормально обработать сообщение и подтвердить его). Функцию мультипотребления можно реализовать за счет маршрутизации
Как маршрутизируются сообщения?
-
Поставщик сообщений -> Маршрутизация -> Одна или несколько очередей Когда сообщение публикуется на бирже, оно будет иметь ключ маршрутизации, который устанавливается при создании сообщения. Очереди могут быть привязаны к биржам с помощью ключей маршрутизации очередей. После того, как сообщение прибудет на биржу, RabbitMQ сопоставит ключ маршрутизации сообщения с ключом маршрутизации очереди (для разных бирж существуют разные правила маршрутизации);
-
Обычно используемые переключатели в основном делятся на следующие три типа:
-
разветвление: если биржа получает сообщение, оно будет передано во все связанные очереди.
-
прямой: если ключ маршрутизации точно совпадает, сообщение доставляется в соответствующую очередь
-
тема: позволяет сообщениям из разных источников попадать в одну и ту же очередь. При обмене темами можно использовать подстановочные знаки.
-
На чем основано сообщение?
- Поскольку создание и уничтожение TCP-подключений обходятся дорого, а количество параллелизма ограничено системными ресурсами, это приведет к узким местам в производительности. RabbitMQ использует каналы для передачи данных. Каналы — это виртуальные соединения, устанавливаемые внутри реальных TCP-соединений, и количество каналов на одно TCP-соединение не ограничено.
Как сделать так, чтобы сообщения не использовались повторно? Другими словами, как обеспечить идемпотентность потребления сообщений?
-
Давайте поговорим о том, почему повторное потребление: в нормальных условиях, когда потребители потребляют сообщения, они будут отправлять подтверждающее сообщение в очередь сообщений после потребления, и очередь сообщений будет знать, что сообщение было потреблено, и удалит сообщение из сообщения. очередь удалить;
-
Однако из-за сетевой передачи и других сбоев информация подтверждения не передается в очередь сообщений, в результате чего очередь сообщений не знает, что она использовала сообщение, и перераспределяет сообщение другим потребителям.
-
В ответ на вышеуказанные проблемы одним из решений является: обеспечить уникальность сообщения, даже если оно передается несколько раз, не позволять многократному потреблению сообщения влиять на него, гарантировать, что сообщение является идемпотентным;
-
Например, когда данные, записанные в очередь сообщений, помечены уникальным образом, при потреблении сообщения судят, было ли оно использовано в соответствии с уникальным идентификатором;
-
Предположим, у вас есть система, которая получает сообщение и вставляет часть данных в базу данных. Если вы повторяете сообщение дважды, вы не вставляете две части данных. Разве эти данные не ошибочны? Но если вы потребляете его во второй раз, судите по себе, было ли оно израсходовано, если да, то просто выбросьте его, чтобы не сохранить часть данных, тем самым обеспечив правильность данных.
-
Как я могу убедиться, что сообщения отправляются в RabbitMQ правильно? Как убедиться, что получатель сообщения потребляет сообщение?
режим подтверждения отправителя
-
Установите канал в режим подтверждения (режим подтверждения отправителя), тогда всем сообщениям, опубликованным на канале, будет присвоен уникальный идентификатор.
-
Как только сообщение доставлено в очередь назначения или сообщение записано на диск (постоянные сообщения), канал отправляет подтверждение (содержащее уникальный идентификатор сообщения) производителю.
-
Если в RabbitMQ возникает внутренняя ошибка и сообщение теряется, отправляется сообщение nack (неподтвержденное, неподтвержденное).
-
Режим подтверждения отправителя является асинхронным, и приложение-производитель может продолжать отправлять сообщения, ожидая подтверждения. Когда сообщение подтверждения поступает в приложение-производитель, запускается метод обратного вызова приложения-производителя для обработки сообщения подтверждения.
Механизм подтверждения получателя
-
Потребители должны подтверждать каждое полученное сообщение (получение сообщения и подтверждение сообщения — две разные операции). RabbitMQ может безопасно удалить сообщение из очереди, только если потребитель подтвердил получение сообщения.
-
Механизм тайм-аута здесь не используется, RabbitMQ только подтверждает необходимость повторной отправки сообщения через прерывание соединения Потребителя. То есть, пока соединение не прерывается, RabbitMQ дает Потребителю достаточно времени для обработки сообщения. Обеспечить возможную согласованность данных;
Несколько особых случаев перечислены ниже
- Если потребитель получает сообщение и отключается или отказывается от подписки до подтверждения, RabbitMQ будет считать сообщение нераспространенным и перераспределит его следующему подписанному потребителю. (Могут быть скрытые опасности повторного потребления сообщений, которые необходимо дедуплицировать)
- Если потребитель получает сообщение, не подтверждая его, и соединение не разорвано, RabbitMQ считает, что потребитель занят, и больше не будет рассылать потребителю сообщения.
Как обеспечить надежную передачу сообщений RabbitMQ?
-
Ненадежные сообщения могут быть вызваны потерей сообщений, перехватом и т. д.;
-
Потеря делится на: потерянное сообщение производителя, потерянное сообщение списка сообщений, потерянное сообщение потребителя;
-
Производитель теряет сообщение: с точки зрения производителей, теряющих данные, RabbitMQ предоставляет режимы транзакций и подтверждения, чтобы гарантировать, что производители не потеряют сообщения;
Механизм транзакции означает: перед отправкой сообщения откройте транзакцию (channel.txSelect()), а затем отправьте сообщение, если в процессе отправки будет какая-либо аномалия, транзакция будет откатана (channel.txRollback()) , и если отправка прошла успешно, транзакция будет зафиксирована (channel.txCommit()). Однако у этого подхода есть недостаток: падает пропускная способность;
В основном используется режим подтверждения: как только канал переходит в режим подтверждения, всем сообщениям, опубликованным на канале, будет присвоен уникальный идентификатор (начиная с 1), как только сообщение будет доставлено во все соответствующие очереди;
RabbitMQ отправит производителю ACK (содержащий уникальный идентификатор сообщения), который сообщает производителю, что сообщение правильно прибыло в очередь назначения;
Если RabbitMQ не сможет обработать сообщение, вам будет отправлено сообщение Nack, и вы сможете повторить операцию.
-
очередь сообщений потеряла данные: сохранение сообщения.
Чтобы справиться с потерей данных в очереди сообщений, обычно включается конфигурация постоянного диска.
Эту конфигурацию сохраняемости можно использовать в сочетании с механизмом подтверждения.Вы можете отправить сигнал Ack производителю после того, как сообщение будет сохранено на диске.
Таким образом, если rabbitMQ будет уничтожен до того, как сообщение будет сохранено на диске, производитель не получит сигнал Ack и автоматически отправит его повторно.
Так как же упорствовать?
Тут, кстати, на самом деле очень просто, всего два следующих шага
1. Установите для постоянного идентификатора durable очереди значение true, что означает, что это постоянная очередь.
2. При отправке сообщения установите deliveryMode=2
После этой настройки, даже если rabbitMQ зависнет, данные можно будет восстановить после перезапуска
-
Потребители теряют сообщения: Потребители обычно теряют данные, потому что принят режим автоматического сообщения подтверждения, и вместо этого сообщение может быть подтверждено вручную!
После того, как потребитель получит сообщение, перед обработкой сообщения он автоматически ответит, что RabbitMQ получил сообщение;
Если в это время обработка сообщения не удалась, сообщение будет потеряно;
Решение: после успешной обработки сообщения вручную ответьте на подтверждающее сообщение.
Почему нельзя использовать механизм сохраняемости для всех сообщений?
-
Во-первых, это неизбежно приведет к падению производительности, потому что запись на диск происходит гораздо медленнее, чем запись в оперативную память, и может быть разница в пропускной способности сообщений в 10 раз.
-
Во-вторых, когда механизм сохраняемости сообщений используется во встроенном кластерном решении RabbitMQ, возникает «сумасшедшая» проблема. Противоречие состоит в том, что если для сообщения установлен постоянный атрибут, а для очереди не установлен постоянный атрибут, то, когда узел-владелец очереди ненормальный, сообщение, отправленное в очередь, будет заблокировано до того, как очередь будет перестроена. ; если у сообщения установлен постоянный атрибут, а очередь также устанавливает постоянный атрибут, то когда узел-владелец очереди ненормальный и не может быть перезапущен, очередь не может быть перестроена на других узлах, и использование очереди может только быть возобновлено после перезапуска узла-владельца. , и сообщение, отправленное в очередь в течение этого времени, будет заблокировано.
-
Следовательно, сохранять сообщение или нет, необходимо всесторонне рассмотреть требования к производительности и возможные проблемы. Если вы хотите достичь пропускной способности более 100 000 сообщений в секунду (один сервер RabbitMQ), вы должны либо использовать другие методы для обеспечения надежной доставки сообщений, либо использовать очень быструю систему хранения, поддерживающую полную персистентность (например, с использованием SSD). . Другой принцип обработки: постоянно обрабатывать только ключевые сообщения (в соответствии с важностью бизнеса), и следует гарантировать, что количество ключевых сообщений не вызовет узких мест в производительности.
Как обеспечить высокую доступность? Кластер RabbitMQ
- RabbitMQ является более репрезентативным, поскольку он основан на принципах «ведущий-ведомый» (нераспределенный) для обеспечения высокой доступности. Мы будем использовать RabbitMQ в качестве примера, чтобы объяснить, как добиться высокой доступности первого MQ. RabbitMQ имеет три режима: автономный режим, обычный режим кластера и режим зеркального кластера.
-
Автономный режим, это демо уровень, обычно вы начали играть локально? никто не использует автономный режим для производства
-
Обычный кластерный режим:
- Это означает запуск нескольких экземпляров RabbitMQ на нескольких машинах, по одному на каждую машину.
- Созданная вами очередь будет размещена только на одном экземпляре RabbitMQ, но каждый экземпляр синхронизирует метаданные очереди (метаданные можно рассматривать как некоторую информацию о конфигурации очереди, через метаданные вы можете найти экземпляр, в котором находится очередь) . Когда вы потребляете, на самом деле, если вы подключаетесь к другому экземпляру, то этот экземпляр будет извлекать данные из экземпляра, в котором находится очередь. Это решение в основном предназначено для повышения пропускной способности, то есть для того, чтобы несколько узлов в кластере могли обслуживать операции чтения и записи очереди.
-
режим зеркального кластера:
-
Этот режим является так называемым режимом высокой доступности RabbitMQ. В отличие от обычного режима кластера, в режиме зеркального кластера созданная вами очередь будет существовать в нескольких экземплярах независимо от метаданных или сообщений в очереди, то есть каждый узел RabbitMQ имеет полную копию очереди. , который содержит все данные очереди. Затем каждый раз, когда вы записываете сообщение в очередь, это сообщение будет автоматически синхронизироваться с очередями нескольких экземпляров. RabbitMQ имеет очень хорошую консоль управления, которая позволяет добавить стратегию в фоновом режиме.Эта стратегия является стратегией режима зеркального кластера.Если она указана, может потребоваться синхронизация данных на всех узлах или на указанном количестве узлов.Один раз снова При создании очереди применение этой стратегии автоматически синхронизирует данные с другими узлами.
-
Преимущество этого заключается в том, что если какая-либо из ваших машин не работает, все в порядке, другие машины (узлы) также содержат полные данные очереди, и другие потребители могут перейти к другим узлам для потребления данных. Недостатком является то, что, во-первых, слишком высока нагрузка на производительность: сообщения должны быть синхронизированы со всеми машинами, что приводит к сильному давлению на пропускную способность сети и ее потреблению! Данные очереди RabbitMQ размещаются на одном узле, а под зеркальным кластером каждый узел также помещает полные данные очереди.
-
Как решить задержку и истечение очереди сообщений? Что делать, если очередь сообщений заполнена? Что делать, если миллионы сообщений задерживаются на несколько часов?
-
Метод обработки невыполненных сообщений: Временное аварийное расширение:
-
Сначала устраните проблему потребителя, чтобы убедиться, что он возобновляет скорость потребления, а затем остановите все существующие потребители.
Создайте новую тему, раздел в 10 раз больше исходного, а количество очередей в 10 раз больше исходного временно установлено.
Затем напишите временную программу-потребитель, которая распределяет данные.Эта программа развернута для использования невыполненных данных.После потребления она не выполняет трудоемкую обработку, а непосредственно опрашивает и записывает в 10 раз больше временно установленных очередей.
Затем для развертывания потребителей временно реквизируется в 10 раз больше машин, и каждая партия потребителей использует данные из временной очереди. Этот подход эквивалентен временному увеличению ресурсов очереди и потребительских ресурсов в 10 раз и потреблению данных с обычной 10-кратной скоростью.
После быстрого использования невыполненных данных необходимо восстановить первоначально развернутую архитектуру и повторно использовать исходную машину-потребитель для приема сообщений.
Аннулирование сообщения в MQ: если вы используете RabbitMQ, RabbtiMQ может установить время истечения срока действия, которое равно TTL. Если сообщение задерживается в очереди более определенного времени, оно будет очищено RabbitMQ, и данные исчезнут. Тогда это вторая яма. Это не означает, что в mq будет накапливаться большое количество данных, но большое количество данных будет напрямую потеряно. Мы можем принять решение, которое представляет собой пакетное перенаправление, которое мы сделали в аналогичном сценарии в Интернете раньше. Когда был большой бэклог, мы просто отбрасывали данные и ждали, пока не закончится пиковый период, например, все допоздна после кофе попили вместе до 12:00, а пользователи все легли спать. В это время мы начинаем писать программы, пишем временную программу для потерянного пакета данных, проверяем ее по крупицам, а затем снова заливаем в mq, чтобы восполнить потерянные за день данные. Это может быть только так. Предположим, что 10 000 заказов остались в mq и не были обработаны, а 1 000 из них потеряны.Вы можете только вручную написать программу, чтобы узнать эти 1 000 заказов, и вручную отправить их в mq для повторного восполнения. -
Блок очереди сообщений mq заполнен: Если сообщение находится в очереди в mq, вы давно его не обрабатывали, а mq в это время почти заполнен, что мне делать? Есть ли другой способ сделать это? Нет, кто заставил ваш первый план выполняться слишком медленно, вы временно пишете программу, получаете доступ к данным для потребления, потребляете одно и отбрасываете другое, не используете его и быстро потребляете все сообщения. Потом переходим на второй план, а потом дополняем данные ночью.
Идеи дизайна MQ
-
Например, эту систему очереди сообщений, давайте рассмотрим ее со следующих точек зрения:
-
Во-первых, этот mq должен поддерживать масштабируемость, то есть быстро расширять емкость, когда это необходимо, чтобы можно было увеличить пропускную способность и емкость, так что же делать? Чтобы спроектировать распределенную систему, обратитесь к концепции дизайна kafka, брокер -> тема -> раздел, поместите машину в каждый раздел и сохраните часть данных. Если ресурсов сейчас не хватает, то просто, добавить разделы в топик, потом сделать миграцию данных, и добавить больше машин, чтобы можно было хранить больше данных и обеспечить более высокую пропускную способность?
-
Во-вторых, вы должны учитывать, должны ли данные этого mq быть на диске, верно? Это должно быть необходимо, только удаление диска может гарантировать, что другие процессы зависнут и данные будут потеряны. Как он упал, когда диск уронили? Последовательная запись, чтобы не было накладных расходов на адресацию случайного чтения и записи диска, а производительность последовательного чтения и записи диска была очень высокой, что и является идеей kafka.
-
Во-вторых, вы учитываете доступность своего mq? По этому вопросу обратитесь к механизму гарантии высокой доступности kafka, описанному в предыдущем разделе о доступности. Мультикопирование -> лидер и последователь -> брокер вешает трубку и переизбирает лидера для внешнего обслуживания.
-
Можете ли вы поддержать потерю данных 0? Хорошо, это немного сложно.