Comments 44
Если вам нужно перекидывать сообщения между сервисами в небольшом количестве — ваш выбор однозначно RabbitMQ.
Ваш выбор однозначно лёгкий и быстрый Redis (PubSub или Streams) или тот же NATS или NSQ, но не как не оверхед в виде RabbitMQ.
Именно. rabbitmq и nats в совершенно разных нишах для совершенно разных задач. Мне очень нравится nats, но в последний раз я его использовал очень давно — чаще нужна надежная доставка, чем ненадежная.
Ну и в целом да, это основное правило собеседований — интервьюверы зачастую не любят, когда кандидат не соглашается с их единственно-верным мнением. Или принимать как есть, или подстраиваться под обстоятельства — просто соглашаться с тем что кафка круче.
PS: Я разбирался с протоколом AMQP и считаю его ужасным, с недавних пор ко всем решениям на AMQP отношусь с подозрением.
Роутинга там как в кролике нет конечно нет, но думаю это можно пережить…
Если трафик до 10к-20к сообщений / сек — всё хорошо.
Если выше — стоит рассматривать другие решения.
Каждый topic бьется на части до 50 partitions
Что это за лимит в 50 partitions? Откуда он?
Сложнее задача когда нужно разделить очередь на под очереди.
Чтобы сыпались ивенты в систему, а процессились у каждого пользователя свои под очереди в той последовательности в какой они сохранились.
Проще всего здесь использовать базу данных и пулить раз в х секунд с группировкой по пользователю.
База умрет под нагрузкой, плюс всякие вакуум. Очереди в базе так себе идея, если есть нагрузка.
под базой имел ввиду sql.
Но как консьюмить миллионы топиков?
Продюсеру то все равно. Открыл соединение и если указать в настройках Кафки, что автосоздавай топики, то по user id писать.
Скорее корректнее разбивать на partitions где key будет user 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.
Перед нашей инстанс-группой стоит load-балансер
Перед нашей группой экземпляров стоит балансировщик нагрузки.
Как только консьюмер подтвердил обработку сообщения, оно удаляется.
При этом нужно понимать, что подтверждение одностороннее в случае AMQP, что может иметь последствия. Или есть опция включить ответы на подтверждения?
Логично выполнить эту задачу асинхронно на фоне.
Логично эти данные денормализовать и сохранить. Жечь процессорные мощности снова и снова на одной и той же задаче весьма странно.
Тут же не об этом. Тут о том что браузер не будет ждать так долго и оборвет коннекшен. И в добавок если что-то временно пошло не так, можно делать попробовать позже и захендлить этот кейс а не ждать пока юзер обнаружит что что0то зафейлилось и он должен повторить просьбу.
Если вы про одмин Кафки — это очень короткий рассказ, как правильно юзать Кафку вместе с контрактами в виде авро, как ее обезопасить и т.д.
Если вы разраб, который левой пяткой ещё и кластеры админит — покажите ваш код, что бы было понятно, как вы совмещаете все навыки не в ущерб друг другу.
И нет, вам не нужна Кафка с 10к евентов в секунду и exactly one логикой.
Неужели нельзя обойтись без кафок и рэббитов, когда принимаешь 10 000 ивентов в секунду