Какие сейчас Message Queue решения актуальны?

А что конкретно тебе нужно - передача сообщений между приложениями (условно IPC) или персистентная очередь с какими-то там гарантиямм доставки?

Нужна гарантия доставки сообщения (сообщения мелкие (символов 100)).

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

Нужно вынести вычисления в отдельный процесс который может упасть? Такое несложно делается на обычных пайпах. Если для поиграться, то можно посмотреть на zmq.

Я знаю и использую zmq, но тут у меня будут десятки тысяч сообщений и тысячи воркеров + выч. кластер (в котором ещё и машинки могут быть разные + добавлять при необходимости).

Было бы там с десяток воркеров и пиковая загрузка очередей небольшой - без проблем бы написал на zmq, написал миксер и радовался жизни. А тут хочется, чтобы всё это как-то сейвилось и баги за меня половили бы уже.

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

P.S. Поясню, если воркеры с потоком сообщений не справляются, то сообщения должны посейвится на диск, но не потеряться. Отследим, что кол-во сообщений растёт и добавим воркеров. Писать слой гарантировая доставки сообщений не хочется вот и всё. Поэтому и ищется, что-то более высокоуровневое чем zmq.

Kafka

ой ложи их в базу и не вые

Одна из первых ссылок в гугле:

Какие преимущества дает подобная архитектура? Во-первых, объем потребляемых данных определяется не брокером, а потребителем. Брокер не обладает никакой информацией насчет того, принял ли потребитель сообщение или нет. Однако для Kafka это не проблема, а преимущество: сообщение удаляется автоматически, если оно задерживается у брокера дольше определенного времени. При этом потребитель может в любой момент сделать «повторный заказ» на то или иное сообщение.

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

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

Кому должны? Мама велела? Воркер должен, как минимум, три вещи: 1) получить сообщение; 2) обработать сообщение; 3) сказать брокеру, что сообщение обработано. Именно так оно в кафке и происходит, и это единственный работоспособный вариант.

Я знаю и использую zmq, но тут у меня будут десятки тысяч сообщений и тысячи воркеров + выч. кластер

Это же не так много, почти что угодно наколеночное осилит такие объёмы.

если воркеры с потоком сообщений не справляются, то сообщения должны посейвится на диск, но не потеряться. Отследим, что кол-во сообщений растёт и добавим воркеров. Писать слой гарантировая доставки сообщений не хочется вот и всё. Поэтому и ищется, что-то более высокоуровневое чем zmq

Тебе мб нужен не mq, а что-то вроде mapreduce, например как в известном могильнике. Оно как раз реализует нужную логику регистрации машин, нарезку кластера между задачами и управление очередями. Внутри оно выглядит как табличка с входными данными (задачи) и реализация map операции с обработчиком таблицы.

Нед, гадуп сразу в пень. Он создаёт больше проблем, чем решает, и жрёт 90% ресурсов просто сам в себя.

Не hadoop, а Storm скорее (софт риал тайм сбор данных, hadoop это про batch processing, как и Spark).

Storm, возможно, воткнём на этапе обработки данных. Но для него нужен поток данных, который он где-то будет хранить (задачи могут генерироваться, как внутри кластера обработки, так и снаружи). Правда там зоопарк для запуска и мониторинга ещё тот (ZooKeper + Nimbus + сам Storm только запуска кластера).

И то не факт, что вообще стоит брать эту Java прослойку под кластер, тут смотреть надо, а оправдает ли она себя вообще.

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

Потому что сейчас я хочу посмотреть на MQ решения и оценить сферу их применения.

Лайк этому господину, а также лайк тому, который сказал «хадуп в пень». Бери кафку и не морочь голову. Но! Это ответ на твой вопрос, возможно - не решение твоей проблемы (http://xyproblem.info/).

Выглядит, как будто тебе нужно backpressure. Попробуй akka streams, должно зайти на ура. Если не хочешь, написать свою нано-реализацию будет не слишком сложно, главное - определись с проблемой.

Посмотри еще этот доклад: https://www.youtube.com/watch?v=wbTyy7vWQXo

И эти слайды: http://www.slideshare.net/Lightbend/understanding-akka-streams-back-pressure-...

Я и не просил никого решать мою проблему. На то она и моя ;)

По поводу akka streams - не Java и я не увидел никаких гарантий доставки. Похоже на аналог zmq, так что меня не интересует. Как вариант для Java мира - возможно пригодиться кому-то.

Нужна раздача сообщения ровно одному получателю (кто первый обратился).

Вполне себе будничная задача для amqp. Если не нравится кроль то есть еще qpid.

Ну так я и не говорю, что там что-то мега мега. Есть какие-то советы какую из реализаций брать? М.б. был опыт применения и были собраны косяки?

За qpid спасибо, посмотрю что и как он умеет.

Опционально, статус обработки (не обработано, в работе, обрабо тано)

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

Кстати, а он его куда подсунет? В конец или в начало очереди?

Если не хочешь, написать свою нано-реализацию будет не слишком сложно

С требованиями ТСа на это спокойно может уйти около года работы небольшой команды. Хотя часто в подобных ситуациях это вполне разумный выбор.

Я и не просил никого решать мою проблему. На то она и моя ;)

Так а нахера тогда задавать вопросы, полезность ответов на которые стремится к 0?

Для тебя - возможно, для меня - нет.

не Java

http://doc.akka.io/docs/akka/current/java/stream/stream-quickstart.html

Похоже на аналог zmq

а теплое похоже на мягкое.

http://doc.akka.io/docs/akka/current/java/stream/stream-quickstart.html

И зачем ты на ответ, что не Java кидаешь ссылку на Java код? Не Java == не JVM, разве не очевидно?

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

Ну ты и балбес, это джава.

Сходиться мы будем сами, протестировав всё. По поводу Scala - сам исправился. Но вопроса зачем мне гайд по Java, если у меня там не Java это не отменяет.

А, я понял «Не джава» как «не джава, поэтому не подходит», а не «у нас не джава». Ну бери тогда кафку.

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

Про offset'ы - уже почитал, не понравилось, усложнит логику клиентов. Надо будет Hello world'ы писать и смотреть что и как, потому что мне критична гарантия обработки сообщения (гарантия скорости на втором месте).

В этом плане RabbitMQ сильно проще в настройке на первый взгляд. durable для гарантии доставки + выставление максимума обрабатываемых сообщений в 1 (для балансировки по реальной производительности клиентов). И возвращение сообщения в очередь при отваливании клиента (можно просто позволить клиенту упасть и перезапустить его процесс, что вполне допустимо в моём случае).

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

Для дотнета Akka.NET, WCF, Orleans Project.

Есть такая библиотека — smartactors. Там есть такая штука как «контрольная точка». Вот эта та самая штука, которую ты хочешь. Дальше гугли сам.

я не силен в очередях, но по-моему все что нужно ТСу это персистентный брокер (много) и ack сообщений. вместо того чтоб прочитать парочку туториалов из офф. документаций и попробовать, развели демагогию а-ля «это делали не мы, переделаем с нуля».

Берешь RabbitMq, и не изобретаешь велосипед.