Как стать автором
Обновить

Комментарии 44

Если вам нужно перекидывать сообщения между сервисами в небольшом количестве — ваш выбор однозначно RabbitMQ.

Ваш выбор однозначно лёгкий и быстрый Redis (PubSub или Streams) или тот же NATS или NSQ, но не как не оверхед в виде RabbitMQ.
Так паб саб вроде же не хранит сообщения если нет консюмеров… Все таки это больше для fire and forget. Раббит же будет держать месседжи пока ваши сервисы которые возможно лежат из за бага или еще чего не поднимутся, и вы не потеряете данные.

Именно. rabbitmq и nats в совершенно разных нишах для совершенно разных задач. Мне очень нравится nats, но в последний раз я его использовал очень давно — чаще нужна надежная доставка, чем ненадежная.

pubsub не хранит, а streams хранят
Именно, но все зависит от задачи. В Redis можно и блокирующий список использовать для организации очереди если он вам подходит, и он так же будет хранить сообщения.
Действительно. Давно не следил за редисом. Похоже Redis Streams это кафка на минималках. Но все же интересно. Может пригодится когда нибудь.
Кроль это не только очереди, но и средство маршрутизации сообщений. При использовании редиски будете эту часть писать сами.
Я только не понял какое отношение процесса имеет к «Зачем-зачем, чтобы пройти собес!»?
Чтобы выстроить интересную, логичную цепочку
И как, получилось?
Не думаю
Вот на днях на собесе спрашивали, «вы пишите в своем резюме, что есть опыт работы с RabbitMQ, а почему не используете Kafka? Kafka же лучше!». Мой ответ, что это лишь инструмент, команда имеет опыт работы с RabbitMQ, и мы не умеем админить Kafka, и нету задач для него — обрабатывать кучу ивентов в реалтайме, такой ответ интервьювера не удовлетворил.
Нужно было ещё указать на различия в RabbitMQ и Kafka и упомянуть объёмы данных (например если у вас 2 сообщения / в сек, то можете вообще очередь не использовать). Например какой-нибудь dead-letter-exchange для меня киллер-фича, задачи которые он красиво решает ставят в небольшой ступор пользователей Kafka, когда выясняется что нужно городить здоровенный костыль чтобы сделать это на Kafka.

Ну и в целом да, это основное правило собеседований — интервьюверы зачастую не любят, когда кандидат не соглашается с их единственно-верным мнением. Или принимать как есть, или подстраиваться под обстоятельства — просто соглашаться с тем что кафка круче.

PS: Я разбирался с протоколом AMQP и считаю его ужасным, с недавних пор ко всем решениям на AMQP отношусь с подозрением.
Это больше говорит о интервьювере, чем о вас. Само заявление «Kafka же лучше!» уже вызывает фейспалм — это примерно, как заявить, что разводной ключ лучше молотка.
Ответ будет зависеть от вакансии, но скорее всего в данном случае интервьюер хотел проверить инициативность и любознательность кандидата при помощи провокационного вопроса.
Если вопрос звучал именно, как «Почему вы не используете Х?», то единственный достойный ответ будет «Потому что мы уже используем Y и нас устраивает!». То есть доказывать нужно как раз преимущества Х, а не защищать используемую технологию, если она исправно выполняет свои обязанности. А любознательность проверяется вопросом «А если вместо используемого Y использовать Х? Плюсы, минусы, подводные камни?»
Не всегда интервьюер хочет разжёвывать вопросы и это его право — заодно проверить soft skills кандидата.
Давно работаем с раббитом… топлю теперь на работе за ввод кафки в некоторые процессы. В раббите мне не хватает шардинга из коробки, ну и остальные плюшки. Иногда когда все упало нужно риплей сделать, и приходится танцевать с бубном и вытаскивать данные с тяжелых хранилищ типа snowflake. А так как кафка это аппенд онли лог, восстановление системы должно стать намного легче.

Роутинга там как в кролике нет конечно нет, но думаю это можно пережить…
В RabbitMQ есть cluster из коробки, как раз для HA/HL. Но в целом работает кролик крайне медленно.
Если трафик до 10к-20к сообщений / сек — всё хорошо.
Если выше — стоит рассматривать другие решения.
Проблема в том что в раббите нужно свой велосипед писать для ребалансировки шардов если вдруг нужно убрать/добавить консюмер. Насчет медленности раббита — зависит от задачи. У нас мессежди обрабатываются сравнительно медленно, поэтому скорость самого раббита вообще не интересна.
Есть команды для перебалансировки. Через раз даёт хороший результат =)
rabbitmq-queues rebalance "all" --vhost-pattern "a-vhost" --queue-pattern ".*"

Я тоже с этим столкнулся и решил, что меня пока устраивает такой формат.
Можно чуть подробнее на тему «через раз»? В чем выражается? баги/потери?
Иногда раскидывает неправильно, о чем само там же пишет. Не помню точно, в чем именно суть.
Возможно я конечно не нашел в kafka, но вот как раз на прошлой неделе хотел разделить топик на несколько партиций и раскидать их по серверам, в итоге нашел что только указав replication factor можно потом раскидать партиции по серверам. Тогда получается все равно будет все писаться на все серверы. Но у меня задача была не разделить нагрузку а увеличить место для хранения сообщений. Возможно не в ту сторону смотрел.

kafka-reassign-partitions утилита

Да, я ее видел и даже читал, но видимо в завале работы понял не совсем правильно возможность задать Replica
Перечитал еще раз и более менее все стало яснее
Спасибо
Каждый topic бьется на части до 50 partitions

Что это за лимит в 50 partitions? Откуда он?

Сложнее задача когда нужно разделить очередь на под очереди.
Чтобы сыпались ивенты в систему, а процессились у каждого пользователя свои под очереди в той последовательности в какой они сохранились.
Проще всего здесь использовать базу данных и пулить раз в х секунд с группировкой по пользователю.

База умрет под нагрузкой, плюс всякие вакуум. Очереди в базе так себе идея, если есть нагрузка.


под базой имел ввиду sql.

Все верно. А иначе разве что динамически создавать топики под пользователя.
Но если много топиков, то это шардинг топиков

Ну так именно эту проблему шардинг кафки и решает. И автоматический ребаланс вроде как киллер фича.

Но как консьюмить миллионы топиков?
Продюсеру то все равно. Открыл соединение и если указать в настройках Кафки, что автосоздавай топики, то по user id писать.
Скорее корректнее разбивать на partitions где key будет user id

Ну да. Шардинг это не про «отдельный топик по id» (id как пример), это про обеспечение условия fifo по id. Это просто условие что мессежди одного и того же юзера будут обработаны в определенном порядке, за счет того что они прилетят на один и тот же консюмер.

Решение с топиком под каждого юзера кажется мне избыточным и возможно даже не реализуемым. Вот что пишут в самой кафке

Unlike many messaging systems Kafka topics are meant to scale up arbitrarily. Hence we encourage fewer large topics rather than many small topics. So for example if we were storing notifications for users we would encourage a design with a single notifications topic partitioned by user id rather than a separate topic per user.

The actual scalability is for the most part determined by the number of total partitions across all topics not the number of topics itself (see the question below for details).


И

Jun Rao (Kafka committer; now at Confluent but he was formerly in LinkedIn's Kafka team) wrote:

At LinkedIn, our largest cluster has more than 2K topics. 5K topics should be fine. [...]

With more topics, you may hit one of those limits: (1) # dirs allowed in a FS; (2) open file handlers (we keep all log segments open in the broker); (3) ZK nodes.
Прочитал статью здесь и на медиум, но так и не понял, в каком режиме тестировался кролик, только в режиме «записи на диск», т.е. режим «in memory» не тестировался и не сравнивался априори?
Перед нашей инстанс-группой стоит load-балансер

Перед нашей группой экземпляров стоит балансировщик нагрузки.
Как только консьюмер подтвердил обработку сообщения, оно удаляется.

При этом нужно понимать, что подтверждение одностороннее в случае AMQP, что может иметь последствия. Или есть опция включить ответы на подтверждения?
Логично выполнить эту задачу асинхронно на фоне.

Логично эти данные денормализовать и сохранить. Жечь процессорные мощности снова и снова на одной и той же задаче весьма странно.
Как это противоречит тому что написано? Это конечно же можно делать как часть процесса обработки месседжа. А там как хотите так и делайте. Хоти в s3 кидайте, хотите в базу. Хотите по ключу определяйте что такой рипорт уже просили и возвращайте данные с прошлой обработки. А где вы их храните — это же ваш бизнес решает.

Тут же не об этом. Тут о том что браузер не будет ждать так долго и оборвет коннекшен. И в добавок если что-то временно пошло не так, можно делать попробовать позже и захендлить этот кейс а не ждать пока юзер обнаружит что что0то зафейлилось и он должен повторить просьбу.
Есть еще вариант — нанять миллиард китайцев ))))… Латенси будет плохая, но объем обработок большой. )))
Я ожидал минималистичный велосипед вместо известных решений, а получил так сказать минималистичный «вебинар» по кафке и еще более минималистичный по рэбиту)

Если вы про одмин Кафки — это очень короткий рассказ, как правильно юзать Кафку вместе с контрактами в виде авро, как ее обезопасить и т.д.
Если вы разраб, который левой пяткой ещё и кластеры админит — покажите ваш код, что бы было понятно, как вы совмещаете все навыки не в ущерб друг другу.
И нет, вам не нужна Кафка с 10к евентов в секунду и exactly one логикой.

Спасибо, полезная статья для тех кто с кафкой дела не имел а только слышал. Появилось желание поиграться с ней, может в будущем пригодится.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий