Я считаю, что очереди сообщений (MQ) не должны быть незнакомы Java-программистам.Если вы чувствуете себя незнакомыми, возможно, проекты, с которыми вы контактируете, относительно небольшие, традиционные проекты не имеют разделенных служб, и они будут разделены, когда их станет больше. и другие предприятия Несколько микросервисов, давайте сначала рассмотрим бизнес-сценарий.
В качестве примера возьмем заказ, размещенный пользователем приложения нашей компании, запрос пользователя сначала поступает в службу заказа, а затем переходит в службу инвентаризации для успешного вычета запасов, а затем информирует продавца о выполнении бизнеса, а затем переходит к Система купонов для расчета купонов, а затем переходит к системе баллов для расчета баллов.
Если предположить, что время отклика каждого интерфейса микросервиса составляет 200 мс, тогда эти вызовы службы займут 600 мс, плюс время обработки собственного бизнеса службы заказа 200 мс, время отклика всего интерфейса отправки заказа составляет почти 1 с. Если вы подключаетесь к другим системам по мере развития бизнеса в будущем, это время будет все больше и больше. Интерфейс отвечает за одну секунду, это очень низкая пропускная способность. Когда QPS системы немного выше, ресурсов сервера недостаточно, когда ресурсов недостаточно, последующие запросы пользователя будут ждать, пока сервер освободит ресурсы для обработки, и пользователь будет чувствовать себя застрявшим. Как только пользователь почувствует, что застрял, он, скорее всего, вернется и обновит страницу или снова нажмет, чтобы отправить заказ, а затем снова придет запрос, и снова будет осуществлен доступ к базе данных, и карта будет больше застревать. В конечном итоге система может дать сбой.
Если вы хорошенько об этом подумаете, то обнаружите, что на самом деле операции торгового бизнеса, купонного бизнеса и точечного бизнеса могут выполняться параллельно, и нет необходимости запрашивать их по очереди. Если эти несколько параллелей могут сэкономить много времени, мы можем рассмотреть возможность использования MQ.
Представьте MQ
Прежде чем представить MQ, нам нужно понять модель MQ, как промежуточного программного обеспечения сообщений, MQ используется для подключения микросервисов на обоих концах: производители и потребители.
Производитель асинхронно отправляет сообщение, которое завершает функцию, в MQ, MQ отправляет сообщение потребителю, а потребитель выполняет свои собственные действия.
На приведенном выше изображении показан процесс после использования MQ. Нам нужно только получить доступ к службе заказов, а затем я могу отправить сообщение в соответствующую службу, чтобы сделать то, что нужно сделать в службе заказов. Например, если я хочу урегулировать купона, я отправлю сообщение в службу купонов, я хочу списать и увеличить баллы, и отправить сообщение в систему баллов. Таким образом, только служба заказа занимает 200 мс, а для отправки сообщения в MQ требуется всего около 5 мс, а пропускная способность интерфейса значительно повышается. И ответ в 200 мс незаметен для пользователя. Так что это отражает первое преимущество очереди сообщений:асинхронный.
Может быть, вы скажете, что я использую многопоточность, и даже используя пул потоков, я не могу добиться асинхронного эффекта? Не беспокойтесь, на первый взгляд, использование потоков может привести к асинхронным эффектам, но вы можете подумать о том, сколько систем задействовано в запросе заказа. Если предположить, что 50 человек размещают заказ сейчас, то для обработки бизнеса необходимо открыть 50 * 5 = 250 потоков.Все мы знаем, что потоки должны потреблять ресурсы ЦП, и это также включает в себя множество операций переключения контекста потока. Используя MQ, если нашему новому бизнесу потребуется доступ к новой системе в будущем, мы можем напрямую отправить сообщение, чтобы уведомить новую систему, и почти не нужно менять какой-либо код заказа.Эта развязка на уровне системы действительно хороша. Это второе по величине преимущество MQ:разъединение.
Взяв в качестве примера первое изображение, мы сказали ранее, что интерфейс заказа, сериализованный серией микросервисов, требует 1 с для ответа. Предположим, что одновременные заказы размещаются при условии большого количества пользователей, или непосредственно рассмотрим сценарий интерфейса seckill. Десятки тысяч, а то и сотни тысяч трафика вливаются в одно мгновение.Если сервер мгновенно уничтожится по прежней пропускной способности, даже если вы будете обслуживать много кластеров, он не рухнет, то ваша база данных так не выдержит много запросов. После введения очереди сообщений мы перекинули весь мгновенный трафик в MQ.MQ специализируется на приеме высокого параллелизма и, как правило, не будет перегружен.Затем нижестоящие подсистемы потребляют из MQ партиями и балансируют, а пик мгновенного трафика отдают на Сопротивляйтесь, подождите, пока закончится пиковый период, и по-прежнему сохраняйте медленную скорость потребления, которая представляет третье важное преимущество MQ:сбривание пиков и заполнение долин.
Выше перечислены несколько преимуществ использования MQ.Я считаю, что каждый может сказать о преимуществах MQ во время собеседования.Асинхронный, развязка, отсечение пиков. Но интервьюер не хочет слышать эти слова, и обязательно хочет, чтобы вы совместили это с бизнес-сценариями в вашем проекте. А когда вы закончите говорить, интервьюер обязательно задаст уточняющие вопросы, обычно четыре вопроса от души:
- Где вы использовали MQ в своем проекте и какую проблему он решил?
- Вы сказали о преимуществах использования MQ, знаете ли вы, какие проблемы это вызвало?
- Как вы решили эти проблемы с внедрением MQ?
- Какой продукт MQ вы выбрали? Почему?
Проблемы с внедрением MQ
Использование MQ действительно решает некоторые проблемы, но когда служба MQ запускается без причины, необходимо рассмотреть вопрос об обслуживании, и в первую очередь должна быть гарантирована высокая доступность MQ.
- В противном случае MQ зависает и сообщение не отправляется. Что делать, если нижестоящие системы нескольких купонов и баллов после того, как я создам заказ, не смогут выполнить коммерческий расчет?
- MQ высокодоступен, сообщение отправлено, но бизнес расчета купона сообщает об ошибке? Так как это асинхронно, откатить не так просто.Вы рассматривали эту проблему?
- Сообщение отправляется нормально, потребитель тоже его получает, система мерчанта и система купонов работают нормально, а бизнес по очкам сообщает об ошибке и очки не начисляются, значит данные этого заказа несовместимы.Как решить Эта проблема?
- Что делать, если система баллов многократно потребляет сообщения, что приводит к двум расчетам?
Поэтому после внедрения MQ сложность системы возросла, и приходится учитывать многие из вышеперечисленных проблем. Интервьюер обязательно спросит, как ее решить, или как избежать вышеуказанных проблем, ждите следующего~~~~
Выбор продукта MQ
У меня нет опыта с этим делом, ведь мой опыт работы еще неопытен, и я не изучал его глубоко, но вы можете сослаться на сравнение нескольких популярных продуктов MQ, приведенных в Интернете.
| Атрибуты | RabbitMQ | ActiveMQ | RocketMQ | Kafka |
|---|---|---|---|---|
| Язык разработки | Erlang | Java | Java | Scala |
| Языки, поддерживаемые клиентом | Официально поддерживает Erlang, Java, Ruby и т. д. Сообщество создает множество API, поддерживающих практически все языки. | Java, C, C++, Python, PHP, Perl, .net и т. д. | Ява, С++ | Официально поддерживает Java, а сообщество выпускает различные API, такие как PHP, Python и т. д. |
| Производительность одной машины | 10000-й уровень (второй) | Десять тысяч (худший) | 100000 уровень (лучший) | 100000 уровень (второй) |
| задержка сообщения | микросекунда | миллисекунда | миллисекунда | в течение миллисекунд |
| Функции | Мощные возможности параллелизма, чрезвычайно высокая производительность, низкая задержка, активное сообщество и богатый интерфейс управления. | Устаревшие продукты, высокий уровень зрелости и дополнительные документы | MQ имеет относительно полные функции и хорошую масштабируемость. | Он поддерживает только основные функции MQ, в конце концов, он подготовлен для области больших данных. |
Объем бизнеса нашей компании не очень велик, и необходимости во вторичной разработке на MQ пока нет.Тогда, учитывая простоту интеграции и низкую задержку сообщений, мы, наконец, выбрали RabbitMQ.Использование SpringCloud-Stream для интеграции RabbitMQ очень удобно~~~