Comments 14
Очень полезная статья, спасибо!
Большое спасибо. Особенно, за картинки.
Спасибо за статью. А что по времени? Сколько времени занимает ребалансировка?
Наверное тут сложно однозначно ответить, так как зависит от кучи факторов: Мощностей брокера, количества активных партиций, как быстро происходит обработка сообщений, как быстро новые поды ackают запросы на вхождение в группу, сам алгоритм партишн асаймента. На практике скажу что в более менее активном топики это происходит достаточно быстро, в пределах 10 секунд. Думаю точное число можно узнать только эмпирически :)
соглашусь с @Derfirm. По времени занимает по разному, в зависимости от среды, ресурсов, числа консьюмеров, протокола, числа топиков, партиций и т.д. Тут надо сравнивать в одной и то же среде разные протоколы и разные сценарии. Например, eager vs coop-sticky и добавление/удаление n-консьюмеров.
Здравствуйте, очень глубокий материал, большое спасибо:) Из хороший новостей - большинство описанной работы не нужно кодить самостоятельно, благо большое количество библиотек, фреймворков уже написано/портировано на практически любой язык. И вот отсюда вопрос, какой фреймворк/язык наиболее комфортный и какой посоветуете?
В этом вы правы. Для кафки очень много клиентских библиотек, где все описанное реализовано и доступно через удобные абстракции. Но всё таки, при работе с какой-то технологией, при решении каких-то особых задач, рано или поздно приходится выходить за рамки абстракций и погружаться в тонкости. Да и вообще, в целом хорошо понимать как-что работает, даже если реализовывать не придется. Надеюсь, что в этом моя статья будет полезна.
Конкретно я пишу на c#/.net. Для .net толковая библиотека - confluent.kafka.net (правда сейчас мы мигрируем на прослойку поверх grpc - об этом есть статья в блоге Озона). Conflient.kafka.net - библиотека вокруг неуправляемого кода (поверх librd) и у нее есть свои приколы и проблемы (удивляюсь, почему до сих пор нет достойной родной библиотеки).
Посоветовать язык сложно - зависит же от круга решаемых задач. Для микросервисной разработки c# весьма хорош. Мощный, выразительный, мультипарадигменный язык. С широким спектром и поддержкой фреймворков и инструментов.
Очень интересная статья, спасибо.
Ох уж эта важная гарантия обработки партиции не более чем одним конзюмером, которая не является гарантией и будет довольно регулярно стрелять в ноги программистам. Чего только не придумали в кафке чтобы оно было почти гарантией, но распределенные системы не обманешь. Sad, but true. Тут надо интеграцию с системой хостинга чтобы кафка могла точно-точно прибивать старых конзюмеров и только тогда запускать новых. Ну или с помощью версии лидерства над партицией бороться со старыми конзюмерами.
Самое грустное когда люди ошибочно считают что кафка даёт эту гарантию и потом пишут код, полагаюсь на неё, ну а далее возникают различные весёлые кейсы, после которых очень приятно ночью сидеть на онколле.
тут нужно рассматривать систему не в вакууме, а в реальности.
Есть такое исследование - FLP (Fischer, Lynch, Paterson). Вывод из него следующий:
В асинхронной распределённой системе с хотя бы одним ненадёжным процессом не существует детерминированного алгоритма, гарантирующего достижение консенсуса за конечное время.
То есть всё? расходимся? не занимаемся построением асинхронных, распределенных систем?
Конечно же нет. Добавляем в систему таймауты, рандомизацию и отказоустойчивость и в большинстве случаев у нас все хорошо.
Т.е. если мы берем в расчет не какую-то внешнюю не доверенную сеть, а внутреннюю (а мы ею управляем, начиная от брокеров и заканчивая клиентами), то все в наших руках.
Конечно могут быть случаи, когда "кривой" клиент не отреагировал на событие ребаланса, но что вам мешает довести его до правильных кондиций? Если вы не укладываетесь в таймауты (обычно в библиотеках это 5 минут), то что мешает его увеличить?
Тут уже будет трейдофф между "делаем большой таймаут == возможный долгий даунтайм, например если конзюмер погиб по ООМ" vs "гарантия нарушается" и придётся выбирать из двух зол.
но если он погиб по ООМ, то значит не нарушается? он же погиб, значит партицию не слушает, значит ею завладеет после таймаута кто-то другой.
а если погиб только консьюмер, а обработка продолжается, то опять всё в ваших руках - почините консьюмер, чтобы не погибал. Или чтобы погиб, а в месте с ним и обработка, в контролируемый вами таймаут.
Kafka: ребалансировка изнутри