Это егэшная задачка по информатике, btw. Сдавал недавно (так вышло) - мне вот ровно она попалась, за 15 минут не уложился решить, сейчас интереса ради попробовал на leetcode - полчаса ушло с учётом вспоминания синтаксиса С++.
Хз насколько это вообще показательно, очень уж сильно зависит успешность решения таких задачек от набитости руки и состояния в моменте - в итоге алгоритмические секции просто проверяют насколько у человека натренирован конкретно этот навык, и корелляция с успешностью выполнения рабочих задач тут отнюдь не полная.
UPD: почитал решения, можно за линию сделать оказывается, у меня было решение за O(nlogk) - забавная задачка :)
К сожалению это потребность платформы, практика показывает, что с настройкой умных библиотек для работы с кафкой (даже при разумных дефолтах), люди справляются очень плохо — слишком много денег теряется на факапах, связанных с этим.
Систему делали для того, чтобы поставить её перед текущим боевым кластером, соответственно нагрузка на него определяла требования к прослойке.
Те самые миллионы rps - это нагрузка от тысяч различных потребителей по методам кафки produce и fetch (не единичные сообщения!). Мы постоянно работаем над оптимизацией потребителей через убеждение и тюнинг платформенных библиотек, но текущая ситуация именно такая.
Консьюмеров мы конечно уже реализовали, в статье об этом написано.
Как и задумывалось, api предоставляет сильно упрощённый функционал, его для большинства сценариев хватает.
Абстракция, разумеется, не идеальная — если сделать клиентов-консьюмеров больше чем партиций, то лишние будут простаивать. Это сделано намеренно, чтобы не усложнять реализацию.
NATS к сожалению обеспечивает лишь гарантии at most once в безброкерном режиме, а с брокером смысл его использования теряется. Кроме того задача переезда на него гораздо тяжелее чем задача переезда на grpc-прокси перед kafka без переезда данных.
Ну и проблемы с библиотеками от этого никуда не деваются :)
Я в процессе отладки не раз подозревал GC, но ни разу он не был виновен - трейсинг хорошо позволяет отслеживать такое. На горячем пути в grpc и franz-go действительно в основном пулы объектов под капотом.
Идея про С++/Rust расcматривалась скорее в полушуточном режиме, поскольку мы не упирались в язык, а в команде экспертизы по Go заметно больше :)
Для подобных систем в целом валидно отправлять каждое событие в кафку, другое дело, что эти отправки стоит батчить, чтобы не создавать чрезмерную нагрузку на брокеры.
Потребность управлять поведением клиентов - как раз одна из основных причин создания data-bus, там зачастую что-то нездоровое происходит.
Тогда возможно вам будет интересно ознакомиться с проектом https://github.com/mailgun/kafka-pixy, хоть он и не имеет полноценной поддержки (последний релиз был в 2019), но как минимум из него можно черпать вдохновение :)
Одна из ключевых целей, которую мы преследуем — это снижение сложности клиентских библиотек.
Библиотеки для работы через grpc гораздо проще чем библиотеки для работы с kafka, у нас более-менее активно используется 4 языка и на каждом свои либы с кучей подводных граблей, поддержка платформенных адаптеров вокруг них весьма болезненна.
По поводу конфигурации кластера не подскажу, возможно смогут ответить коллеги.
Клиент получит свой ack только после того как батч будет записан на брокеры.
ProducerLinger влияет на время накопления сообщений перед тем как они будут записаны, всё это время клиент ждёт подтверждения.
Если же клиент умрёт и сообщение в этот момент будет записано, то он просто запишет его ещё раз после рестарта — дублирование сообщений допустимо при at least once.
Недурно! А скорость поиска? И какого размера кластер это добро обслуживает, если не секрет?
А какое у вас примерно количество записей в базе и рейт запросов по ним?
Это вот любопытно на самом деле - а зачем ставить себе цель отсекать кандидатов?
Они могут решать задачи бизнеса? Могут.
Делают это не хуже литкодовцев? Не хуже.
Так зачем тогда мучать и их и интервьюеров?
Это егэшная задачка по информатике, btw. Сдавал недавно (так вышло) - мне вот ровно она попалась, за 15 минут не уложился решить, сейчас интереса ради попробовал на leetcode - полчаса ушло с учётом вспоминания синтаксиса С++.
Хз насколько это вообще показательно, очень уж сильно зависит успешность решения таких задачек от набитости руки и состояния в моменте - в итоге алгоритмические секции просто проверяют насколько у человека натренирован конкретно этот навык, и корелляция с успешностью выполнения рабочих задач тут отнюдь не полная.
UPD: почитал решения, можно за линию сделать оказывается, у меня было решение за O(nlogk) - забавная задачка :)
Это текущая нагрузка на кластер, прокси просто должна с ней справиться, иначе она станет блокером роста бизнеса.
К сожалению это потребность платформы, практика показывает, что с настройкой умных библиотек для работы с кафкой (даже при разумных дефолтах), люди справляются очень плохо — слишком много денег теряется на факапах, связанных с этим.
Прекрасный вопрос!
Главный ответ такой: в большой компании людям не очень интересно разбираться с тонкостями настройки kafka. Это хорошо , согласуется с опытом Avito.
В итоге мы реализовали упрощающий pub-sub интерфейс, позволяющий не думать об этом.
Систему делали для того, чтобы поставить её перед текущим боевым кластером, соответственно нагрузка на него определяла требования к прослойке.
Те самые миллионы rps - это нагрузка от тысяч различных потребителей по методам кафки produce и fetch (не единичные сообщения!). Мы постоянно работаем над оптимизацией потребителей через убеждение и тюнинг платформенных библиотек, но текущая ситуация именно такая.
Консьюмеров мы конечно уже реализовали, в статье об этом написано.
Как и задумывалось, api предоставляет сильно упрощённый функционал, его для большинства сценариев хватает.
Абстракция, разумеется, не идеальная — если сделать клиентов-консьюмеров больше чем партиций, то лишние будут простаивать. Это сделано намеренно, чтобы не усложнять реализацию.
Безусловно вы правы.
Выбор оптимизируемой метрики определяется целью — в нашем случае нужно было держать нагрузку на продовый кластер без чрезмерного оверхеда.
Поскольку кафка занимается в основном перекладыванием байтиков, то и оптимизировали мы именно его :)
Хорошее замечание, спасибо.
NATS к сожалению обеспечивает лишь гарантии at most once в безброкерном режиме, а с брокером смысл его использования теряется. Кроме того задача переезда на него гораздо тяжелее чем задача переезда на grpc-прокси перед kafka без переезда данных.
Ну и проблемы с библиотеками от этого никуда не деваются :)
Я в процессе отладки не раз подозревал GC, но ни разу он не был виновен - трейсинг хорошо позволяет отслеживать такое. На горячем пути в grpc и franz-go действительно в основном пулы объектов под капотом.
Идея про С++/Rust расcматривалась скорее в полушуточном режиме, поскольку мы не упирались в язык, а в команде экспертизы по Go заметно больше :)
Для подобных систем в целом валидно отправлять каждое событие в кафку, другое дело, что эти отправки стоит батчить, чтобы не создавать чрезмерную нагрузку на брокеры.
Потребность управлять поведением клиентов - как раз одна из основных причин создания data-bus, там зачастую что-то нездоровое происходит.
Посмотрел крупнейших потребителей - в топе рекламная сеть, аналитика и система защиты от ботов.
Тогда возможно вам будет интересно ознакомиться с проектом https://github.com/mailgun/kafka-pixy, хоть он и не имеет полноценной поддержки (последний релиз был в 2019), но как минимум из него можно черпать вдохновение :)
Вы оперируете интересными числами неизвестного происхождения в своих предположениях :)
Не думаю, что я смогу комплексно ответить на ваш вопрос за пределами уже сказанного.
Нагрузка на гейтвее скорее ближе к сотне тысяч rps, а дальше микросервисная архитектура делает своё дело — у нас сейчас около 4 тысяч сервисов.
Одна из ключевых целей, которую мы преследуем — это снижение сложности клиентских библиотек.
Библиотеки для работы через grpc гораздо проще чем библиотеки для работы с kafka, у нас более-менее активно используется 4 языка и на каждом свои либы с кучей подводных граблей, поддержка платформенных адаптеров вокруг них весьма болезненна.
По поводу конфигурации кластера не подскажу, возможно смогут ответить коллеги.
Клиент получит свой ack только после того как батч будет записан на брокеры.
ProducerLinger влияет на время накопления сообщений перед тем как они будут записаны, всё это время клиент ждёт подтверждения.
Если же клиент умрёт и сообщение в этот момент будет записано, то он просто запишет его ещё раз после рестарта — дублирование сообщений допустимо при at least once.