Comments 27
да, спасибо что обратили внимание ) минимальным конечно же должно быть время. поправил в статье
А какую топологию кластера натса вы в итоге используете?
Мы в своих внутренних исследованиях обнаружили нестабильность работы NATS при кластером сетапе в 5 нод и использовании Jetstream (один баг даже зарепортили). В частности это проявляется в нестабильном создании стримов, "отключении" консьюмеров.
Также нас не очень устроила скорость работы Jetstream: при 300-400k RPM латенси записи начинает очень сильно уступать кафке. Ну и с масштабированием стримов тоже есть вопросы.
Общий наш вывод в том, что nats без Jetstream хорош, но с ним - пока слишком молод и нестабилен.
мы изначально стали standalone использовать, ну и оно до сих пор хорошо летит, что перестраивать на кластер или добавлять надежную доставку нет необходимости. Хотя поиграть с этими штуками хочется. Надеюсь что получится найти время, сделаю бенчмарки по nats\rabbit\kafka в разных режимах, сделаю еще одну статью с графаной и цифрами )
ну да, про jetstream хоть у них в доке написано что jetstream стильно модно молодежно, технология вроде как достаточно новая, багов еще не собравшая. но думаю через пару лет будет пушка ))
Кластер же позволяет вам проводить работы на nats, пересетапливать сервера без простоя и т.д.
Как сейчас вы обеспечиваете бесперебойную работу?
Не автор, но вклинюсь) Если использовать натс просто как шину, без всякой перзистентности, то перезапуск тривиален, т.к. все сервера кластера равноправны. Естественно, клиенты должны быть сконфигурирована на реконнект автоматический, а в остальном - главное не прибейте все ноды кластера одновременно.
В случае с JetStream все скорее всего посложнее, так как там уже есть мастер нода и всякий Raft для консенсуса. Тут не подскажу.
Ну и есть один момент, по которому я создавал issue в их репозитории, но не помню, исправили они что-то или нет. Смотрите, клиенты обычно скофигурированы так, чтобы рандомно выбирать ноду кластер, куда коннектиться. Получается, что во время работы кластера у нас примерно по N клиентов на каждой ноде. Потом вы начинаете рестарт кластера. Останавливаете одну ноду, и все ее N клиентов переходят на 2 оставшиеся (предположим, что 3 ноды в кластере). Потом нода поднимается, на ней 0 клиентов, на других 1.5N. Думаю, идея понятна, когда вы закончите, у вас на одной ноде будет 0 клиентов, на другой 1/3, и еще на одной 2/3 (посчитайте сами). Но повторюсь, возможно, с этим уже что-то сделано.
ну, мы дублируем просто как натс, так и сервисы которые с ним работают. грубо говоря дублируем весь узел системы. это позволяет не только с натс работы проводить но и с сервисами которые с ним взаимодействуют, что иногда нам тоже необходимо
Также, как я понимаю, вам не требуется персистивность сообщений после публикации продюсером?
нет, мы в целом были готовы мириться с потерей 3-5% сообщений (хотя думаю в итоге если бы такое было, то в итоге искали бы варианты решения), но поскольку nats показал себя хорошо и стабильно, то ничего добавлять не стали
Интересно, т.е. любой пик сообщений выше запланированного приводит к отстрелу всех консьюмеров, ибо они переполняются и начинают тормозить?
не всех, а только тех кто начинает тормозить. остальные как читали, так и продолжают читать.
Но нюанс заключается в том, если например у вас 5 топиков, и из каждого топика читают по 5 клиентов, один из которых начинает тормозить, то его натс в итог отстрелит. Но при этом этот, которые тормозит может влияет на вычитку остальных 4 клиентов, которые читают из того же топика. Это особенность реализации, мы им писали об этом, даже вроде реквест зарелизили (не помню уже если честно, давно было) но в итоге просто свою схему потюнили немного и оно норм работает
Только написал статью, где говорил про то, что про NATS ничего нет на хабре и вуаля) Спасибо)
Что касается натса, тоже выбирал его за его низкую latency, и тоже доволен. У нас используется суперкластер: один кластер из 3х нод в амазоне, один такой же в овх. Проблем особых не было, один раз сертификат какой-то только забыли обновить)
Мы пишем микросервисы в основном на плюсах, и с этим есть проблемы. У них есть только си либа, плюсовые только сторонние и скорее мертвы. Я писал свою билиотеку, мне важна была полная асинхронность, и с этим были проблемы. Их сишная либа дает асинхронность либо через libuv, либо через libevent. Обертку-то плюсовую я в итоге написал, добавил туда примитивы для удобной работы с асинхронными операциями, но это была боль, потому что их либа все равно внутри какие-то операции (например, flush) делает синхронно, а выясняется это только опытным путем, когда дедлок ловишь где-то. К счастью, это некоторым образом компенсируется тем, что натсовские разработчики хорошо идут на контакт, с их помощью эти проблемы я либо фиксил, либо они вносили изменения в либу.
Ну вот выложите плюсовую свою обертку на github, сделайте людям пользу и payback вселенной... ато все мы пишем свои велосипеды для nats для ++, и я писал, пока с плюсов не перехал...
да, плюсовой любы у них почему то нету (( у нас есть микросервисы на плюсах, но в них видимо как раз сишная либа используется. До вашего коммента я был уверен что ее можно легко с плюсовый код встроить, но щас начал сомневаться ) поизучаю этот момент
ну, я тоже когда искал про nats в рунете в целом и на хабре в часности находил только по касательной, полноценной статьи не видел. Решил исправить сей недостаток, потому как технология как по мне очень интересная
было бы неплохо описать особенности архитектуры, в том числе и в сравнении.
несколько лет назад смотрел в его сторону, но вот это:
"Поскольку NATS не записывает сообщения на диск, сервисы-получатели должны аккуратно завершать свою работу — вначале отписываться от новых сообщений, затем обрабатывать полученные ранее и только потом останавливать процесс. "
не дало шанса попробовать из-за особенностей производства.
Да там особенностей изначально-то особо и не было) Он фундаментально очень прост: пришло сообщение, если кто-то слушает, отправил дальше. Если нет, сразу отбросил. Причем года полтора назад, они и никакой ошибки, что никто не слушает, не отправляли. Было проблематично организовывать request-reply, потому что если принимающая сторона отсутствовала, request по таймауту только завершался.
Сейчас есть у них движок jetstream, который превращает натс в а-ля кафку. Про него не расскажу, не использовал.
Очень специфичный сервис, по сути это замена пул модели на пуш для отгрузки данных из сервиса.
С кафкой даже рядом не сравнить. А про жаву и кафку - есть редпанда, 2 бинаря: клиент на плюсах и конфиг утилита на го.
А вот в этой статье сравнили, и там действительно натс и кафка рядом не валялись. Я думаю все-таки для определенных задач одно, для других другое)
скорость прохождения сообщений через весь путь должна быть минимальной;
может время прохождения? или скорость все-же максимальная?
Мы смотрели в сторону брокера Kafka, и это вроде как хорошая штука, но по итогу мы отказались тащить решение, написанное на Java.
Брокер сообщений NATS: как мы решали проблему скоростной и стабильной доставки сообщений