RabbitMQ VS. ActiveMQ

У ZeroMQ (никогда не юзал, мб ошибаюсь), вроде как, дуплекс и там как раз можно играть в запрос-ответ

Но зачем если есть grpc. Не, я понимаю логи или что-то не-realtime в очередь кидать, но когда вот прям ответ нужен (и ещё с максимальным временем этого ответа) это мягко говоря странно

Это же относительная тонкая надстройка над сокетом. Для IoT как минимум. А GRPC я никогда не видел, не представляю что это. В отличие от брокеров сообщений. Но у меня везде по назначению юзались.

Grpc в первом приближении что-то типа бинарного rest с плюс-минус строгой схемой. Для обычного общения двух сервисов как раз самое то

И да, что круче?

WebSphere MQ (но это не точно, скачай фри репорт https://www.itcentralstation.com/products/comparisons/ibm-mq_vs_red-hat-amq_v...)

П.С. У Межделмаша самый фичастый, кролег самый популярный, но... пока ты не знаешь чего хочешь от MQ, можно брать любой, который плохо лежит.

Лапшой нормальный код становится в кривых руках.

Есть ли инструмент который может выдержать кривые руки?

Pivotal насколько мне известно не разрабатывает кролика

А ты знаешь как твой observable работает?

Конечно.

Сможешь его с нуля написать?

Не вижу проблемы.

А еще у кролика KCQL нет.

Но мы то говорили о потоке.

ПС.
Читать старые записи пришлось только один раз и только из-за упертости клиента.

Для каждого случая есть свой тул.

На другом проекте все ложилось в elastic и искалось там вместе страданий с таблицами в Кафке.

Если нужен именно запрос-ответ то разумеется grpc будет правильнее(да тут и рест подойдет), но что если сообщение нужно получить двум и более консьюмерам?

В GRPC есть что-то для таких случаев?

Обычно оно не нужно.

Расскажите когда применяется тот или иной MQ

Первое на эрланге, второе на java. А применяется в основном kafka.

Если у тебя предполагается очереди длиной >100500 элементов, то эти поделки текут и кушают RAM. И тогда вместо длинной очереди делается по какому-то событию SELECT из огромной базы, небольшой сегмент очереди генерится на лету, и уже сегмент раскидывается по нодам.

Если нужен именно запрос-ответ то разумеется grpc будет правильнее(да тут и рест подойдет), но что если сообщение нужно получить двум и более консьюмерам?

Опять же «90% случаев». Я не спорю что mq нужны. Я против когда их питают туда где хватит grpc или редиса.

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

редиса

Редис использую, но опять же он не даёт гарантии доставки.

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

А мы наблюдали, когда начали сравнивать по базам источника и потребителя: что должно было дойти и что на самом деле дошло.

Кафка тоже теряет, да :(

может клиенты какие-то кейсы не обрабатывают?

Нет, так задумано.