Comments 24
нам предстояло выбрать среди нескольких доступных на рынке брокеров сообщений, и мы остановились на Apache KafkaКакие были другие варианты?
А чем вы мониторите кластер?
Читаю уже не первую статью про Kafka. Хотелось бы узнать, есть ли у нее какие-то киллер-фичи относительно того же RabbitMQ?
Насколько я знаю, rabbit mq не может гарантировать exactly-once семантику доставки сообщений, которая хорошо описана, например, здесь habrahabr.ru/company/badoo/blog/333046
Насколько я помню, семантика доставки в кафке во-первых, зависит от настроек. А во-вторых, по-идее должна (возможно сильно), влиять на производительность. Вы это учитывали в своих тестах?
И второе:
Например, одна из них собирает все отклики с большинства самых известных работных сайтов страны, обрабатывает и отправляет это все рекрутерам. А это довольно большие потоки данных.
Отклики — это люди? Или вы о чем-то другом? Если люди, то верится с трудом — люди не могут генерировать реально большие потоки данных. По сравнению с роботами это всегда мало. Да как правило еще и сильно варьируется в течение суток, потому что к утру Москвы активность Владивостока уже спала.
Главная киллер фича — это скорость и масштабируемость. Кролик, по факту, очень трудно масштабируем. Ну и указанная exatly-once тоже хороша, но появилась там совсем недавно.
Просто мы используем RabbitMQ в продакшене. Кластер из двух нод прекрасно работает. При этом и продьюсеры и консьюмеры могут быть подключены к разным нодам. Т.е. масштабируется довольно хорошо.
Нагрузка пока не очень большая — около 1000 сообщений/сек. И Rabbit прекрасно справляется.
Но, тем не менее, знание других брокеров сообщений очень полезно. Особенно их плюсов, минусов и различий. Это вполне может пригодиться в будущем.
Нагрузка пока не очень большая — около 1000 сообщений/сек. И Rabbit прекрасно справляется.
Но, тем не менее, знание других брокеров сообщений очень полезно. Особенно их плюсов, минусов и различий. Это вполне может пригодиться в будущем.
Просто мы используем RabbitMQ в продакшене. Кластер из двух нод прекрасно работает. При этом и продьюсеры и консьюмеры могут быть подключены к разным нодам. Т.е. масштабируется довольно хорошо.
Подключены могут быть, да. Но владельцем очереди всё равно будет одна нода — другие будут просто пересылать ей\от неё сообщения используя встроенную эрланговскую механику. Плюс, если используется HA-политика, будет N нод-реплик, которые имеют зеркало очереди.
Так что нет, не масштабируется — в рамках отдельной очереди всегда будет упор в одну ноду, плюс, чтобы не нагружать еще и соседей, нужно знать к какой именно подключаться. Если просто сделать TCP-балансёр перед кроликами то получим доп. нагрузку на межкластерных линках и процессоре.
Некое масштабирование получить можно, но для этого нужно реализовывать его в приложении — распределять нагрузку на кластер из него по большому количеству очередей. Но по сути это костыль.
Нагрузка пока не очень большая — около 1000 сообщений/сек. И Rabbit прекрасно справляется.
1к сообщений это вообще ни о чём для брокера. Когда я его последний раз мучал, кластер из 3 нод умирал примерно на 20к msg/sec в режиме с 1 репликой (могу ошибаться).
Кафка же не особо напрягаясь прожует и 200-300к и даже больше.
В общем, если нужна сложная логика обработки сообщений:
exchange -> exchange -> queue
роутинг по header
разные хитрые TTL
плагины
и прочее
то без кролика не обойтись.
Если нужно просто и быстро — кафка. Плюс есть всякие менее распространённые штуки типа NSQ, но там другая парадигма немного.
Киллер фича в моем понимании это то, что кафка и не брокер в классическом смылсе это распределнный Log или по русски может быть я назвал бы точнее "распределенное хранение событий".
Тут переосмыслен сам это Log. Клиенты сами ведут учет какое сообщение они получили а какое нет. Вам вообще можно ничего не стирать, лог остается не изменненый, можете прочитать заного событие из 2014-го года…
Это все скалирует очень хорошо конечно… А главное это дает возможность переосмыслить архитекртуры, и внедрить EventSourcing и CQRS.
Но статья совершенно не об этом… Поэтому сравнения с Раббитом уместны и правильны.
Какой у вас реальный объем сообщений в топиках? И какие ресурсы под это дело и настройки кафки?
Прогоняли тесты на 200-стах итерациях по 500К сообщений в каждой. Настройки кафки и потребителя дефолтные. Ресурсы: 16G ОЗУ, Core i7 x2, SSD
Я не про тесты, а про промышленную эксплуатацию. Короткая синтетика совсем не то же самое, что постоянная работа.
Чаще всего она «размазана» по времени и колеблется в районе 250к в секунду на 6-ти нодовом кластере
Это «отклики с большинства самых известных работных сайтов страны»? Выглядит крайне сомнительно что там такой трафик даже на серверах статики. Эти сайты продают вам трафик?
Зачем в этом кейсе exactly once? Как вы проектировали свое приложение для работы с exactly once?
Какие настройки пришлось менять? Как выбирали репликацию, ретеншн? Как настраивали размер сообщений (то о чем у вас указано в статье)? Какие проблемы были? Были ли проблемы с ребалансом?
Зачем в этом кейсе exactly once? Как вы проектировали свое приложение для работы с exactly once?
Какие настройки пришлось менять? Как выбирали репликацию, ретеншн? Как настраивали размер сообщений (то о чем у вас указано в статье)? Какие проблемы были? Были ли проблемы с ребалансом?
Как вы справедливо заметили, в наших hr-системах нагрузка сейчас существенно ниже, а приведенные значения — это максимальные цифры, с которыми приходилось сталкиваться коллегам в работе.
В приведенных кейсах не используется exaclty once. Упоминание об excaclty once связано с тем, что это фича привлекла внимание к использованию Apache Kafka. Остальные вопросы требуют подготовки отдельной, более глубокой статьи.
В приведенных кейсах не используется exaclty once. Упоминание об excaclty once связано с тем, что это фича привлекла внимание к использованию Apache Kafka. Остальные вопросы требуют подготовки отдельной, более глубокой статьи.
UFO just landed and posted this here
Вот-вот, ни о какой exactly once semantic ( www.confluent.io/blog/exactly-once-semantics-are-possible-heres-how-apache-kafka-does-it ) в вакуме и речи нет. Только есть все такие из себя идемпотентные и правильные.
Куча вопросов к статье:
1. Желтушный заголовок, и где ваш миллион сообщений, по графикам вижу максимум 500к
2. Где конфиги обеспечивающие ваши требования? Почему только один брокер, где реплика?
2. Сколько времени гонялись тесты. Успевал ли за это время время заполняться хип и в какой момент бралось время для графика
3. Почему взята мифическая цифра в 100 байт не объяснено, а каков средний размер ваших сообщений?
4. Если уже заупстили кафку в экплуатацию или собираетесь, то расскажите как вы добиваетесь exactly-once, на какой версии, с какими конфигами на кафке/продюсерах/консумерах, как организовали отсутвие дубликатов при краше читальщика и при этом обеспечили миллионы сообщений в секунду при постоянной нагрузке.
1. Желтушный заголовок, и где ваш миллион сообщений, по графикам вижу максимум 500к
2. Где конфиги обеспечивающие ваши требования? Почему только один брокер, где реплика?
2. Сколько времени гонялись тесты. Успевал ли за это время время заполняться хип и в какой момент бралось время для графика
3. Почему взята мифическая цифра в 100 байт не объяснено, а каков средний размер ваших сообщений?
4. Если уже заупстили кафку в экплуатацию или собираетесь, то расскажите как вы добиваетесь exactly-once, на какой версии, с какими конфигами на кафке/продюсерах/консумерах, как организовали отсутвие дубликатов при краше читальщика и при этом обеспечили миллионы сообщений в секунду при постоянной нагрузке.
1) 500К это количество сообщений для тестирования пропускной способности на конкретном значении batch.size. А таких различных значений приведено 200 штук, и они были проведены одна за другой. А что касается заголовка, отчасти, конечно, соглашусь.
2) Я написал, что конфиги брокера и потребителя дефолтные, чтобы протестировать кафку в общем случае, поскольку разные задачи требуют разных подходов оптимизации. Действительно, в приведенных тестах фигурирует только один брокер, без репликации, поскольку большая часть материалиа построена на оптимизации настроек producer'a
3) Цифра взята в качестве примера. У всех разный размер сообщений. В статье мы лишь должны были от чего-то отталкиваться.
4) Сейчас на практике exactly-once мы не используем, используется at-least-once. Но в перспективе мы хотели бы exaclty once, т.к. на некоторые кейсы, она удачно ложится.
2) Я написал, что конфиги брокера и потребителя дефолтные, чтобы протестировать кафку в общем случае, поскольку разные задачи требуют разных подходов оптимизации. Действительно, в приведенных тестах фигурирует только один брокер, без репликации, поскольку большая часть материалиа построена на оптимизации настроек producer'a
3) Цифра взята в качестве примера. У всех разный размер сообщений. В статье мы лишь должны были от чего-то отталкиваться.
4) Сейчас на практике exactly-once мы не используем, используется at-least-once. Но в перспективе мы хотели бы exaclty once, т.к. на некоторые кейсы, она удачно ложится.
Просто получается введение в заблуждение, т.к. вы заявили большой спектр функционала кафки, который кардинальным образом снижает производительность, но все тестируете на инсталляции из одного брокера без этих фич, причем без явного указания, что используется SSD и практически отсутвует стоимость сохранения лога (на обычных hdd скорость диска становится крайне важным фактором при исчерпании хипа на брокере и все эти «миллионы рпс» просто падают на порядки)
Еще есть претензия к графику с 16 партициями — почему только 4,8,16, а где данные для одного продюсера? Из-за этого ваш вывод о повышении пропускной способности невозможно правильно толковать — это улчшение из-за увеличения партиций или количества продьюсеров? Т.е. создается ощущение, что нужно и то и то увеличивать, однако на практике количество партиций не ускоряют продьюсеров. А вот пара дополнительных продьюсеров положительно сказывается на утилизации ресурсов, главное не перебарщивать, а то до деградации недалеко.
Вот из-за этих всех мелких моментов статья выглядит как маркетинговый булшит, хотя в ней есть полезные моменты, но чтобы понять, что именно там полезного нужно иметь опыт в сопровождении кафки. А полезного — комментарии к статье и графики, на которые по хорошему нужно наложить линию тренда, а еще лучше — сопроводить версией с логарифмической осью Х, а то невозможно оценить разницу для 100 и 200 байт.
Еще есть претензия к графику с 16 партициями — почему только 4,8,16, а где данные для одного продюсера? Из-за этого ваш вывод о повышении пропускной способности невозможно правильно толковать — это улчшение из-за увеличения партиций или количества продьюсеров? Т.е. создается ощущение, что нужно и то и то увеличивать, однако на практике количество партиций не ускоряют продьюсеров. А вот пара дополнительных продьюсеров положительно сказывается на утилизации ресурсов, главное не перебарщивать, а то до деградации недалеко.
Вот из-за этих всех мелких моментов статья выглядит как маркетинговый булшит, хотя в ней есть полезные моменты, но чтобы понять, что именно там полезного нужно иметь опыт в сопровождении кафки. А полезного — комментарии к статье и графики, на которые по хорошему нужно наложить линию тренда, а еще лучше — сопроводить версией с логарифмической осью Х, а то невозможно оценить разницу для 100 и 200 байт.
>Нет потребителей — скорость падает
Что? Данные в любом случае записываются на диск согласно retention.ms/compact.policy конфигурации. Не важно прочитали их или нет.
Единственное отличие — если consumer получает самые последние данные возможно они все еще в файловом кеше, и тогда bottleneck будет не диск а сеть.
Asks не влияет на живучесть, он определяет минимальное количество подтверждений от in-sync replicas. И используется в паре с min.insync.replicas
Нарушение очередности с Max.in.flight.requests.per.connection было полностью решено в Apache Kafka 1.0 (KAFKA-5494)
linger.ms используется для уменьшения числа запросов при малой нагрузке на продюсер. Иными словами что бы плотнее набивать batch.size. Имеет смысл если у вас сотни/тысячи продюсеров и маленький кафка кластер.
Описание batch.size так же не отражает реальности.
>Асинхронное реплицирование может потерять данные
Что вы этим хотели сказать? Что при acks=0 у продюсера при падении лидера реплики данные могут быть потеряны?
>Новые производители почти линейно увеличивают производительность
Почти нет. Есть network threads на стороне брокера и это первое во что вы упретесь. Потом в random writes при записи в десятки/сотни/тысячи разных партиций одного брокера.
Что? Данные в любом случае записываются на диск согласно retention.ms/compact.policy конфигурации. Не важно прочитали их или нет.
Единственное отличие — если consumer получает самые последние данные возможно они все еще в файловом кеше, и тогда bottleneck будет не диск а сеть.
Asks не влияет на живучесть, он определяет минимальное количество подтверждений от in-sync replicas. И используется в паре с min.insync.replicas
Нарушение очередности с Max.in.flight.requests.per.connection было полностью решено в Apache Kafka 1.0 (KAFKA-5494)
linger.ms используется для уменьшения числа запросов при малой нагрузке на продюсер. Иными словами что бы плотнее набивать batch.size. Имеет смысл если у вас сотни/тысячи продюсеров и маленький кафка кластер.
Описание batch.size так же не отражает реальности.
>Асинхронное реплицирование может потерять данные
Что вы этим хотели сказать? Что при acks=0 у продюсера при падении лидера реплики данные могут быть потеряны?
>Новые производители почти линейно увеличивают производительность
Почти нет. Есть network threads на стороне брокера и это первое во что вы упретесь. Потом в random writes при записи в десятки/сотни/тысячи разных партиций одного брокера.
Sign up to leave a comment.
Apache Kafka и миллионы сообщений в секунду