Так... если говорить про некую абстрактную производительность, то мы должны для начала определить метрики ("открываешь/закрываешь его на каждый этот свой вызов рпц" - это не метрика), обычно их две: latency и throughput (надеюсь не нужно объяснять, что это как болид F1 против фуры), для них есть еще персентили и сренеквадратичные отклонения, поскольку среднее значение мало кому интересно. И дороговизна открытий HTTP-соединений должна рассматриваться в рамках этих двух терминов, здесь можно согласиться, что throughput у персистентных соединений будет выше, однако latency в сравнении с HTTP там будет зашкаливать, потому что открыть TCP соединение и проверить валидность сессионного токена - это одно, а дождаться когда брокер зафиксирует сообщение в очереди, потом его кто-то оттуда вычитает, обработает, отошлет обратно и мы прочтем - это совсем другое.

Относительно бродкастов... если мне понадобится так делать, я HTTP использовать не буду - у меня здесь нет никаких религиозных соображений.



кому вы собрались ответ отсылать из DLQ? в RPC на кривой запрос клиент получает ошибку, чтобы такое же сделать на request/reply нужно изворачиваться - это совершенно не равноценное взаимодействие, очереди - это когда глухой общается с немым.

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

https://www.ben-morris.com/the-problem-with-guids/ This can be improved by using sequential GUIDs, though these are more vulnerable to being guessed or brute forced. In most cases, the simplest solution is to use boring old incrementing integers.

Что мда? Вы уже второй раз (первый тут: 22197826 - какой-то нереальный прогон, что что ACK долетает до отправителя) демонстрируете, что умение читать - это не ваш конек (про умение понимать прочитанное даже речь не идет), при таком раскладе насколько вероятно что вы не несете пургу постоянно? Если приплюсовать ту дичь, что вы писали в топике про СУБД, я бы сказал что к вашему мнению прислушиваться совершенно не стоит. При всем при этом зачем-то докопались до образования чувака, вы вообще в курсе, что, например, у сэра Исаака Ньютона теологическое образование? А в курсе как расшифровывается PhD?


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

Вероятно запросили пруф для простейшей реализации в подтверждение утверждения о крутости очередей


Так что в итоге за 4 страницы обсуждения непонятно чего удалось выяснить:
- общение peer-to-peer между сервисами при помощи RPC - суть отстой, потому что там что-то не достаточно отказоустойчиво, не достаточно мастабируется и что-то еще
- очереди (возможно не все, но RabbitMQ-то точно) это круто и быстро, потому что там персистентные соединения, durable-очереди, можно настроить отказоустойчивый сервис, все дела

Вроде ничего не пропустил...

и вот я как дурак зачем-то полез в интернет и начал выяснять что это за зверь такой этот RabbitMQ, что на нем, куда не плюнь, все лучше чем в REST и вот нашел статейку: Benchmarking Apache Kafka, Apache Pulsar, and RabbitMQ: Which is the Fastest? , если кому-то лень читать (ну или кто не умеет слишком много текста) приведу основные тезисы:
- чуваки взяли тройку i3en.2xlarge (8C/64GB) и начали на них проверять какая очередь работает круче
- поставили они эти очереди в условно одинаковые условия: ну вот durability в RabbitMQ завезли недавно и оно такое медленное, что даже вендор не рекомендует , поэтому вместо durability репликация, а в кафке типа все круто из коробки (ну и crutchmaster завещал не просирать сообщения)
- ну вот в таком режиме оказалось что RabbitMQ больше 30 тысяч сообщений в секунду не умеет, а у кафки оказалось 200 тысяч

Итак.

RabbitMQ умеет с 24 ядер не больше 30 тысяч сообщений в секунду, в случае request/reply там очевидно 2 канала в разные стороны, поэтому эти 30 тысяч сообщений в секунду можно смело поделить на 2 и получить 15 тысяч обменов в секунду. Много это или мало? Идем на сайт, где другие ребята измеряют производительность разных web-фреймворков и смотрим что там и как (нужно в правом верхнем углу переключиться на вкладку cloud, чтобы результаты хоть как-то были сопоставимы с теми что для очередей: у них один Azure D3v2 - это 4С/14GB, т.е. раза в два слабее и в три раза меньше чем в тесте очередей). И что-то видится мне, что 15 тысяч обменов в секунду для HTTP - это совсем какой-то слабый результат - вон undertow, который в wildfly встроен за секунду делает 64 тыщи, да еще из базы что-то при этом выбирать успевает, без базы там вообще 180 тыщ в секунду.