Zmq vs redis для шаблона pub-sub

redis поддерживает pub-sub
zmq также поддерживает pub-sub через брокер сообщений

Какими будут архитектурные плюсы\минусы для выбора между ними?
Я нацелен на точки, которые выходят за рамки очевидного конкретного теста производительности, который должен быть выполнен (здесь хороший пример).

Предположим, что используется язык высокого уровня, такой как Python.

Ответы

Ответ 1

Я работал с ZeroMQ и Redis с python. Я бы сказал, что ZeroMQ более надежный, он предлагает реальную простую балансировку нагрузки, а также больше, чем pub-sub, например, запрос ответа среди других. Но если вы только после pub-sub, redis намного проще.

В случае сбоя или прекращения работы сервера redis все клиенты перестанут работать, а ZeroMQ работает, даже если сервера нет.

Обе службы доступны с любым языком программирования, ruby, python, C, С++ и т.д.

Короче говоря, redis намного проще, очень надежно. ZeroMQ является чрезвычайно надежным, но более сложным.

Если бы я только делал паб sub, я бы выбрал redis, иначе я бы выбрал ZeroMQ. Если бы я ожидал огромные нагрузки трафика, я бы выбрал ZeroMQ

Ответ 2

ZeroMq Pros/Cons

  • Pub/sub peers могут подключаться и разъединяться независимо; сообщения сохраняются в буферах на основе настроек HWM, автоматически отправляются при наличии доступа к сверстке (сохранение и пересылка).
  • Если сверстник терпит неудачу, буферизованные сообщения будут потеряны
  • Подписки по подписке поддерживают префикс, соответствующий только pub/sub enveloping; NEWS подписка соответствует NEWS* сообщениям

Redis Pros/Cons

  • Снимка снимка AOF на диске сохраняется в случае неудачи события
  • Pub/sub клиенты зависят от redis для подключения
  • Подстановочный знак для подписки на избранные темы, например news.*.

Ответ 3

Я сам это изучал, так как мне нужно было решить, использовать ли Redubs pubsub или ZMQ pubsub для уровня связи для распределенных систем. Я думаю, что Redis и ZMQ отличаются с точки зрения настройки приложения.

  • ZMQ pubsub врожденно соединяется напрямую, т.е. нет среднего человека.
    Вы можете создать экземпляр среднего человека, например, форвардерное устройство

  • Для Redis pubsub как подписчику, так и издателю необходимо подключиться к Redis.

Отсутствие среднего человека в ZMQ означает, что подписчику нужно как-то знать, чтобы подключиться к издателю, чтобы получить сообщение. В моей системе, где приложение запускает издателей, которым необходимо отправлять информацию подписчикам, нет никакого способа сделать это без наличия устройства-пересылки, к которому подключаются подписчики до того, как начнется мое приложение.

Задержка имеет значение в моей системе, поскольку я хочу, чтобы удаленные ящики делали все как можно быстрее.

Zmq (direct pubsub)
avg: 0.000235867897669
max: 0.0337719917297
min: 0.000141143798828

Zmq (w/ forwarder)
Avg: 0.00237249334653
max: 0.00536799430847
min: 0.000249862670898

Redis (8gb ram)
avg: 0.000687216520309
max: 0.0483138561249
min: 0.000313997268677

Redis (32gb ram)
avg: 0.000272458394368
max: 0.00277805328369
min: 0.000216960906982
  • Если ваше приложение находится на стороне абонента, где есть демон издателя, из которого вы хотите получить информацию, я бы пошел на ZMQ, потому что вы можете напрямую подключиться к издателю.
  • Если ваше приложение находится на стороне издателя, я перейду в Redis pubsub, потому что подписчики уже подключены к прослушиванию Redis.

Ответ 4

Вот как бы я решил. Делайте минимальные тестовые примеры с использованием каждого продукта. Посмотрите, что легче построить и работает лучше. Нажмите несколько тестовых примеров немного дальше, а затем отбросьте одну строку как слишком много работы.