Это урок, который мы должны усвоить основные понятия, такие как Очередь очереди сообщений, тем, разделы. Эти концептуальные основы, как мы узнаем базовый синтаксис языка программирования, как вы только знаете их все, для того, чтобы проводить последующие исследования.
Если вы изучаете больше чем одно сообщение массового обслуживания продукта, вы можете заметить, что каждый из очереди сообщений имеет свой собственный набор модели сообщений, как очереди (Queue) Тема (Тема) или раздела (Partition) Эти термины и понятия, в каждая модель очереди сообщений будет включать в себя какой-то смысл и не то же самое.
Почему такая ситуация? Потому что нет никакого стандарта. В свое время, есть также целый ряд международных организаций, старается развивать с помощью сообщений, связанных стандартов, таких как ранний JMS и AMQP. Но разочарование в том, что стандартная скорость эволюции развивалась, чтобы не отставать очереди сообщений, эти стандарты фактически отказались.
Так, в конце концов, что это очередь? Что такое тема? Темы и очереди, какая разница? Хочу, чтобы полностью понять это, мы должны говорить об эволюции из очереди сообщений.
Темы и очереди Какая разница?
Архитектор круг в середине Интернета, распространение такого не знает, источник цитаты, я очень согласен и любовь: хорошая архитектура не предназначена, а эволюционировала из. Современные очереди сообщений, показывающий рисунок такой же, как и раньше, после десяти лет постепенно эволюционировали.
Оригинальный очереди сообщений, очередь на строгом смысле этого слова. В компьютерной области, «очередь (очередь)» представляет собой структуру данных, полное и строгое определение. Wikipedia, очередь определяется следующим образом:
Очереди буфер FIFO (FIFO, First-In-First-Out) линейная форма (линейный список). Как правило, с использованием массива или связанного списка в конкретных приложениях. Только задний конец очереди (задний) называют вставки операции, операция удаления в переднем конце (упоминается как спереди).
Это определение, которое содержит несколько ключевых моментов, то первый из них является первым в первом из, есть требование означает, что в новостях команды в процесс команды, необходимо убедиться, что эти сообщения являются строгими и упорядоченно, в каком порядке записываются в очередь Он должен быть считан из очереди в том же порядке. Однако очередь не «читать» эту операцию, «читать» это команда, которая является «удалить» сообщение из очереди.
В начале очереди сообщений, в соответствии с «очереди» структура проектных данных. Вместе мы смотрим на этой цифре, продюсер (продюсер) является операцией сообщения Епдиеей, потребитель (Consumer) получил сообщение команды, которая является операция удаления, сообщение сервера контейнера для хранения, естественно, называется «очередь.»
Это первый из модели обмена сообщениями: модель массового обслуживания.
Если есть несколько производителей отправка сообщений в ту же очередь внутри, эта очередь может потребить сообщение, сообщение представляет собой совокупность всех этих производителей производят. Эти последовательности производителей сообщения передаются в сообщении естественного порядка. Если есть несколько потребителей получать ту же очередь сообщений, отношения между этими потребителями фактически конкурировали, каждый потребитель может получить только часть очереди сообщений, что любой из них может быть только сообщением потребитель получает.
Если вам нужна копия данных сообщений, распределенных по нескольким потребителям, она требует, чтобы каждый потребитель может получить полную сумму сообщений, например, в течение данных заказа, системы управления рисками, аналитических систем, платежных систем и поэтому должны получить сообщение. На этот раз, одна очередь не будет удовлетворять спрос, возможное решение создать отдельную очередь для каждого потребителя, так что производители отправить несколько копий.
Очевидно, что это относительно глупый подход, то же копия данных сообщения копируется в нескольких очередей будет тратой ресурсов, что еще более важно, производители должны знать, сколько потребителей. Отправить сообщение для каждого отдельного потребителя, который фактически противоречит очереди сообщений «развязке» предназначен.
Чтобы решить эту проблему, модель эволюционировала еще одно сообщение: «опубликовать - подпишитесь модель (издатель-подписчик)».
В опубликовывать - подписаться модель, отправитель сообщения называется издателя (Publisher), получатель сообщения вызываемого абонента (Subscriber), контейнер для хранения сервер называется тему новостей (тема). Издатели отправлять сообщения в тему, абоненты должны «подписаться на тему» до получения сообщения. «Подписаться» здесь как действие, но также может рассматриваться как логическая копия темы на момент потребления, каждая подписка, абоненты могут получать все темы новостей.
В истории поля сообщения в течение длительного периода времени, режим очереди и публикация - подписаться модели сосуществуют, некоторые поддерживают очереди сообщений обе модели обмена сообщений, такие как ActiveMQ. Мы тщательно сравнить эти две модели, издатель является производителем, потребителем является абонентом, очередь является объектом, и нет существенной разницы. Самая большая разница между ними на самом деле, данные сообщения не могут быть проблемой потребительского много раз.
На самом деле, в этом публиковать - подписаться модель, если только один абонент, и модель очереди, что она в основном такая же, как. Другими словами, публикации - подписаться модель на функциональном уровне, совместимая модель очереди.
Современные модели сообщений в продуктах очереди сообщений в основном используются в этой публикации - подписаться модели, конечно же, есть исключения.
модель обмена сообщениями RabbitMQ
Исключением является RabbitMQ, это несколько по-прежнему настаивают на использовании очередей модель одного из продуктов. То есть, как это решает проблему потребителей делать? Как вы помните, я говорил о RabbitMQ является особенностью модуля обмена на уроке? В RabbitMQ, обмен находится между производителями и очередями, производители не заботится, которые в очереди, чтобы отправлять сообщения, но отправить сообщение на биржу, политика определяются конфигурацией биржи, которая будет сообщение доставлено в очередь.
Если же копия сообщения должна быть больше потребителей тратить деньги, вам нужно настроить обмен для отправки сообщения в несколько очередей, каждая из которых хранятся в полных данных сообщений, может обеспечить потребительские услуги потребителю. Это также может быть достигнуто в маскировке новой версии - модель подписки, «а данные сообщения могут быть во много раз больше абонентов , чтобы потреблять» эту функцию. Вы можете обратиться к конкретной конфигурации RabbitMQ официального учебника, где глава конкретно о том , как опубликовать подписку.
Модель новости RocketMQ
модель обмена сообщениями RabbitMQ закончена, давайте посмотрим на RocketMQ. RocketMQ модель сообщений с использованием стандарта публиковать - подписаться модель, в RocketMQ глоссарии, производители, потребители и темы и я говорю в вышеупомянутом высвобождении - Подписка Концепция модели в точности то же самое.
Однако, в RocketMQ также имеет это понятие очереди (Queue), и очередь является очень важным понятием в RocketMQ в этой очереди RocketMQ какую роль это? Это из очереди сообщений потребления механизма говорит.
Почти все продукты очереди сообщений используют очень простой - механизм «запрос подтверждения», чтобы гарантировать, что сообщения не будут потеряны из-за сети или сбоя сервера в процессе передачи. Специфический подход очень прост. В конце производства, производитель первое сообщение отправляется на сервер, то есть брокер, сервер отправляет сообщение после получения сообщения или тему очереди письма, производитель посылает подтверждение ответа.
Если производители не получают подтверждение или ответ о сбое сервера получен, то устройство будет посылать сообщение, на конечном потребителе, потребитель после получения сообщения и завершить свою бизнес-логику потребителя (например, для сохранения данных в базе данных) , будет отправлен к конечному потребителю услуг успешного подтверждению, сервер только после получения подтверждения потребления, просто думает, что сообщение успешно потребление, в противном случае это даст потребителям повторно отправить сообщение, пока вы не получите успешное подтверждение потребления, соответствующие.
Механизм подтверждения хороший способ обеспечить надежность процесса доставки сообщения, однако, введение этого механизма в конце потребительского принесло большую проблему. В чем проблема? В целях обеспечения упорядоченного характера сообщения, сообщение до потребителя успешна, то следующее сообщение не может быть израсходовано, в противном случае сообщение будет пустым, вопреки порядку этого принципа.
То есть, каждая тема в любое время, в лучшем случае только один экземпляр ведения потребительских расходов, было бы невозможно улучшить общий уровень потребительских конечного потребителя производительности по количеству потребителей расширения. Чтобы решить эту проблему, RocketMQ в следующих разделах добавлено понятие очереди.
Каждая тема включает в себя множество очередей, реализовать несколько экземпляров производства и потребления посредством множества параллельных очередей. Следует отметить, что RocketMQ только обеспечить упорядоченное очереди сообщений на уровне темы нет никакой гарантии, что сообщение о строгом порядке.
RocketMQ, концепция абонентов через группу потребителей (Consumer Group) воплощаться. Каждый потребитель темы группы потребителей в полном сообщении, прогресс потребления среди различных групп потребителей влияют друг на друга, то есть, сообщение является потребление потребительских Group1 тоже даст потребление потребительских GROUP2.
Потребительская группа содержит множество потребителей в пределах те же группы потребителей является взаимосвязь между потреблением конкуренции, каждый потребитель несет ответственность за часть сообщения внутри группы потребителей. Если сообщение потребляется потребители Consumer1, та же группа, что и другие потребители больше не будут получать это сообщение.
Тема процесса потребления, поскольку сообщение должно быть различным набором множественного потребителя, так что потребитель не завершает сообщение и немедленно быть удален, что требует расхода RocketMQ для каждой группы потребителей поддерживает позицию по каждой очереди ( потребитель Offset), прежде чем новости этой позиции должны быть потреблены до, после того, как новости не потребляются, для каждого успешного потребления сообщений, место потребления является плюсом. Положение потребителя является очень важным понятием, когда мы используем очередь сообщений, поскольку сообщения теряются в основном из-за неправильное обращение потребителя места.
RocketMQ модель сообщение, тем более важным является то, что эти понятия. Для того, чтобы облегчить понимание, я нарисовал картину ниже:
Вы можете контролировать эту картину, а потом я просто сказать, что эти концепции продолжают переваривать и углубить понимание.
Модель сообщение Кафки
Давайте посмотрим на другой общей очереди сообщений Кафки и RocketMQ Кафка модель сообщения точно так же, понятие всех RocketMQ я просто говорю в соответствующем механизме подтверждения и процесса производства и потребления, в полной мере применимы к Кафке. Единственное отличие состоит в том, что в Кафке, имя очереди этой концепции не то же самое, соответствующее имя Кафка «разделы (раздела)», смысл и функция ничем не отличается.
резюме
Резюмируем содержание этого урока, чтобы узнать. Во-первых, мы говорили о разнице между очередями и тем, за эти два понятия фактически соответствуют двум различным моделям обмена сообщениями: модели массового обслуживания и публикации - подписаться модель. Тогда вы должны понимать, что эти две новости модели на самом деле не принципиально разные, доступны через ряд изменений, чтобы продлить или заменить друг друга.
Общие очереди сообщений, используется модель очереди RabbitMQ, но он все еще может достичь опубликовать - функцию подписки. RocketMQ и Кафка использует публикации - подписки модель, и обе модели являются в основном то же самое сообщение.
Наконец, чтобы напомнить вам, я говорю об этой модели сообщения урока и связанное с ним понятие бизнес-модель уровня, глубокое понимание бизнеса-модель поможет вам с лучшей осанкой использовать очереди сообщений.
但业务模型不等于就是实现层面的模型。比如说 MySQL 和 Hbase 同样是支持 SQL 的数据库，它们的业务模型中，存放数据的单元都是“表”，但是在实现层面，没有哪个数据库是以二维表的方式去存储数据的，MySQL 使用 B+ 树来存储数据，而 HBase 使用的是 KV 的结构来存储。同样，像 Kafka 和 RocketMQ 的业务模型基本是一样的，并不是说他们的实现就是一样的，实际上这两个消息队列的实现是完全不同的。
思考题
最后给大家留一个思考题。刚刚我在介绍 RocketMQ 的消息模型时讲过，在消费的时候，为了保证消息的不丢失和严格顺序，每个队列只能串行消费，无法做到并发，否则会出现消费空洞的问题。那如果放宽一下限制，不要求严格顺序，能否做到单个队列的并行消费呢？如果可以，该如何实现？欢迎在留言区与我分享讨论。