RabbitMQ — это промежуточное программное обеспечение для сообщений с открытым исходным кодом, написанное на Erlang и основанное на протоколе AMQP;
Вы можете использовать его для: разделения, асинхронности, ограничения пиков.
Преимущества: развязка, асинхронность, ограничение пиков;
Недостатки: Сниженная стабильность системы: раньше система работала хорошо, но теперь вам нужно добавить в нее очередь сообщений. Если очередь сообщений зависнет, ваша система выйдет из строя. В результате доступность системы снижается;
Увеличивает сложность системы: добавление очереди сообщений требует большего рассмотрения многих аспектов, таких как: проблемы согласованности, способы обеспечения того, чтобы сообщения не использовались повторно, как обеспечить надежную передачу сообщений и т. д. Следовательно, есть что учитывать, и сложность увеличивается.
(1) Асинхронная связь между службами
(2) Последовательное потребление
(3) Запланированные задачи
(4) Запросить пиковое сокращение
Broker: Проще говоря, это объект сервера очереди сообщений. Exchange: Переключатель сообщений, определяющий правила, согласно которым сообщения направляются в какую очередь. Queue: Носитель очереди сообщений, каждое сообщение будет помещено в одну или несколько очередей. Binding: обязательность, его функция — установка очереди обмена согласно правилам маршрутизации обязательность Routing Key: Ключевое слово маршрутизации, Exchange доставляет сообщения на основе этого ключевого слова. VHost: vhost Можно понимать как виртуальный broker ,Прямо сейчас mini-RabbitMQ сервер. Он содержит независимые queue、exchange и binding и т. д., но самое главное, что у него есть независимая система разрешений, которая может vhost Объем пользовательского контроля. Конечно, из RabbitMQ Глобальная перспектива vhost Его можно использовать как средство изоляции различных разрешений (типичным примером является то, что разные приложения могут запускаться в разных vhost середина). Producer: Производитель сообщений — это программа, которая доставляет сообщения Consumer: Потребитель сообщений — это программа, которая принимает сообщения Channel: Канал сообщений, в каждом соединении клиента может быть установлено несколько каналов, каждый канал представляет собой задачу сеанса. Exchange, Queue и RoutingKey определяют уникальный маршрут от Exchange к очереди.
broker
относится к одному или нескольким erlang node
логическая группировка node
бежит дальше RabbitMQ
приложение.
cluster
находится в broker
На основе node
Ограничения на обмен метаданными между собой.
Queue иметь свой собственный erlang процесс;exchange Внутренне реализовано как сохранение binding Справочная таблица каналов связи; Это организация, которая на самом деле выполняет работу по маршрутизации, Прямо сейчас отвечает за подписку routing_key Воля message доставлено в queue . Зависит от AMQP Из описания протокола видно, что канал это правда TCP виртуальные соединения поверх соединений, все AMQP Все команды передаются channel отправлено, и каждый channel Есть только один ИДЕНТИФИКАТОР. один channel Может использоваться только одним потоком операционной системы, поэтому он доставляется в конкретный channel на message Есть заказ. Однако один поток операционной системы позволяет использовать несколько channel 。
vhost
Можно понимать как виртуальный broker
,Прямо сейчас mini-RabbitMQ server
。Он содержит независимыеиз queue
、exchange
и binding
и т. д., но самое главное, что у него есть независимая система разрешений, которая может vhost
Объем пользовательского контроля. Конечно, из RabbitMQ
глобальная перспектива,vhost
Его можно использовать как средство изоляции различных разрешений (типичным примером является то, что разные приложения могут запускаться в разных vhost
середина).
Из-за больших затрат на создание и уничтожение TCP-соединений.,А количество параллелизма ограничено системными ресурсами.,Вызовет узкие места в производительности. RabbitMQ использует каналы для передачи данных. Канал — это виртуальное соединение, установленное внутри реального TCP-соединения.,И нет ограничений на количество каналов для каждого TCP-соединения.
Если на очередь подписывается хотя бы один потребитель, сообщение Воля отправляется потребителю в циклическом порядке. Каждое сообщение будет распространяться только одному подписанному потребителю (при условии, что потребитель может обработать сообщение и подтвердить его обычным способом).
концептуально,информациямаршрутизация Должно быть три части:выключатель、маршрутизация、обязательность。Продюсер публикует сообщениевыключательначальство;обязательность Определяет способ отправки сообщениямаршрутизацияустройствомаршрутизацияк конкретномуочередь;Сообщение наконец приходиточередь,и получены потребителями.
Когда сообщение публикуется на выключателе, сообщение Воля имеет ключ маршрутизации (routing key), устанавливается при создании сообщения. Очереди можно привязать к коммутаторам с помощью ключей маршрутизации очереди. После того, как сообщение достигнет выключателя, RabbitMQ сопоставит ключ маршрутизации сообщения со строкой Соответствующие ключи маршрутизации (для разных коммутаторов существуют разные правила маршрутизации). Если если может соответствовать очереди, сообщение будет доставлено соответствующей очередисередина, если если не может соответствовать ни одной очереди, сообщение Воля Входить; «Черная дыра».
Обычно используемые переключатели в основном делятся на три типа:
direct
:еслимаршрутизация Ключ точно совпадает,Сообщение доставляется в соответствующую очередьfanout
:есливыключательполучатьинформация,Воля будет транслироваться всем обязательность очередиtopic
:Можетделатьиз разных источниковизинформацияспособен достичь того жеочередь。использоватьtopicвыключательчас,Можетиспользовать Подстановочный знак。
например:"*" Сопоставьте любой текст в определенной позиции, “.” Разделите ключ маршрутизации на несколько частей, "#" Соответствует всем правилам и т. д.
Особое примечание: сообщения, отправляемые в выключатель темы, не могут произвольно устанавливать ключ выбора (routing_key) и должны состоять из серии идентификаторов, разделенных знаком ".".в Африке cluster
В этом режиме метаданные в основном делятся на Queue
Метаданные (очередь Имя и атрибуты и т. д.)、Exchange
Юаньданные(exchange имя、тип и атрибут и т. д.)、Binding
Юаньданные(магазинмаршрутизацияреляционная таблица поиска)、Vhost
Юаньданные(vhost Ограничения пространства имен и настройки атрибутов безопасности для первых трех в пределах области).
существовать cluster
режим, также включает cluster середина node информация о местоположении node информация об отношениях. Метаданные следуют erlang node Определение типа сохраняется только в RAM середина,Все тот жечасдержатьсуществовать RAM и disk начальство。Юаньданныесуществовать cluster середина Это все node распределено.
Ответ: Когда вы существуете node Заявление о queue когда, пока node Если соответствующие метаданные будут изменены,вы получите Queue.Declare-ok отвечать;исуществовать cluster Заявление о queue, то требуется cluster навсе node Все метаданные должны быть успешно обновлены для получения Queue.Declare-ok отвечать. Кроме того, если node Тип RAM node Тогда измененные данные сохраняют существующую память только в том случае, если Тип disk node Тогда вам также необходимо изменить место сохранения на данных диске.
мертвое письмоочередь&мертвое письмовыключатель:DLX полное имя(Dead-Letter-Exchange),позвони этомертвое письмовыключатель,когдаинформациястатьмертвое После письма, если эта новость будет существовать, в свою очередь, параметр, то он будет отправлен на выключатель, соответствующий значению x-dead-letter-exchange. Этот выключатель называется мертвым. письмовыключатель,С этим мертвым письмовыключательобязательностьизочередьто естьмертвое письмоочередь。
RabbitMQиспользовать Режим подтверждения отправителя,убеждатьсяинформация Правильно отправлено наRabbitMQ。
Режим подтверждения отправителя:Воля Канал настроен наconfirm
модель(Режим подтверждения отправителя),Тогда всем сообщениям, опубликованным на канале существования, будет присвоен уникальный идентификатор. Как только сообщение будет доставлено в пункт назначения, очередь,Или после записи сообщения на диск (постоянное сообщение),Канал отправит продюсеру подтверждение.(ВключатьинформациятолькоID)。еслиRabbitMQ
Произошла внутренняя ошибка из-заипривести кинформацияпотерянный,отправлюnack
(not acknowledged,Неподтверждено) информация. Режим подтверждения отправителя асинхронный.,Заявка производителя существует в ожидании подтверждения,Вы можете продолжить отправку информации, когда сообщение с подтверждением достигнет приложения-производителя.,Для обработки информации подтверждения будет запущен метод обратного вызова приложения-производителя.
Механизм подтверждения сообщения получателя: потребитель должен подтвердить получение каждого сообщения (прием сообщения и подтверждение сообщения — это две разные операции). Только потребитель подтверждает сообщение,RabbitMQ
безопасноинформацияоточередьсерединаудалить.Супер здесь не используетсячасмеханизм,RabbitMQ
только черезConsumer
изсоединятьсередина Прервите, чтобы подтвердить, требуется ли повторная отправкаинформация.такжето естьобъяснять,Пока связь не разорвана,RabbitMQ
отдалConsumer
достаточно долгоизчасвремя для обработкиинформация.
Вот некоторые особые ситуации:
Давайте сначала поговорим о том, почему происходит повторное употребление: при нормальных обстоятельствах.,Когда потребители существуют, потребляют новости,После употребления,На сообщение будет отправлено подтверждающее сообщение.,messageturn будет знать, что сообщение было использовано,Сообщение будет удалено из сообщения очередисередина;
Однако из-за сбоев передачи данных по сети и т. д.,Информация о подтверждении не была доставлена в сообщение.,В результате сообщение, в свою очередь, не знает, что оно уже использовало сообщение.,И снова сообщение распространяется среди других потребителей.
В ответ на вышеупомянутые проблемы одним из решений является: обеспечить уникальность сообщения, даже если оно передается несколько раз, не допускать влияния многократного потребления сообщения; обеспечить идемпотентность сообщения;
Например: существует, записывает сообщение, используя данные в качестве единственного идентификатора.,При потреблении сообщений,Определите, было ли оно использовано, на основе уникального идентификатора;
Ненадежные сообщения могут быть вызваны потерей сообщения, его перехватом и т. д.;
Потери далее подразделяются на: потерю сообщений производителя, потерю сообщений в списке сообщений и потерю сообщений потребителем;
Производитель теряет сообщения: с точки зрения производителя, теряющего данные, RabbitMQ поставлять transaction и confirm Шаблон, гарантирующий, что производители не потеряют сообщения;
transaction Механизм такой: перед отправкой сообщения запустите транзакцию (channel.txSelect()), Затем отправьте сообщение, и если в процессе отправки возникнет какое-либо исключение, транзакция будет отменена (channel.txRollback()), Если отправка прошла успешно, зафиксируйте транзакцию (channel.txCommit()). Однако у этого подхода есть недостаток: снижается пропускная способность;
confirm Наиболее часто используемый режим: один раз channel Входить confirm режиме всем сообщениям, опубликованным на этом канале, будет присвоен уникальный идентификатор (от 1 Старт), как только сообщение будет опубликовано во всех соответствующих очередях;
RabbitMQ отправит производителю ACK (содержащий уникальный идентификатор сообщения), что позволит производителю узнать, что сообщение правильно прибыло в очередь назначения;
Если RabbitMQ не сможет обработать сообщение, он отправит вам сообщение Nack, и вы сможете повторить операцию.
Очередь сообщений теряет данные: сохранение сообщений.
Чтобы справиться с ситуацией потери данных в очереди сообщений, обычно необходимо включить настройку постоянного диска.
Эта конфигурация персистентности может confirm В сочетании с этим механизмом вы можете сохранить сообщение на диске, а затем отправить его производителю. Ack Сигнал.
Таким образом, если RabbitMQ умрет до того, как сообщение будет сохранено на диске, производитель не получит сигнал Ack и автоматически отправит сообщение повторно.
Так как же это сохранить?
Кстати, это на самом деле очень просто, достаточно выполнить следующие два шага:
После установки этого,Прямо сейчасделать rabbitMQ Если он зависнет, данные можно будет восстановить после перезагрузки.
Потребители теряют сообщения. Потребители обычно теряют данные, потому что используют режим автоматического подтверждения сообщения. Просто подтвердите сообщение вручную!
После того, как потребитель существует, получит сообщение,Перед обработкой сообщения,Автоматически ответит RabbitMQ Сообщение получено;
Если в этот момент обработка сообщения завершится неудачно, оно будет потеряно;
Решение. После успешной обработки сообщения вручную ответьте подтверждающим сообщением.
Однопоточное потребление обеспечивает порядок сообщений, которые пронумерованы, и потребитель обрабатывает сообщения в соответствии с номерами;
Сообщение о мертвом письме:
Сообщение отклонено (Basic.Reject или Basic.Nack), а для параметра requeue установлено значение false. Срок действия сообщения истек Очередь достигла максимальной длины
Просроченная новость:
существовать rabbitmq Существует два способа установить срок действия сообщения. Первый — установить срок действия сообщения. После этой настройки будет установлен срок действия сообщения. ьсередина Все сообщения имеют одинаковый срок действия. Второй способ — установить само сообщение, поэтому срок действия каждого сообщения разный. Если вы используете эти два метода одновременно, значение с меньшим сроком действия будет иметь преимущественную силу. Когда срок действия сообщения истекает и оно не было использовано, оно становится мертвое письмо информация.
Настройки очереди: существованиеповорот используется, когда вы делаете заявление x-message-ttl Параметр, единица измерения миллисекунда
Индивидуальные настройки сообщений: Это установка свойств сообщения expiration Значение параметра, в единицах миллисекунда
Очередь задержки: существованияrabbitmqсередина не имеет задержки существования очереди, но мы можем установить время истечения имертвого сообщения буквочередь для имитации задержки поворота. Потребитель слушает мертвое письмовыключательобязательность по очереди вместо прослушивания сообщений, отправленных по очереди.
Имея базовые знания на, мы выполняем следующие требования:
Требование: Пользователь существует система середина создает заказ,если Пользователь не оплатил по истечении срока,Тогда заказ автоматически отменяется.
анализировать:
1. В приведенной выше ситуации мы можем использовать очередь задержки для ее реализации. Итак, как создать очередь задержки? 2. Очередь задержки может быть Просроченная новость+мертвое письмоочередь Приходи время 3. Просроченные сообщения устанавливаются через очередьсередина. x-message-ttl Реализация параметра 4、мертвое письмоочередьпроходитьсуществоватьочередь Заявлениечас,Установить на поворот x-dead-letter-exchange параметры, а затем дополнительно объявить очередь, привязанную к обмену, соответствующему x-dead-letter-exchange.
1. Снижение доступности системы: что вы думаете?,Первоначально, пока другие системы работали нормально,,Тогда ваша система в норме. Теперь вам нужно добавить сообщение в свою очередь,Эта новостная очередь мертва,Ваша система больше не работает должным образом. поэтому,Сниженная доступность системы
2. Повышенная сложность системы: необходимо учитывать многие аспекты, такие как проблемы согласованности, способы обеспечения того, чтобы сообщения не использовались повторно, и как обеспечить надежную передачу сообщений. Таким образом, появляется больше вещей, которые необходимо учитывать, и сложность системы увеличивается.
Если у потребителя есть x сообщений и он не отвечает на ACK, этому потребителю больше не будут отправляться сообщения.
channel.basicQos(int x)
Я не знаю, любишь ли ты солнечные дни или дождливые, но ты мне нравишься каждый день.