Зачем нам нужен RabbitMQ, когда у нас есть более мощная сетевая структура в Python под названием Twisted. Я пытаюсь понять причину, по которой кто-то захочет использовать RabbitMQ.
Не могли бы вы предоставить сценарий или пример с помощью RabbitMQ?
Кроме того, где я могу найти учебник по использованию RabbitMQ?
Позвольте мне сказать вам несколько причин, которые делают использование MOM (Message Oriented Middleware), вероятно, лучшим выбором.
Он может разделить/разделить основные компоненты приложения. Здесь нет необходимости использовать все преимущества развязанной архитектуры. Я просто хочу указать на то, что это одно из основных требований к написанию качественного и поддерживаемого программного обеспечения.
На самом деле очень просто соединить два совершенно разных приложения, написанных на разных языках, с использованием протокола AMQP. Эти приложения будут разговаривать друг с другом с помощью "переводчика", который является MOM.
Используя MOM, мы можем масштабировать систему по горизонтали. Один производитель сообщений может передавать неограниченному количеству потребителей сообщений задачу, команду или сообщение для обработки и для масштабирования этой системы все, что нам нужно сделать, это просто создать новых потребителей сообщений. Допустим, мы получаем 1000 снимков в секунду, и мы должны изменить их размер. Решение этой проблемы традиционными методами может быть головной болью. С помощью MOM мы можем передавать изображения потребителям сообщений, которые могут выполнять свою работу асинхронно и гарантировать целостность данных.
Это другие преимущества использования MOM, но эти 3 являются самыми значительными, на мой взгляд.
Twisted не является реализацией очереди. Кроме того, RabbitMQ предлагает функции очередности на уровне предприятия и реализует протокол AMQP, который часто необходим в корпоративном мире.
Twisted - это сетевая библиотека, которая реализует ряд сетевых протоколов, а также позволяет создавать свои собственные. Одним из протоколов, которые можно использовать с Twisted, является AMQP https://launchpad.net/txamqp
RabbitMQ является брокером AMQP, то есть службами, которые работают за пределами вашего приложения, возможно, на отдельном кластере серверов. AMQP - это просто протокол, который используется для связи с брокером обслуживания сообщений, таким как RabbitMQ. Вы получаете много вещей от RabbitMQ. Вы можете отправлять сообщения настойчиво с гарантированной доставкой, чтобы они прибудут, даже если ваше приложение выйдет из строя, и даже если брокер RabbitMQ завершит перезагрузку. Вы получаете балансировку нагрузки между потребителями сообщений, если у вас несколько потребителей в одной очереди. Вы получаете возможность взаимодействия с приложениями на других языках, если вы используете разумно открытый формат сериализации для своих тел сообщений. AMQP позволяет разбить монолитное приложение на многие свободно связанные части, которые могут работать на разных серверах. Это большая победа для долгосрочного обслуживания приложения.
rabbitmq - это нечто большее, чем просто обмен сообщениями... его общая платформа, способная взаимодействовать с приложениями. Используя rabbitmq, приложение java может разговаривать с сервером linux и/или с .net-приложением, с рубином и рельсами + почти на все, что находит свое место в корпоративной веб-разработке. И самое главное, он реализует модель "огонь и забыть", предложенную AMQP. Его просто отличная замена для JMS или ESB... особенно если вы имеете дело с кросс-платформенной архитектурой, с гарантией надежности. Существует даже специальная функция RPC (Remote procedure call), которая добавляет к простоте разработки в распределенной арке.
Помимо всего этого, в мировых финансовых услугах, таких как фондовая биржа или рынок акций, где требуется много надежной и эффективной маршрутизации (предположите, что вы не знаете фактического отсутствия людей, подписанных на ваши услуги, но хотите обеспечить, чтобы кто когда-либо делает это, получает ваши сообщения о том, подключены ли они в этот момент или подключится позже), правила rabbitmq, поскольку он основан на ERLANG и платформе Open-telecom, которая обеспечивает высокую производительность при использовании минимальных ресурсов. Для наиболее удобного введения в rabbitmq см. Rabbitmq.com/getstarted.html для вашего родного языка разработки.
RabbitMQ представляет собой реализацию AMQP, которая определяет совместимый протокол для ориентированного на сообщения промежуточного программного обеспечения. Таким образом, он определяет семантику для создания сообщений, публикации, маршрутизации и потребления, которые могут быть реализованы на любой платформе.
Концептуально это можно было бы рассматривать как специализацию сетевого движка, такого как Twisted, но на основе общепринятого в отрасли стандарта.
Вот блог от Росса Мейсона, в котором обсуждается интерес интероперабельной публикации-подписки с AMQP: http://blogs.mulesoft.org/inter-operable-publishsubscribe-with-amqp/
Я использую RabbitMQ в качестве брокера сообщений для Celery.
Кроме того, я работал с Twisted. Это другое.
Подробнее см. здесь AMQP: http://en.wikipedia.org/wiki/Advanced_Message_Queuing_Protocol
Системы MQ, как правило, лучше всего работают в сценариях "огонь и забухание". Если событие происходит, а другие должны быть уведомлены об этом, но исходная система не нуждается в обратной связи с другими системами, тогда MQ может быть хорошо подходит.
Если вы понимаете плюсы и минусы MQ и до сих пор не понимаете, почему это было бы хорошо подходит для конкретной системы, то, вероятно, это не так. Я видел системы, в которых MQ использовался, но не нужен, и результат был некрасивым.
Одно из ключевых применений промежуточного ПО, таких как очереди сообщений, - это возможность отправлять данные между неоднородными системами. Сами сообщения могут быть разными. Строки легче всего понимать на разных языках на разных системах, но часто менее полезны для передачи более значимых данных. В результате JSON и XML очень популярны для сообщений. Это только структурированные строки, которые могут быть преобразованы в объекты на выбранном языке на стороне потребителя.
Дополнительные полезные функции:
Здесь приводятся некоторые, возможно, надуманные примеры. Java-программа в локальной системе хочет отправить сообщение в систему по подключенному через Интернет. В локальной системе есть сервер, подключенный к Интернету. Все заблокировано из Интернета, за исключением подключения к MQ. Программа Java может публиковать сообщение в MQ без необходимости доступа к Интернету. Сообщение находится в очереди до тех пор, пока внешняя система не заберет его. Программа Java публикует сообщение, скажем, XML, и потребитель может быть программой Perl. Пока у них есть некоторый способ понять XML с предопределенным способом сериализации и десериализации, все будет хорошо.
В принципе, тесно связанные программы хороши, если программа очень проста или есть некоторые специальные причины для использования тесно связанной программы.
В реальном мире все гораздо сложнее. Программы не могут быть такими простыми, и становится кошмаром для развития корпоративных приложений в тесном взаимодействии. Поэтому мы используем термин "слабосвязанный" для определения больших систем, которые состоят из множества небольших кусков. Части имеют четко определенные границы и функции, так что смена системы может быть выполнена более легко. Это суть объектно-ориентированного дизайна. Очереди сообщений (например, RabbitMQ) позволяют общаться по электронной почте между различными программами и частями программ, тем самым делая рабочий процесс намного более похожим на людей. Добавление дополнительной емкости становится простым вопросом запуска и дополнительного компьютера, где вам это нужно.
JMS (ActiveMQ - реализация брокера JMS) может использоваться как механизм, позволяющий обрабатывать асинхронные запросы. Вы можете сделать это, потому что запрос занимает много времени, или потому что несколько сторон могут быть заинтересованы в фактическом запросе. Еще одна причина для его использования - разрешить нескольким клиентам (потенциально написанным на разных языках) доступ к информации через JMS. ActiveMQ - хороший пример, потому что вы можете использовать протокол STOMP для доступа к клиенту С#/Java/Ruby.
Использование в реальном времени очередей JMS/сообщений:
Пример реального мира - это пример веб-приложения, которое используется для размещения заказа для конкретного клиента. В рамках размещения этого заказа (и хранения его в базе данных) вы можете выполнить ряд дополнительных задач:
Для этого ваш код приложения будет публиковать сообщение в очереди JMS, которая включает идентификатор заказа. Одна часть вашего приложения, слушающего очередь, может ответить на событие, взяв orderId, посмотрев порядок в базе данных и затем разместив этот заказ с другой сторонней системой. Другая часть вашего заявления может нести ответственность за получение заказа и отправку электронного письма клиенту.