Comments 4
Я бы выбрал NATS, стримы из коробки, меньше избыточных сущностей, быстрый и со стороны разработки показался прям сильно удобней, чем Rabbit. Конечно, если много всего написано и работает под Rabbit, наверное плагин будет кстати. Но специально я бы в него не шёл.
Основная сложность стримов в рэбите: это подтверждение доставки.
Допустим мы отправляем с помощью await porduser.Send(...), это вообще ничего не значит, нужно ждать когда отработает MessageHandler. Приходится писать свою обвязку.
Если отправили список сообщений (даже с одним сообщением), то MessageHandler отрабатывает сразу, а если по одному, то происходит буфферизация. Задаётся параметров MessagesBufferSize продюсера, по умолчанию 100. Параметра "максимальное время ожидания отправки" не существует.
В итоге, из коробки либа Rabbit.Streams подходит для быстрой массовой отправки сообщений без гарантии доставки. Если нужны гарантии, нужно дописывать свой код.
А ещё нет сжатия сообщений в стримах.
Всё что есть - сжатие пачки сообщений на продюсере при отправке. Вся эта пачка становится одним чанком. Если отправка идёт по одному сообщению: то никакого сжатия.
Этот чувак на иллюстрации к статье - крутой разработчик. Он шарит в С++, С#, Go, Rust, Python. Это только то, с чем он засветился в последний месяц. Но наверняка его знания намного более обширны.
.NET C# и RabbitMQ Streams: превратить кролика в Kafka легко, нужно всего лишь…