Назад | Перейти на главную страницу

Какую очередь сообщений мне выбрать (должна работать в Linux)

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

Моя проблема проста - мне отправляют список файлов, которые нужно обработать. Каждое задание нельзя разделить, но оно самодостаточно и может быть распределено на несколько компьютеров.

Думаю решить эту проблему с помощью очереди сообщений. Несколько клиентов отправляют сообщение в центральную очередь. У каждой очереди есть несколько подписчиков, которые будут принимать задания из этой очереди после завершения обработки текущего задания.

В идеале он должен обладать следующими качествами

Может ли кто-нибудь предложить простую в использовании очередь сообщений?

У вас есть RabbitMQ и ZeroMQ, но afaik ZeroMQ не сохраняет необработанные сообщения в случае сбоя. Они оба с открытым исходным кодом и используют AMQP, открытый протокол обмена сообщениями.

очень просто использовать memcacheq, который использует тот же API, что и memcached, поэтому вы можете использовать те же библиотеки. он использует бэкэнд BDB, поэтому он не работает только с RAM, как memcached

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

Я сделал презентация на beanstalkd для локальной группы пользователей, у которой есть дополнительная информация.

Я только что прошел через это в своем последнем архитектурном планировании ...

В основном .. "очереди сообщений" .. у всех есть проблемы, которые ни одна из них не гарантирует обе следующие характеристики одновременно ..

Гарантия получения сообщения
Гарантия отсутствия повторяющихся сообщений

Итак, то, что в настоящее время предлагается как решение с открытым исходным кодом, не может выполнять эти две обязательные задачи одновременно ... (если вы не хотите потратить 50 КБ с IBM)

Есть одно отличное видео, в котором говорится, что cassandra может справиться с этим с помощью чтения / записи кворума, но не принимает во внимание параллелизм в больших масштабах: /

В конце концов я остановился на РЕДИС на самом деле (я избегал кластерного решения)

Просто и эффективно однопоточный .. (чтобы избежать дублирования) Предлагает атомарный BlockonPop или даже функцию многоадресной рассылки pubsubhubbub для работников очереди.

было разработано собственное решение для управления «потерянными рабочими местами», которые так и не появились .. (надежность)

На самом деле это довольно простая модель ... казалось бы, простая в обслуживании ...

Надеюсь это поможет..

Я использовал Beanstalkd для этого типа задач. Его можно настроить для сохранения заданий на диске между перезагрузками. Чтобы помочь с удалением дубликатов, я поместил идентификатор задания в memcached - если задание уже было в кэше памяти, удалите его, а не ставьте в очередь в Beanstalkd.