Какое решение лучше справляется со сценарием «издатель/подписчик»?

Сценарий — издатель/подписчик, и я ищу решение, которое может обеспечить возможность отправки одного сообщения, сгенерированного ОДНИМ производителем, МНОЖЕСТВУ потребителей в режиме реального времени. Чем легче этот сценарий может быть обработан одним решением, тем лучше!

В случае серверов AMQP я проверил только Rabbitmq и использовал сервер rabbitmq для шаблона pub/sub, каждый потребитель должен объявить анонимную частную очередь и привязать ее к разветвленному обмену, поэтому в случае, если тысячи пользователей потребляют одно сообщение в реальном времени. времени будут тысячи или около того анонимных очередей, обрабатываемых rabbitmq.

Но мне действительно не нравится подход rabbitmq. Было бы идеально, если бы rabbitmq мог обрабатывать этот сценарий pub/sub с одной очередью, одним сообщением, многими потребителями, слушающими одну очередь!

что я хочу спросить, так это то, какой сервер AMQP или решения другого типа (любые подобные, включая серверы XMPP или Apache Kafka или ...) лучше и намного эффективнее обрабатывают шаблон/сценарий pub/sub, чем RabbitMQ, потребляя (конечно) меньше ресурс сервера?

предпочтения в порядке интереса:

  1. в случае, если сервер с поддержкой AMQP обрабатывает сценарий публикации/подписки только с ОДНИМ или МЕНЬШИМ числом очередей (как объяснено)

  2. легко обрабатывать тысячи потребителей, потребляя меньше ресурсов сервера по сравнению с другими решениями в шаблоне pub/sub

  3. кластеризация, допускающая отказ узлов

  4. Многие языковые привязки (по крайней мере, Python и Java)

  5. прост в использовании и администрировании

Я знаю, что мой вопрос может быть ОЧЕНЬ общим, но я хотел бы услышать идеи и предложения для паба/подкаталога.

благодаря.


apache-kafka rabbitmq publish-subscribe amqp xmpp
person Reza Rasouli    schedule 18.05.2014    source источник

Ответы (1)


arrow_upward
1
arrow_downward

В общем, для RabbitMQ, если вы поместите пользователя в routing key, вы сможете использовать один exchange, а затем небольшое количество queue (даже один, если хотите, но вы можете разделите их по серверу или аналогичному, если это имеет смысл с учетом вашей настройки).

Если вам не нужен guaranteed order (как, например, для гарантии того, что ограничения FK не будут затронуты для последовательности изменений в различных таблицах базы данных SQL), то нет причин, по которым вы не можете иметь кучу consumers рисунков из одной очереди.

Если вам нужен сценарий типа широковещательного сообщения, то, возможно, это можно было бы обработать немного по-другому. Вместо одного пользователя в routing key, который вы могли бы использовать для сообщений нешироковещательного типа, создайте специальный тип пользователя, скажем, __broadcast__, которого на самом деле не может быть ни у одного пользователя, и пусть пользователи широковещательная передача хранится в полезной нагрузке сообщения вместе с самим сообщением.

Затем ваш код обработки сообщений может позаботиться о размещении этого сообщения в базе данных (или в любом другом месте конечного назначения) для всех этих пользователей.

Редактировать в ответ на комментарий от OP:

Таким образом, routing key может выглядеть примерно так: message.[user], где [user] может быть фактическим пользователем, если бы это было двухточечное сообщение, и специальное __broadcast__ > user (или аналогичное имя пользователя, которое фактическому пользователю не будет разрешено зарегистрировать), что будет указывать на сообщение в стиле широковещательной рассылки.

Затем вы можете поместить пользователей, которым должно быть доставлено сообщение, в payload сообщения, а затем содержимое этого сообщения (которое также будет в payload) может быть доставлено каждому пользователю. Механизм для этого будет зависеть от вашего конечного пункта назначения. т. е. сообщения в конечном итоге сохраняются в Postgres, Mongo DB или подобном?

person khampson    schedule 19.05.2014
comment
можно поточнее? что ты имеешь в виду под put the user in the routing key ? Я не понял связи с обменом и небольшим количеством очередей. было бы очень признательно, если бы вы могли объяснить больше. и, как уже упоминалось, сценарий отправляет одно сообщение по одной очереди всем потребителям, гарантируя, что все потребители получат копию этого сообщения и сообщения после этого. если вы можете указать на какую-либо документацию, это тоже будет хорошо. кстати спасибо за ответ :) - person Reza Rasouli; 19.05.2014
comment
Уточнено выше; также вопрос о том, каков конечный пункт назначения сообщений. - person khampson; 20.05.2014