Какой брокер сообщений выбрать?

Question

[HoHsi]

Добрый день!
Уже довольно долгое время играюсь с RabbitMQ, даже написал обертку над amqplib (node.js), но все чаще он мне кажется громоздким и непонятным (даже спустя пол года активного использования).

Сейчас разрабатываю сервис целиком завязанный на брокерах сообщений. Скорость записи-чтения не особо важна, но хотелось бы не сильно уступать RabbitMQ.

Отсюда и происходит сам вопрос, на какую альтернативу посмотреть в ближайшее время? Хотелось бы услышать плюсы и минусы всех вариантов.

Из требований:
* наличие клиентов для GO, Python и JS.
* приемлемая скорость работы (на уровне RabbitMQ)
* возможность настроить сервер, на хранение очередей на диске (в том числе и в sync режиме), что-бы при перезагрузке сервера ничего не потерялось

Comments

[Дмитрий Беляев]

не совсем уверен, что решит все Ваши задачи, но все же взгляните на ZeroMQ

[HoHsi]

Дмитрий Беляев: ZeroMQ не может хранить данные на диске, как я понимаю, и он не отказоустойчив. Как только сервер на***ется все данные потеряются.

Answer 1

[VovanZ]

Если не важна персистентность (не страшно иногда терять сообщения) - можете посмотреть на механизм PUB/SUB в Redis. Очень быстрый, легковесный и простой как три рубля. Клиенты для Redis, конечно же есть под все хоть сколько-нибудь популярные языки.

Comments

[HoHsi]

* возможность настроить сервер, на хранение очередей на диске (в том числе и в sync режиме), что-бы при перезагрузке сервера ничего не потерялось

наоборот очень важна, даже важнее скорости

[VovanZ]

HoHsi: прошу прощения, невнимательно читал. Ну тогда, наверное, альтернатив RabbitMQ нет.

[VovanZ]

HoHsi: а может быть, вам вообще не нужен брокер сообщений, а достаточно базы данных? :)

Answer 2

[Iron Bug]

Если хотите другой брокер, то их много. На любой вкус и цвет. Хотя сам пользуюсь rabbitmq, рекомендую обратить внимание на kafka.apache.org

Если хотите без выделенного сервера, посмотрите в сторону akka. Работает быстрее, чем через брокер, умеет хранить состояние и еще кучу всего.

Answer 3

[Dimonchik]

так их всего два - второй ZeroMQ
Gearman, увы, слишком прост

на хабре достаточно статей, плюс, например
docs.celeryproject.org/en/latest/getting-started/i...

Comments

[HoHsi]

Дмитрий Беляев: ZeroMQ не может хранить данные на диске, как я понимаю, и он не отказоустойчив. Как только сервер на***ется все данные потеряются.

[HoHsi]

А адекватная реализация селари, только на Python. + сам по себе селари не брокер, а лишь обертка над другими брокерами

[Dimonchik]

ну а шо делать, это ж не от хорошей жизни
выкручиваются, как могут: ruhighload.com/post/%D0%A4%D0%B5%D0%B9%D0%BB%D0%BE...

[HoHsi]

dimonchik2013: гирман - вообще поделка для PHP

[Dimonchik]

там принцип описан )) про гирман я ж выше написал

[HoHsi]

dimonchik2013: дык, костыль же. RabbitMQ умеет это из коробки

[Dimonchik]

ну, еще раз: "не от хорошей жизни". В чем-то проигрыш. Сделать сохранение не проблема, проблема с гарантированным временем доступа.

посмотрите выступления Аксенова (сфинкс), он хорошо расскзаывает, что внутри баз данных и вообще

просто инструменты выбираются под задачу, и где-то на такие потери можно забивать (те же логи), где-то - нельзя (интересно, там где "нельзя", вообще можно ли очереди в контексте использовать)

[HoHsi]

dimonchik2013: в моем случае нельзя. У меня долгоживущие задачи, т.е. по факту у меня не очень много сообщений, просто они долго выполняются.

[Dimonchik]

ну вот Вы и нашли ответ )