Transcription
Для начала, кто я такой? Меня зовут Андрей Серебрянский. А я занимаюсь Кавкой довольно давно. А сейчас я разрабатывал, разрабатываю Кавка в IDBs. Topics — это такой брокер сообщения от Яндекса. Он используется в Яндексе. А, ну, на самом деле, снаружи тоже, но это неважно. Вот я туда прикручиваю, например, транзакции кавкянские к этому брокеру. А с другой стороны, я до этого 5 лет строил всякие стриминговые платформы. Это платформа, которая помогает другим командам разработки в реальном времени данные обрабатывать, а, во всяких крупных банках. А, то есть видел много разных кейсов того, как с Кавкой можно работать, разных поломок, разных граблей. В общем-то, о них я сегодня и буду рассказывать. Вот.
А получается, я видел Кавку и изнутри, как разработчик, типа, как она работает, собрать исходники, написать какой-то аналог на плюсах в Яндексе. И с другой стороны, а, видел, как она, а, используется разными командами, пока строил стриминговые платформы. Вот. Ну, и, конечно, я много про неё рассказываю. Вот даже решил записать про это курс. Открытый урок такому курсу, а, на всяких разных конференциях, возможно, мы с вами на конференциях виделись и перепи.
А о чём сегодня мы поговорим? Я сначала начну с того, как вообще Кавка появилась, как в ней работает чтение, а откуда вообще как оно устроено и почему оно работает именно так. Затем мы поговорим, зачем вообще нужна Кавка, зачем она вам в бизнесе может пригодиться, ну, в смысле, как эээнд может помочь бизнес за счёт Кавки, а чем Кавка отличается от очередей типа Rabit MQ. А потом мы немножко пройдёмся по вопросам собеседований. И среди этих вопросов обязательно будет, как гарантировать порядок. А когда удаляются данные в Кавка, там не всё так просто, ни одним ретеншном единым. А когда использовать Кавка, когда очереди, это вообще супер частый вопрос на System дизаign интервью. Вот. Ну, и в самом конце я предложу записаться на Q&A со мной тоже бесплатно завтра, а где мы вообще любые вопросы про Кавку ваши тоже сможем обсудить. Так. Поехали.
А Кавка используется почти в каждой IT-компании. А, и то, как вас сегодня много, в общем, это подтверждает, что Кавка суперпопулярный продукт. Сложно представить себе компанию, в которой Кавки нет. Используется она для самых разных целей. Ну, конечно, чаще всего вы встретите её для обмена между микросервисами. Типа два приложения хотят какие-то сообщения друг другу отправить. И вот они это делают обычно через Кавку. Зачем, почему именно через Кавку, мы ещё сегодня поговорим. Но кроме обмена между микросервисами есть ещё куча применений. Например, в большинстве компаний, где я работал, именно в Кавку собирали всякие клики, переходы на экраны, показы рекламы, потому что это огромный поток, и этот поток нужно куда-то приземлить. И Кавка — отличное место для этого. А также очень часто в компаниях Кавка используется как такая шина инфраструктуры. Туда собираются логи приложений микросервисов, метрики, трейсы. Это тоже большие потоки, и они чаще всего на Кавке. Ну и аналитика, bigтаa, вся эта движуха C тоже обычно не обходится без Кавки, потому что Кавка используется как место, куда со всей организации из разных базданных стекаются данные для того, чтобы потом сложить их в дата-платформу. Именно вот в таких компаниях, в датаплатформе я часто работал, а когда нужно все организации кучу данных собрать в одну Кавку. То есть, на самом деле, с Кавкой может столкнуться не только работая в бэкэнде, но и работая датаинженером и работая где-то в инфраструктуре. Короче, очень много где Кавка применяется. Применяется по-разному.
Кавки в мире много, как я уже сказал. Появилась она когда-то в 2011 году в Лингне, то есть уже больше 10 лет назад, ну, 15 лет назад даже. И сейчас LinkedIn её до сих пор использует супер интенсивно. Порядка 200 ГБ в секунду. Это огромный поток. Вообще наши телефоны столько не хранят, сколько LinkedIn передаёт в секунду. А больше 10.000 серверов. А, кстати, брокер — это один сервер в кластере брокера сообщений. В Кавке один сервер — это брокер. Вот. А в Нетфликсе, в общем, всё, что вы смотрите, кликаете, ставите на паузу, оно всё сохраняется в виде событий. Тоже в шину данных в Кавку. А в России Кавка тоже распространена. Я взял два там конкретных примера, про которые я хорошо знаю. А, ну, вообще Кавка есть в куче во всех организациях фактически, про которые я знаю. А в Яндексе через Кавка Compatible брокеer, который мы как раз зарабатываем, прокачивается 150 Гб в секунду поверх больше чем 2.000 серверов брокеров. А в Озоне, насколько я знаю, есть огромный кластер X200 брокеров, тоже обрабатывающий все вот эти события, которые есть в Озоне. Они об этом часто на метапах и на докладах рассказывают.
А, поехали к нашему докладу. Уже начнём мы с короткого интродакшена. Не буду сильно на этом задерживаться. Про то, как вообще появилась Кавка. А когда-то давным-давно, а на самом деле ещё в девяностые были синхронные вызовы. Один сервис вызывал другой, а это могло быть внутри одного огромного монолита. Вот. Ну, в общем, один сервис вызывал другой. И а в этом была проблема. Дело в том, что если один сервер заваливал другой запросами, то тот мог просто сложиться и сказать: "Блин, я не выдерживаю. Я не могу так много запросов обработать и отказать". А это одна проблема. А другая проблема состоит в том, что у нас могут случиться каскадные отказы. Как только у нас отказывает один компонент из-за высокой нагрузки, другой не может получить от него ответ, тоже отказывает. В итоге страдают пользователю. Кстати, прокпрешер. Backкре — это такое понятие в асинхронных системах, да и в синхронных тоже, когда у нас одна система оказывает давление на другую систему, и хорошо бы иметь возможность как-то это давление контролировать. Вот в Кавке контролировать это давление можно. Мы дальше поговорим о том, как это работает.
А чтобы это решить, когда-то умные ребята решили, что мы хотим добавить очереди. Когда-то ещё в Амазоне в 2004 году появился SQS Simple Qвис, а RabitQ появился, по-моему, в 2007. Вот. А всякие очереди от IBM ещё в девяносто восьмом, по, по-моему, появился IBM MQ. Вот. То есть, а, очеди придумали довольно давно, именно чтобы решать вот эти вот проблемы, а, жёсткой связанности двух сервисов, когда один обращается к другому, происходят каскадные отказы, пользователи страдают. Что же они придумали? А они придумали, что контроль вот этого бэкпреша, давление одного сервиса на другой, может взять на себя брокер сообщений. А, представим вам один сервер. Он быстро пишет, а, и эти быстрая запись спокойно обрабатывается месседж-брокером. При этом второй сервер не перегружается, он в своём темпе вычитывает оттуда сообщение, и когда bir брс записи пройдёт, то читатель постепенно всё дочитает. Да, возник какое-то отставание, но по крайней мере система не отказала. Система продолжила работать, и это очень ценно. А каскадные отказы тоже перестали быть проблемой, потому что а наш писатель не зависит от читателя. А даже если вдруг читатель сложится по какой-то причине нагрузку он не выдержал, какую-то ошибку словил, первый сервер не отказывает. Он продолжает работать, потому что он спокойно может писать свои сообщения месседжброкеer. Мы развязали читателя и писателя и тем самым решили проблему каскадных отказов.
А что было дальше? Нагрузка множилась, а появилось много брокеров на на экране. Просто привёл те, которые мне всплыли в голову. На самом деле гораздо больше. Есть, э, платные, проприетарные брокеры, есть бесплатные, openсоourсные. В общем, брокеров появлялось больше, нагрузка на брокеры росла, а брокеры реагировали на это и учились распределять нагрузку. Они сказали: "Давайте, у нас будет не один сервер, а несколько в нашем кластере брокера сообщений". И а на этих серверах на разных будут жить разные очереди, чтобы нагрузка распределялась равномерно. Но всё ещё оставалось одновычное горлышко, очередь. Собственно, мы можем разнести очереди на разные сервера, но а всё равно одна очередь остаётся бутылочным горлышком. Почему? Потому что она может разрастись, а масштабировать сервер бесконечно невозможно. У одного сервера есть какой-то предел масштабируемости. Мы не можем вставить бесконечное количество оперативной памяти или бесконечное количество ядер в сервер. Всё-таки даже самые большие серверы, они их мощность конечна. А одна очередь может разрастаться и забирать все ресурсы этого сервера. И если вы посмотрите внимательно на картинку, там за огромной оранжевой очередью есть маленькие такие серые и другие очереди. Вот те очереди, которые им не повезло оказаться на одном сервере с а этой толстой очередью, они будут страдать. Вот. А добиться такой вот перегрузки в целом не очень сложно. Если мы отправим десятки тысяч запросов в секунду на запись, уже сервер будет довольно сложно именно с точки зрения сети проживать такие большие RPS. Если ещё параллельно из этой очереди читаются, в общем, возникают проблемы.
А кроме проблемы масштабирования, того, что у нас масштабирование одной очеди ограничено возможностями одного сервера, была ещё одна проблема. Если вдруг что-то неправильно обработали, ну, то есть мы вычитали сообщения, что-то с ними сделали, а потом поняли, что неправильно обработали, то вычитать их повторно уже нельзя, потому что брокер, а, классический удаляет сообщение сразу после того, как, а, они из него были прочитаны. Можно попросить писателя переотправить эти сообщения, но это, на самом деле, не всегда возможно. Чаще всего писать это сложный процесс, нужно договариваться с другой командой. В общем, далеко не всегда возможно. А дебаг проблем тоже довольно сложный, потому что мы не знаем, какие сообщения находятся внутри. А после того, как мы вычитали сообщение из месседжб брокера, они оттуда удаляются. И посмотреть, блин, а что же мы запроцесили? Что там была такая за фигня, которую мы не смогли обработать, уже нельзя. И вот с учётом всех этих проблем, нагрузка, сложный дебаг, сложная переобработка сообщений, появляется Кавка.
А что Кавка делает с проблемойша? То есть давление одного сервиса на другой. Кавка вводит новое понятие. Топик. Топик — это сообщение, относящееся к одной теме. Например, в одном топике могут быть все сообщения о проведении банковских транзакций, а сообщения о об открытии кредитов будут в другом брокере, а в другом топике. Притом здесь, наверное, а что с бэкпреше? Здесь скорее даже больше вопрос, что с проблемами большой нагрузки, а это понятие топик. Топик распределён на несколько серверов, а, и состоит внутри топик из партий. То есть топик — это такая абстракция. Физически данные лежат в партиях. А, и запись в топик равномерно распределяется по брокеру. А каждая партия на отдельном сервере. У нас много может быть писателей, а писатель в Кавке называется продюсер. Продюсеры пишут на разные сервера, нагрузка размазывается. Если вдруг нам не хватает серверов, чтобы работать текущую нагрузку, мы просто добавляем новые сервера, добавляем новые партицы и нагрузка размазывается. Всё хорошо, мы выдерживаем даже увеличение нагрузки. С нагрузкой разобрались, мы её держим. Мы можем масштабироваться. Можем масштабироваться за преде пределы одного сервера.
А то, что было невозможно, невозможно с месседжброкером, что с повторным перечитыванием сообщений. Как быть, если в Кавка мы хотим перечитать сообщение? А ответ простой. В Кавка можно читать данные сколько угодно раз, сколько угодно раз их можно перечитывать. Они не удаляются после прочтения. В Кавка сообщения удаляются согласно политике RENtion. По умолчанию это 7 дней после записи. То есть мы записали сообщение, оно по умолчанию через 7 дней удалится. Мы ещё об этом поговорим, а, чуть-чуть позже, потому что, а, тут есть нюансы, когда именно сообщения удалятся. А мы говорили с вами о политике retтенtion. Через 7 дней после записи сообщение удаляется. До этого их можно сколько угодно раз перечитывать. А срок хранения сообщения управляется политикой. То есть это не единая политика для всех топиков. Её можно менять. Можете выставить минуту, можете выставить месяц, можете выставить год, сколько хотите, столько можно сообщения хранить. Ещё можно сказать, что нужно хранить по объёму, то есть не дать топику переполниться, остать слишком большим. Но я вам честно скажу, в проде эту настройку используют редко, потому что она непредсказуемая. Если вы говорите Retenstion Bytes, например, говорите максимум размер топика должен быть 1 ГБ, то а сообщения могут удаляться непредсказуемо для вас. Сегодня они удаляются на следующий день, потому что у вас очень много было записей и за 1 ГБ забился, а завтра они удаляются через месяц, потому что записи было мало. Мы с вами поговорили про retтеtion Bytes. А сообщение можно теть сколько угодно раз в течение всего retтенtion периода.
Как работает чтение в Кавка? Это, на самом деле, уже начинается немножко вопрос собеседования, потому что вот когда приходишь на позицию, на которой используется Кавка, а тебя могут начать потихонечку раскручивать, спрашивать типа насколько хорошо ты разбираешь, насколько хорошо понимаешь. И обычно это хороший водный вопрос, из которого можно дальше уже вглубь начать копать, а насколько хорошо человек погружен в доменную область Кавки. Итак, как работает чтение в Кавке? А в Кавке есть понятие консюмера, то есть это процесс, который читает. Консюмеры при подключении указывают параметр Group ID. Консюмеры с одинаковым Group ID объединяются в Consumer Group. Такое важное понятие Consumer Group. Внутри консюмер группы партиции топика делятся равномерно между участниками. То есть у нас на картинке, как видите, три партиции и два консюмера в одной консюмер группе. Соответственно, первый консюмер получит одну партицию, а второй две. Ну, он не попытается равномерно забалансировать, но так партиции не равно количеству консюмеров, кому-то досталось чуть больше. Если мы добавим ещё консюмеров, то а мы постараемся партицы распить равномерно. Но если консюмеров будет больше, чем партий, то а лишние консюмеры будут простаивать. Вот, например, сейчас на картинке четвёртый консюмер простаивает и ничего не делает. топика может быть сколько угодно групп. То есть вы можете один раз записать данные, а потом много разными консюмерами их вычитать. И это, на самом деле, суперважная фишка Кавки, которую мы много где использовали, когда вы один раз заливаете данные, например, кликстрима, а потом используете их для маркетинговых коммуникаций, чтобы определить, кто куда кликал, для поддержки, чтобы определить, что кто-то не справлялся, не смог на правильный экран зайти. для антифрода, чтобы определить, что кто-то такое реально было в банке. Мы по кликстриму определяли, что человек находится под давлением, под управлением мошенника просто благодаря тому, какой паттерн кликов приложении у него. В общем, единожды залитые данные вы храните один раз, платите сохранение один раз, а читать можете многими разными приложениями, извлекать из них пользу много раз. Вот это всё делается за счёт того, что один топик можно читать разными консюмер группами, и каждая консюмергруппа получит все сообщения из всех партий.
О'кей. А дальше обычно в собеседовании спрашивают: "О'кей, понятно, а что будет, если консюмер упадёт? Как он при переподключении поймёт, откуда начать читать?" В Кавке есть понятие офсе. Офсе — это порядковый номер сообщения, и каждый консюмер может закомитить осет, то есть сказать: "Я дочитал до такого-то сообщения. Кавка, пожалуйста, сохрани это". И Кавка на своей стороне это сохранит. А вам со своими приложениями, своими конзюмерами ничего сохранять не нужно. Как Кавки есть специальный API, который позволяет сохранять в себя офсет. Вот сейчас на картинке у нас есть топик какой-то с одной партий. В нём есть четыре сообщения. У каждого сообщения есть офсет 0 1 2 3. Ну и какие-то данные внутри. Вот. А консюмер говорит: "Я дочитал до первого сообщения". Говорит: "Закомить, пожалуйста, для нулевой партиции первый offset. Если консюмер упадёт и поднимется заново, ну или поднимется какая-то другая версия этого консюмера, то он при старте у Кавки спросит: "А докуда я дочитал?" Кавка скажет: "До первого офсета, а консюмер решит читать со следующего". О'кей, значит, надо читать со следующего. Соответственно, если вы захотите в Кавке перечитать сообщение, например, вы что-то вычитали, поняли, что обработали неправильно, вам просто нужно сдвинуть офсет консюмера в этой партии. Например, это можно сделать так. На экране команда для кавка CLI, то есть Commandline интерфейса, для интерфейса в терминале. Но на самом деле, а то же самое всё можно сделать и через всякие UI кавки, а, короче, много разных интерфейсов обычно существует для того, чтобы такую операцию сделать.
Итого, зачем нам нужна Кавка и чем она отличается от от очередей? А Кавка, да и в целом брокеры сообщений, такие как Rabit MQ, IBMQ и другие, а были созданы для того, чтобы контролировать бэкпреши, то есть контролировать давление одного сервиса на другой и разделять их, разделить читателей и писателей, чтобы решить проблему каскадных отказов. А очередь прекрасна, она хорошо решила эту задачу, но она масштабируется только до одной машины. И в этом её проблема, что машины, сервера не масштабируются бесконечно. А топик в Кавке, в отличие от очереди, состоит из партиции и позволяет распределить нагрузку по многим машинам. То есть, на самом деле, возможно, слышали в других, а, занятиях это понятие. Если очереди масштабируются вертикально, то есть нам нужно добавлять физических ресурсов, оперативной памяти, ЦПУ и так далее, то топики масштабируются горизонтально. Мы можем добавлять новые машины, новые партиции в топики и тем самым увеличивать пропускную способность. И в этом основная, на самом деле, преимущество Кавки. А в очереди сообщения удаляются сразу же после обработки. Из-за этого нам сложнее дебажить, сложнее повторно обработать сообщения. А в топике сообщениях хранятся согласно политики retтенtion. По умолчанию это 7 дней. То есть сообщение можно сколько угодно раз перечитать. Про то, когда применять очереди, а когда топики в Кавке, мы поговорим дальше. И здесь я сделаю паузу и начну отвечать на вопросы в чате.
Спрашивают в чате: "Перекатываю с доnet на GO. Говорят, рынок сейчас не очень ждёт таких спецов". Что думаете? Не знаю, честно не знаю. У моих коллег, у меня много коллег, которые пишут на Го в Яндексе в целом много пишут на го. Кажется, что бэкэнды на нём пишут. Так, всем привет. Так, у нас супер из разных мест и разного уровня люди приходят. Очень круто. Спасибо большое. Разного возраста, офигенно разного пола. очень разная аудитория. Привет. Будет ли про ребалансировку? Вопрос от Романа. А про ребалансировку в этом открытом уроке не будет, но это открытый урок к большому курсу, который я делаю, который запустится осенью. И там будет целое занятие, посвящённое чтению и скавки. Там будет не только про ребалансировку, там будет про шторм ребалансов. Это когда читатели вместо того, чтобы читать, просто бесконечно пытаются договориться друг с другом. А там будет про схематизацию данных, там будет про паттерны обработки недоставленных сообщений, в общем, там будет много чего именно про чтение. Это вот одно занятие целиком будет посвящено тому, как разработчику эффективно читать и скавки. А в этом занятии, к сожалению, не будет. А так, а другие уроки нельзя посмотреть? А пока нельзя. Это только открытый урок.
Вбит MQ тоже есть топики. Какая разница между ними? Прекрасный вопрос. Спасибо. А, действительно, Ребит добавил топики какое-то время назад. Аа, насколько я помню, топики всё равно, несмотря на то, что они, в общем, очень хорошо повторяют аа Кавку по гарантиям, они имеют не тот API, который в Кавке. Вы не можете использовать Кавка API для того, чтобы работать с топиками в Ребите. А большинство приложений за 15 лет существования Кавки всё-таки уже научились именно по Кавка работать. А все эти истории про партиции, распределение данных, обработку, всё, про что этот курс, оно работает именно по определённым протоколом Кавкянским. И даже есть много брокеров новых, которые появляются. Например, есть э Red Panda и другие. А Warbstream, Red Panda, аb на самом деле яндексовый, они все работают по Кавка протоколу. Вот. А Ребиit, по-моему, по Кавка протоколу не умеет.
Вы видево отректо нужно генерировать ключи демпотент для защиты от дубликатов? А, да, про это мы поговорим сегодня, наверное. Есть ли в Кавка ограничения размер одного сообщения на уровне топика партиции? По-моему, есть. И оно равно 1 Мб, если я правильно помню, его можно менять, но не на уровне партиции, а на уровне топика. А вроде лок удаляется, если не ошибаюсь, а не само сообщение pretention seconds. Да, Дмитрий, вы правы. И это будет дальше в частных вопросах собеседования.
Как несколько консюмеров в одной группе перебалансируется между партиями? Надеюсь, я ответил на это в презентации. Но если коротко, Кавка старается справедливо распределить партиции между консюмерами. А ещё есть разные алгоритмы балансировки. Мы о них поговорим в третьей лекции, не сегодня, про то, как вообще устроено чтение. Но если коротко, то Кавка старается справедливо распределить партиции между консюмерами, чтобы всем досталось примерно одинаковое количество партиций. А плюс вы можете всегда написать свой алгоритм балансировки.
Как, где Кавка хранит данные? Если инсребутнуют данные в партиции потеряются, прекрасный вопрос, Владимир. А Кавка хранит данные на дисках обычно, ну то есть на физических хардрайвах, там на сэсдшках, на хддшках. А и данные не потеряются, если инстанутнуть. Но это короткий ответ. Есть длинный ответ про то, как данные в Кавке их потерять и как я на самом деле несколько раз данные в Кавке терял. Разные способы. Про это будет у меня четвёртая лекция про Кавку и хайлот. А про Кавку большой организации, как гарантирует, что ничего не потеряется, даже если у вас откажет дата-центр, даже если у вас горят диски, даже если уборщица выключит из розетки сервер. Вот. Но короткий ответ. По умолчанию Кав хранить данные надёжно, персистентно на дисках и не должна терять.
А, да, отвечают на вопрос Владимира ниже. Бывает так, что один костюмер прочитал, не закомитил чтении и тут же запись читает другой консюмер? А нет, а так как одну партицию одновременно может читать только один консюмер, но бывают всякие сбои. Один консюмер вычитал, действительно не успел закоммитить. В этот момент случился ребаланс и другой консюмер почитал. Вот такое может быть. Но в штатном процессе, то есть если никаких ребалансов, а смен, а распределения партицы между читателями не было, то такая штука не произойдёт.
А каким инструменты пользуются для просмотра топиков, сообщений, сброса, офсетов и так далее, если есть ли готовы решение? Да, прекрасное решение AKHQ, абсолютно openсоourсное, бесплатное. А очень мне нравится. Есть другие, есть платные. Обычно во всяких, э, провайдерах, там, не знаю, типа Яндекс Clуда есть, а, свои юаи. Вот. Так что инструментов много. Мы на наших лекциях будем использовать HQ и научимся с ним работать.
А реплика партий только на чтение, пишем только в мастер. А в Кавке действительно существует репликация. И до недавнего времени, по-моему, даже до Кавки 4.0, до прошлого года читать можно было только с мастера и писать, читать с мастера. А в последних версиях Кавки, по-моему, можно читать с реплик, но мне нужно это уточнить.
Консюмер не обязан комитить свой offset, например, если сам запоминает свой последний осет. Конюмер комитит осет в Кавку. Это важно, а Кавка запоминает. Но я видел разные приложения. Например, при у Даженеров распространено, когда вы читаете и скавки и пишете в какой-нибудь ходуб, в какой-то огромное Datale. Там распространено хранить офсеты там же, где лежат данные. То есть вы сохранили в DATAL данные и там же офсеты храните. Так что консюмер вполне может хранить свои офсеты. И перед началом чтения сказать: "Кавка, я не хочу слушать, что ты там у себя сохранила, докуда я дочитал. Начни мне давать данные вот с этого офсета, который я у себя запомнил".
Так, вопросов-то много. Я боюсь, что мы сейчас можем всё время на это потратить. Но с другой стороны, это важно. Давайте я попробую довести. Давайте так, ещё пять вопросов, а дальше я побегу дальше. А завтра у нас будет ещё одна сессия Q&A, куда можно будет прийти и позадавать вопросы, те, на которые я не отвечу или которые я отвечу, кстати, может быть, сегодня после второй части лекции.
Что с безопасностью в Кавке? Несанкционированный доступ к получению данных и отправке данных. В Кавке Кавка существует 15 лет в суперкрупных организациях. Там придумали хорошие способы защитить данные. Если коротко, там есть access control листы и сель, вы можете сказать, а какие права есть у определённых ролей, а для доступа к каким-то сущностям. Есть сущности topic, consumer, брокеer, а возможно какие-то ещё. А сходу просто не помню, ну есть документация, можно набить в Гуглевка ACL и будет страничка хорошая от компании Confluent, описывающая, как это работает. Вот, соответственно, вы можете гранулярно выдать роли доступ на а какую-нибудь подстроку топиков. Вы можете выдать роли доступ только на чтение. На чтение только под определённым консюмером. Короче, безопасностью с Кавкой у Кавки неплохо. Подробно об этом тоже буду рассказывать в лекции четыре про хайлоты и корпорацию, про то, как свои данные защитить, про то, что делать, если у вас есть какие-то шумные соседи, которые могут прийти и занять все ресурсы кластера. Поговорим про это.
Консюмер сам в общается в Кавку за новыми сообщениями? А, да, Кавка работает по полмодели. То есть консюмер внутри, вам это не видно на самом деле, когда вы пользуетесь, например, каким-нибуд Java клиентом, но внутри консюмер постоянно опрашивает Кавку: "Есть ли у тебя новые сообщения? Есть ли у тебя новые сообщения?"
Когда лучше использовать transaction outbox, а, а когда коннект с дебе? Что надежнее, что лучше? В чём разница? Александр,
Прекрасный вопрос. Мне кажется, у меня даже есть про это доклад, но я не буду к нему отсылать, потому что не про то у нас занятие. А когда используется c connect + dbedium, когда transaction outbox? Я боюсь, что мы потеряем слушателей, которые не знают, что такое transactional outbox, cnx и dbedium.
А, но для вас, Александр, отвечу коротко. Моё мнение, что нужно использовать вместе, использовать и transaction outbox, и cnect + depum. Вы transтраншубоксом сохраняете в отдельную табличку, которая, а, ну, содержит какие-то денормализованные данные, а потом натравливаете Cnex DBUM на вот эту табличку transactional Outbox.
А подробнее о том, когда использовать, сорри, что столько у меня отсылок к лекциям, ну, просто нет времени ответить, а, подробно на этот вопрос. А у меня прямо целый блок слайдов про именно этот вопрос, когда transaction outbox, когда Cnect, как это настроить, что надёжнее, когда упадёт. Вот, с моей точки зрения, надёжно именно так, как я описал и то, и другое использовать, потому что вы, с одной стороны защищаете данные в базе и можете их легко эволюционировать, а с другой стороны э получаете все преимущества CDC и очень быстрого доступа к данным.
Так, два вопроса я ещё обещал ответить. Что будет, если упадёт хост с партицией? А, опять же, подробный ответ не смогу сейчас дать, он в лекции. Ну и у нас нет на это время, но если коротко, а Кавка по умолчанию хранит данные в трёх, а репликах, а, соответственно, на трёх разных хостах. Один из хостов является мастером. Если упадёт хост с партицией, то Кавка просто передвинет мастер на другой хост, который, э, не отстал, и записи чтения продолжится с другого хоста незаметно для вас. То есть все SDK кавки, ну, то есть все клиенты кавки, они умеют обрабатывать такую ситуацию, когда хост перезагрузился, а вы вычитываете за данные, а пока вычитывали данные, хост перезагрузился, издики это заметил, пошёл у Кавки, спросил: "А где новый лидер партиции живёт?" Установил соединение с брокером, где живёт новый лидер партицы, и продолжу чтение. То есть вы увидите просто небольшую задержку, на самом деле порядка 600 мсекунд, а дальше всё будет в порядке.
Так, какие самые лучшие техники тестирования flow с кавкой? Анна, тут слово flow для меня непонятно. Это, возможно, название фреймворка, а возможно вы имеете в виду, а просто типафлоу разработки. А я предпочитаю, я отвечу про второе, про flлоow разработки, потому что фреймwork flow я не знаю. Аа я предпочитаю тестирование сest containers. Я раньше был долгое время Java разработчиком. Там прекрасная интеграция с теest containers, когда вы поднимаете прямо из кода docker контейнер с кавкой и можете в него писать, читать и так далее. Но а существуют разные реализации для конкретных фреймворков, например, для флинка, который работает с кавкой, или для Кавкаст Streams, который работает с кавкой, который эмулирует кавку прямо в а ваших тестах. И в этом случае я бы предпочёл вот такой вот эмулятор. Они ещё прикольнее и лучше позволяют всякое осёртить, проверять. Вот. Но опять же, это зависит от языка. Вот. А если не углубляться в конкретные языки, то моё предпочтение - это докерконтейнер с кавкой.
А я обещал ответить на пять вопросов, и я ответил, а дальше пойду а по курсу и после этого продолжу отвечать на вопросы уже в следующей Q&A. Основные вопросы собеседований про Кавка. Частый вопрос номер один: как гарантировать порядок обработки? Вот правда довольно часто спрашивают, и я, честно говоря, сам иногда спрашиваю, когда хочу проверить, насколько глубоко человек понимает устройство кавки. Этот вопрос позволяет понять, ну, в целом, насколько вы хорошо знакомы с моделью в Кавке, со всеми этими партициями, офсетами, ключами. Сейчас мы про это поговорим.
Итак, для начала зачем вообще гарантировать порядок? Ну вот представьте себе топик, которым вам, ну, прямо кровь из носа. Нужно гарантировать, что всё обработается в строгом порядке. И в этот топик попадает два сообщения. А топик с банковскими операциями. В этот топик попадает два сообщения. А каждый свою партицию. Пополнение счёта на 500 руб. И зачем покупка со счёта на 500 руб. Ну, наверное, кто-то положил себе деньги на счёт, а потом решил с него заказать Хендекславки что-то. А в каком порядке консюмер вычитает эти сообщения? А мы не знаем. он вычитает их случайном. В один запуск вычитает сначала пополнение, потом снятие, в другом сначала снятие, потом пополнение. Мы не знаем. А если консюмер вдруг обработает не в правильном порядке, то есть сначала вычитает снятие, то будет ошибка, типа на счету нет средств. Понятно, что пример вымышленный. В смысле, ну, в банках никто так не делает через консюмеров, э, в кавке по разным партиям. Вот. Но а, например, как кэшбэки делают с такой ошибкой, я видел.
А как гарантировать порядок? Нужно все сообщения, относящиеся к одному ключу, ну, то есть к одному счёту в данной ситуации, а положить в одну партицию, потому что все сообщения в одной партиции читаются в строгом порядке. То есть нужно, чтобы все операции по счёту 1 2 3 попали в одну партицию. Как такое сделать? В Кавка сообщения распределяются по партиям. А, да, сорри. Как кавка сообщения спяется по партиям и как сделать так, чтобы некоторые сообщения оказались в одной партиции? А при записи в Кавка можно сообщению явно указать номер партиции. О'кей, этот способ мог бы сработать, но он не очень масштабируемый, а вам нужно самим как-то это придумывать, распределять, не очень удобно. Но можно и не указывать, и тогда по умолчанию будет применяться настройка paritioner class. И вот это как раз то, что нам нужно для того, чтобы все сообщения с одним ключом попали в одну партицию. Как это работает? По умолчанию применяется следующая логика. Мы берём ключ сообщения. В нашем примере мы берём 1 2 3, а дальше происходит некоторая магия. Следите за руками, потому что, ну, на самом полезно понимать, как это работает, какие у этого процесса ограничения. Об ограничениях мы тоже поговорим. Итак, мы берём ключ сообщения и берём хэш от этого ключа. Хэш - это какое-то большое числовое значение. Дальше мы берём остаток отделения ключа на количество партиций. В нашем примере партиции две. Значит, мы берём остаток отделения на два. Остаток отделения нашего большого нечётного числа на два - это один. А значит, и писать нужно в первую партицию. Ну, это, кстати, не единственный способ того, как распределять сообщение по партиям. Существуют и другие. Например, есть Round Robin Partitioner, которые позволяет вам суперравномерно распределять. Нам в нашем примере это не подходит. Нам нужно в одну партицию класть сообщение. Соответственно, мы robitionшнер не будем. Просто я здесь его вставил, чтобы вы знали, что такое тоже бывает. Ещё можно придумать свой алгоритм партенирования, если вас не устраивает ни раунд Робин, ни вот это вот распределение по ключу. Вот. Ну, тоже довольно редко пригождается.
Итак, как же нам сделать, чтобы некоторые сообщения оказались в одной партице? Ответ простой. Легко указать этим сообщением один ключ, но есть нюанс. И в общем-то я прям честно видел, как ломаются продакшены об этот нюанс. Что будет, если изменится количество партиций? Ну, на самом деле, на самом деле, а, при неизменном количества партиций всё будет хорошо. А вот если добавить количество партиции, то у нас поменяется остаток отделения. Если помните, мы раньше брали вот это какое-то большое число, точнее, ну, хэш от нашего ключа, брали остаток отделения, он получался определённый, он был равен единиц. И все сообщения с ключом 1 2 3 имели бы один и тот же хэш и всегда писались бы в первую партицию. Круто. Но как только мы меняем количество партиций, остаток отделения тоже меняется. И вот мы уже пишем в другую партицию. И у нас снова есть проблема с тем, что мы не понимаем, в каком порядке консюмер обработает сообщение. А как же тогда нам увеличивать количество партиций, спросите вы? Опять же, подробнее это, наверное, мы разберём в курсе, но сейчас такие короткие рекомендации, а довольно больно. А если вам не важны гарантии порядка по ключу, вы просто увеличиваете количество партий и ничего страшного не случится. А если гарантии всё-таки важны, то в Кавке проще всего создать новый топик и мигрировать писателей, а затем читателей на него. Именно в таком порядке. То есть вы сделали новый топик, переключили запись в него, а с большим количеством партий, конечно же, у вас топик новый, а потом читателей, когда они всё дочитали в старом топике, переключили на новый. Если и это не вариант, например, вам нужно сохранять название топика, вы не можете просто переключиться на новый или у вас очень много читателей, писателей их долго мигрировать, а то здесь поможет downутайм. Останавливаете запись, ждёте, пока все читатели дочитают, увеличиваете количество партиций, запускаете запись и не подключайте новых консмергруп, пока не пройдёт retтенtion период. Таким образом, можно увеличить количество партии. Как видите, это довольно сложно. То есть на самом деле вот в Кавке есть вот эта сложность, то, то, что если вы заранее не выбрали правильное количество партий, потом их увеличивать может быть довольно проблематично. Есть всякие секретные стратегии, но сегодня на про них не успеваю рассказать.
А, итого, как гарантировать порядок обработки, если вас спросят о таком на собеседовании? Кавка гарантирует строгией порядок только в рамках одной партиции. В рамках всего топика порядок не гарантируется. Мы можем гарантировать порядок в рамках ключа, потому что по умолчанию все сообщения с одним ключом попадут в одну партицию. Но в таком топике а нужно очень аккуратно менять количество партиций, чтобы не сломать вот эти гарантии.
Переходим к частному вопросу на собеседование номер два. Когда удаляются данные в Кавка? И на самом деле этот вопрос даже у нас был в чатике сегодня, так что супер, что мы его разберём. А всё просто же вы скажете: "Через 7 дней согласно политике Rнtion сообщения удаляются". Да, но если вдруг вас захотят проверить чуть поглубже, понять, а вот насколько вот правда хорошо вы понимаете устройство внутренняя Кавка, то здесь возникает интересный, а, дада, и сообщения перечитаются. А, но тут возникает интересный нюанс. А правда ли Кавка следит за каждым сообщением, когда его пора удалить? Ведь в Кавку можно лить миллионы, десятки миллионов, сотни миллионов сообщений в секунду. И Кавка отслеживает каждого из них. Ну, конечно, нет. А внутри партиции сообщения разложены под так называемым сегментом. То есть физически на диске лежат вот такие вот локфайлики. Я даже тут специально привёл нейминг, как они называются. То есть, если вы запустите свою кавку и зайдёте, а, на файловую систему, где она хранит данные, вы увидите именно такие вот файлики. А, и вот в эти лог-файлы, а, собственно, пишутся сообщения. Log он называется, потому что это такая структура данных, который всегда запись идёт в конец. Сегмент считается открытым и в него пишутся данные. Пока он не закроется. А закроется он по двум условиям. Либо по условию сегмент баййтes, то есть он стал слишком большим, либо пройдёт сегмент millликонс, то есть прошло заданное в конфигурации топика, а промежуток времени. Вот. То есть, ну, либо слишком долго храним сегмент, либо слишком большого размера он стал. В нашем примере на экране у нас, а, пишется в топик по одному сообщению в день. Такой просто вот искусственный пример. И наш сегмент закрыт на запись, потому что прошёл дефолтный сегмент milliseconds time out 7 дней. Дальше сообщения будут писаться в следующий сегмент. Вопрос: когда удалится сообщение а номер один в топике? Ответ. Оно будет удаляться довольно долго, потому что оно удалится тогда, когда удалится весь сегмент, а сегмент удалится, когда прошёл ретенtion период. Сейчас он не удаляется. Видишь, видите, у нас восьмое, девятое сообщение записалось, то есть прошло 2 дня, сегмент не удаляется, потому что 7 дней ещё не прошло. Вот когда пройдёт 7 дней с последнего сообщения, тогда сегменты удалится. То есть, обратите внимание, в нашем примере сообщение номер один хранилось не 7 дней, как указано в ретешн периоде, а 14 дней. И это может быть важно. Бывают топики, я видел такие топики в продакшн, которые хранятся и по полгода, и по году. И сегменты у них могут быть большие, и, а, в них запись может быть редкая, то есть сегменты редко закрываются, потому что им поменяли настройки. Это может быть важно, например, для какой-нибудь политики персональных данных, что если пользователь к вам пришёл и запросил удаление своих данных, вы должны удалить отосю всех баз данных и скавки тоже. И вот помнить о том, что сообщения не удаляются сразу, а только через какое-то время, может быть полезно.
Единственный ли способ удалить данные в Кавка именно такой? Нет. Существуют и другие способы. А в Кавке есть такая политика, настройка клина полиси. Это настройка топика. По умолчанию она равна delete, и она вам уже знакома по этой лекции. Она удаляет данные потен. Но существует и другая настройка, называется compact. А она позволяет удалять все предыдущие сообщения с таким же ключом. Как видите, в кавке понятие ключа очень важно. Ну и обычно у сущности какой-то ключ есть. Что значит удаляет все предыдущие сообщения с таким же ключом? Ну вот давайте на примере. Есть какие-то сообщения по каждому ключу, и эти сообщения неожиданно хранятся вечно. Ну, по крайней мере, пока не придёт следующее сообщение с таким же ключом. Как только появляется новое сообщение, старое с таким же ключом удаляется. Это, на самом деле, супер полезный паттерн, чтобы хранить в кавке слепок данных какой-то таблички. Мы прямо часто использовали это в стриминговых платформах. Вы выгружаете какую-то табличку, например, из постгреса, справочник какой-нибудь, не знаю, с актуальными комиссиями, а выгружаете этот справочник кавку, и любая команда может прийти, выгрузить из кавки это к себе в табличку и подписаться на изменения, чтобы иметь у себя под ногами, в быстром доступе вот эти справочник комиссии. А в этом справочнике мы вечно храним последнее сообщение по ключу. То есть там есть какая-то комиссия, не знаю, с ID 1 2 3. Вот сейчас у неё такой-то рейд. Ну, то есть там, не знаю, настолько домножается какой какой-то тариф. И, э-э, сорри за банковские метафоры, человек проработал 5 лет в банках. Вот вся голова теперь в банковских метафорах. Вот, в общем, а она позволяет такие справочники хранить вечно, чтобы ничего не удалялось и в любой момент команды могли прийти и подписаться на данные и на их изменения. Такой топик, кстати, называется компактифицированный. А при этом вы можете довольно гибко это всё настраивать. По умолчанию вы можете включить компаct, но можно и выставить, например, компаct Delete, когда последнее сообщение по ключу хранится вечно, а предыдущее сообщение с тем же ключом удаляется сразу. Здесь на самом деле должно быть просто compпаct. Сорри, здесь немножко ошибка на слайде. Up mod compact - это вот первая строчка. Но можно и выставить compact запятая delete. Тогда последнее сообщение по ключу хранится всего неделю. То есть мы retтенtion период применяем. А ещё бывает настройка min comption lck milliseconds, как в третьей строчке. Тогда мы откладываем компактификацию на заданное значение. Можно, например, сказать: "Удаляй не сразу сообщение", а через какое-то время. В общем, довольно гибко можно с этими параметрами играть.
А можно ли удалить конкретное сообщение в Кавке? Такой, знаете, хитрый вопрос на собеседовании. Периодически я слышу о таком. Нет, нельзя конкретное сообщение удалить, только вот так через комплектификацию по предыдущему ключу. Вот так можно. А просто взять, выбрать любое сообщение, удалить так нельзя.
Фух. Наконец часто вопрос нас есть собеседование номер три. Когда использовать Кавка и когда очереди на примере Rabit MQ? Давайте разбираться. А на самом деле почти любую задачу можно решить и тем, и другим. Если вас спросят на systemдизаign интервью, типа, что вы здесь будете использовать топики, очередь, вам нужно будет довольно аккуратно отвечать, потому что это, на самом деле, зависит от задачи и просто зависит от того, сколько усилий вы потратите на прикручивание того или иного брокера брокера. А главное отличие, о котором стоит помнить - это то, что кавкатопики масштабируется горизонтально. То есть вы можете добавлять новые сервера, новые партицы и обрабатывать всё большую нагрузку. А, но мы сейчас разберём с вами разные задачи, и в одних быстрее можно будет разобраться с очередью, а в других с топик.
Итак, задача номер один. Роутинг сообщений. Что это значит? Роутинг - это распределение сообщений по читателям. Например, представьте себе ситуацию. Вам нужно, чтобы один ваш читатель получал событие а открытие карты, ну, просто открытие банковской карты в данном случае. А другой читатель должен покупать все, получать все те же события, но только случившееся в Москве. То есть у вас есть какая-то Москва специфичная логика, она должна определённым образом работать, а есть общая логика, которая работает для всех событий открытия карт. А в очередях довольно просто такое сделать. Вы можете просто указать паттерн, по которому хотите читать сообщение. Вот на экране пример из Rabit MQ, как можно такой паттерн указать. Но есть очень важный нюанс, о котором он часто забывает. Вам нужно, чтобы у сообщения был проставлен хедер, в котором, например, проставлен город отправки. Вот. То есть вам нужно заранее на писателе об этом подумать. Но если писатель об этом продумал за вас, то всё сработает, и вы быстро, буквально в одну настройку, получите такой фильтр. В топиках всё посложнее. Вам придётся писать отдельное приложение, куда-то его деплоить. Мы, кстати, в отдельной лекции поговорим, как такие приложения можно быстро писать с минимумом кода для стриминговой обработки. Сейчас не буду в это углубляться, но всё-таки придётся отдельное приложение написать.
А давайте разберём ещё одну задачу. Распределить задачи по Worker. Мне она прямо очень нравится, потому что она ярко подсвечивает недостатки кавки, когда вот кавки может быть кавка может быть честьчу. А наша цель распределить работу равномерно между разными воркерами. То есть вот у нас есть какая-то очередь с задачами, есть воркеры, которые эту задачу разгребают. И в Rabbit MQ - это легко. А Rabit MQ отдаёт сообщение по очереди. одному воркеру, другое другому. Как видите на картинке, у нас в зелёным подсвечено второе сообщение, надо станить второму, а первое и третье первому. Всё просто. А вот в Кавке всё не так однозначно. На первый взгляд, как вы видите на картинке, всё довольно легко. Ну что, у нас два воркера, а у нас тогда нужно создать две партиции, чтобы каждому воркеру осталось по партиции и сообщение равномерно по ним распределять. Всё просто же. А, кажется, что да, но когда вы начинаете с этим работать, возникают очень резкой. Например, вам нужно добавить ещё одного читателя. Ну, представьте, у вас нагрузка выросла, сообщений накопилось много, вы понимаете, что читатель не справляется, вы хотите добавить ещё одного. А нельзя. Нового читателя добавлять нельзя. Или а всё нормально, вы с нагрузкой справляетесь, но какое-то конкретное сообщение оказалось довольно плохим, но оно плохо обрабатывается. никак во workingкер не может его обработать. Это значит, что все сообщения после него в этой же партиции заблокированы, потому что мы помним, одну партицию может читать только один читатель одновременно. И, а вот мы уже заблокированы, не можем никак вычитать следующее сообщение. Они ждут своей очеди достаточно долго. А вкавка на самом деле придумывал решение этой проблемы, но оно пока доступно только в режиме prevw. Вот, буквально в этом, ладно, в прошлом году оно появилось, в этом году они его дорабатывали, но всё ещё это не продакш решение. А в Artemis MQ или в Rabbit MQ, я просто здесь разные брокеры привожу. А следующее сообщение, даже если какое-то одно заблокировалось, получит другие воркеры. То есть у нас вот воркер один как-то залочился, никак не может запроцесить первое сообщение, а второй воркер спокойно приходит, берёт второе, третье, обрабатывает. В общем, задача распределения равномерно сообщений между воркерами вам действительно может скорее лучше подойти в очередь.
Задача: обмен сообщениями между микросервисами. Тут прямо совсем неоднозначно. Особенностей нет, топики очереди одинаково удобны. А вы главное помните про то, что Кавка лучше держит нагрузку. Обычно на systemдизаign интервью, где вот такие вопросы типа Rabit MQ или Кавка задают, там у вас заранее известны нефункциональные требования. То есть какая будет нагрузка, сколько будет RPS, сколько будет запросов. А-а вот здесь, конечно, кавка подойдёт лучше, если нет каких-то ограничений дополнительных. А а если вы в целом не для system design это изучаете, а так для себя, то, конечно, всегда лучше провести нагручный тест своей системы и понять, держит ли ваш брокер вашу нагрузку или нет. То есть, если у вас компании уже принят Rabbit MQ и вы его часто используете и он держит ваши нагрузочные тесты, ну, и супер, значит, ritmq вам подходит. Аа, да и, собственно, разные паттерны нагрузки бывают. Бывает такое, что вот там, как я показывал в предыдущем кейсе, бит просто лучше справляется. Короче, обязательно тестируйте, проверяйте, а держит ли ваша архитектура, ваш брокер ту нагрузку и тот паттерн нагрузки, который у вас есть.
Идём дальше. Осталось буквально пара задач, на самом деле. сбор логов приложений, но тут, на самом деле, Кавка часто выигрывает, потому что она позволяет обрабатывать большие объёмы. Мы сейчас об этом поговорим. Для начала просто скажу, что, э, часто сбор логов осуществляет именно в брокер сообщений, а не напрямую в систему хранения, потому что вам всё тоже пресловутый контроль backкпрешера необходим. Вам нужно сделать так, что даже система хранения сложится, перегрузится, вы всё равно продолжили собирать логи, а не просыпали их. И в качестве буфера здесь часто выступает какой-то брокер сообщений. Существует множество фреймворков для сбора логов. А я на экране привёл только несколько тех, с которыми я когда-либо работал. И на самом деле большинство из них работают именно с кавкой и не работают с какими-нибудь брокерами. Как видите, например, Open Tillemet умеет с RIT MQ, но не умеет с артмисq. Это связано с тем, что обычно всё-таки логов, метрик очень много, и вот этот большой поток проще обрабатывает на горизонтально масштабируемой кафки, чем на Rabit MQ, которое масштабируем всё-таки ограничен.
Ещё одна задача, последняя, насколько я помню, поставка данных датаплатформ. тоже частый сценарий, когда используется именно кавка, потому что в кавке есть openсоourсное приложение, позволяющие прикрепить к ней самые разные приложения, например, разные базы данных типа Постгриса, Myсик V Оракла, короче, много разных, а, баз данных можно к ней подключить, а, и собирать все данные через это приложение, никакого кода писать прямо в кавку. А с другой стороны, обычно у Кавки есть ещё и способ выгрузить тоже с помощью точно такого жесорсного приложения данные скавки в какое-нибудь хранилище, там в тот же Hadub, в V3, Greгenplam, неважно. Короче, всё это Кавка Connect умеет. А, кстати, о том, как это делать, мы тоже отдельно поговорим на третьем занятии у меня про эффективное чтение из Кавки. Там про Cв Connect тоже будет. Вот. Так что в датаплатформах обычно выигрывает Кавка. Если у вас есть задача собрать данные со всей организации куда-нибудь, то часто это будет именно кавка плюс кавка Connect. Очереди тут не используются не только потому, что они хуже держат нагрузку, но и потому, что есть задача загрузить данные в кавку один раз, а потом вычитать их несколько раз для разных задач. Например, для долгой аналитики вы выгружаете их в Data Lake, а для какой-то быстрой аналитики, чтобы прямо сейчас обновлялись дашбордики, выгружаете в клиckхаус или делаете прямо стриминговую аналитику на потоке данных. Вот в случае такого несколько раз перечитывания данных очередь данные дублируют, поедают много ресурсов, а Кавка хранит данные один раз. Один раз записали, много раз вычитали под разные паттерны.
В итоге, когда использую топик, когда очередь, а всё очень зависит от задачи. Роутинг сообщений проще на очередях, но скавка тоже возможна. При этом на очередях есть ограничение, что вы завязываетесь на то, что писатель проставит правильный хендетер. А распидач по воркерам гораздо проще работать с hчедьми. Скавки тоже можно. Скавкой тоже можно, но там есть разные эджкейсы, особенно на большие нагрузки. А для обмена сообщений между микросервисами подходят и те, и другие. А, но обязательно проводите нагручноные тестирование, чтобы понять, а хватает ли вашего текущего брокера под ваш профиль нагрузки. А для задач сбора логов и всякой другой телеметрии чаще используют кавку, потому что фреймворки чаще работают с ней из-за её лучшей масштабируемости. А про поставку данных датаплатформу, а всё то же самое. Есть готовый фреймwork C connect. Он open sourceный и позволяет собрать данные с разных баз и загрузить в какое-нибудь хранилище. И всё это не написав ни одной строчки кода.
Отвечу на все вопросы в конце урока. Сейчас я чуть-чуть расскажу ещё про курс. А перед этим завтра всё то, что я не успею сегодня ответить, я отвечу завтра на Q&A с 19:00 до 20:00. Туда можно принести любые вопросы, а особенно про Кавку. Я с удовольствием расскажу про ваш кейс, расскажу что-то, а что можно делать с кавкой прикольнее, интересней, с большей нагрузкой. А, ну и в целом про распределённые системы тоже буду рад поговорить. Курс
Покавка для разработчиков, собственно, который я готовлю, открытый урок, который мы сегодня пронаблюдали. Давайте чуть-чуть про него поговорим.
А это глубокий курс, но он именно для разработчиков, то есть создан разработчиком для других разработчиков про паттерны, антипаттерны, грабли, подводные камни, хайлот, отказы, в общем, про всё вот это, как справиться с большой нагрузкой. А стартует он следующей осенью. Сейчас я его уже заканчиваю готовить. А тем, кто был, кстати, на этом уроке, скидка, а, 12.000 руб. Полная цена тоже сейчас будет, я её озвучу.
Кому подойдёт такой курс, пробный урок, которому вы сейчас увидели? Вы уже базово работали с кавкой, но столкнулись с тем, что что-то медленно читается, пишется, не понимаете, куда смотреть. Вот обо всём таком мы поговорим. Как оптимизировать, сделать эффективно, сделать быстро, сделать надёжно. Всё это будет. Вы уже понимаете, куда строить кавка и как говорить об этом на систм дизайн интервью. Но как именно это сделать, сколько партиции выбрать, какой объём данных хранить, сколько вообще ваш брокер выдержит, вы не знаете. На курсе про это поговорим. У вас есть проект, 1.000 сообщений. Вам нужно эти сообщения отгружать другой команды. А в будущем нагрузка планирует только расти. А мы об этом поговорим. Как нормально заключить контракт с другой командой? как это всё мониторить, как это всё писать, как гарантировать, что у вас не будет дублей, как гарантировать, что у вас не будет потерь. Обо всём этом обязательно поговорим на курсе.
Ну и последняя причина, почему курс может быть интересен. Вы хотите в биктех, хотите стать став-инженером, синер-инженером, лид инженером, в общем, занимать какие-то ведущие позиции инженерные. А обычно на таких позициях всё-таки нужна кавка. Кавка - это, ну, необходимый компонент расплённой архитектуры. Чаще всего на больших проектах он есть, и чаще всего всё-таки про него спрашивают на собеседованиях, особенно систмдизайн или на архитектурных секциях. Вот про это тоже мы довольно глубоко про то, как Кавка встроится в entтерпрайз архитектуру, поговорим.
А что нужно знать, чтобы участвовать в курсе? По-хорошему, вам нужен любой бэкэнд язык. У нас никаких язык специфичных вещей не будет. А можно Java, GIP+, шарпы, Typescript, что угодно. А единственное нужно, чтобы вы умели работать с докером, потому что те примеры работы с кавкой, которые вам может захотеться воспроизвести дома, я буду делать именно на докер. Ну и базовый компьютер science вам тоже поможет, если вы понимаете, что такое каптеоремы, это хорошо, но если не понимаете, ничего страшного, я вам расскажу, дам ссылки, э, ну, в ответах на уроки расскажу, дам ссылки, подскажу, что почитать в целом, расскажу, как это работает. Вот в целом про архитектуру распределённых систем мы тоже будем касаться. И там прямо глубоко знать не обязательно.
Программа. О чём вообще в курсе будет? Ну, первый урок будет очень похож на то, что вы видели сегодня. Наверное, побольше деталей просто туда насыплю. В целом, что такое кавка, как она работает, чем отличается от RBIT MQ, для решения каких задач корато появилось, про основные термины, офсет, сегмент, компактификация, вот эти все вещи. А отличие кавка отбит MQ, ну, и разбор ещё дополнительных задач собеседования, которые сегодня не потрогали. А на практике мы поднимем свою кавку и попробуем через консоль в неё что-то записать, прочитать, чтобы вы дома могли это воспроизвести.
А второй урок будет посвящён целиком а записи в Кавку. А как писать с низкими letсси, как писать с большим strpпу. Это значит, как писать очень быстро и очень много. Это не всегда одно и то же. Обычно очень много пишут медленней, но а важно понимать, как оптимизировать кавку и свою запись и под тот, и под другой сценарий. А главное, как это померить, как провести нагрузочные тесты легко и быстро, а чтобы понять, насколько ваша Кавка вывозит. А второй способ эффективно писать в Кавка - это ничего не терять. Расскажу про разные гарантии, про то, как добиться listes, про то, как добиться exactly и в целом, можно ли добиться exactly и на какие компромиссы придётся пойти, чтобы exactly ones получить. То есть exactly Once - это запись без дубля и без потерь. Ну, и последний способ эффективно работать с кавка на записи - это писать мало кода. Мы разберём с вами здесь кавка connect CDC. Помню в чате как раз был вопрос про Transactional Outbox. Обязательно про него поговорим, про грабли, которые возникают при отказах со всем этим CDC Bзиумом, какие там проблемы с форматами могут быть. В общем, про всё про это поговорим. Если вам нужно когда-нибудь быстро загрузить данные из базы в Кавку, вот кавка Connect + CDC + DBIUM вам идеально подойдут, но есть нюанс. О них мы здесь и поговорим. Ну, и собственно, в качестве практики мы настроим забор данных, использоваться в кавку с помощью CDC.
Третий урок будет посвящён чтению, как я уже рассказывал, как раз тот самый шторм ребалансов, когда вместо того, чтобы читать, консюмеры просто занимаются тем, что пытаются договориться между собой, кто какие партиции будет читать. А, поговорим про CQRS. Суперчастый паттерн, особенно с использованием кавки. А, покажу, как его применять вместе с Кавкаконнектом, как вам быстро взять данные определённые и разложить их подходящую ритнагрузку. Поговорим в этом же уроке про схематизацию данных. Зачем это делают, почему в большинстве крупных компаний смаре registстри есть и схематизация существует, ну, и как это применять с кавкой? Почему это вам, как бы, кендеру может быть полезно. Ну, и наконец, немножко tipпs and tricks. Что такое DQ? Deadletter Q. Очередь недостальных сообщений. Как быстро сбрасывать, как сделать отхок, чтение данных легко и непринуждённо. Про всё про это поговорим. А в качестве практики добавим с вами схематизацию, увидим, что это не сложно, что она не кусается, а, и научимся выгружать данные из кавки какое-нибудь другое хранилище для того, чтобы попробовать руками патрон QRS.
На этом этапе вы уже сможете работать с кавкой на небольшом масштабе в плане того, что вы умеете в неё быстро писать, вы умеете из неё быстро читать, но пока непонятно, что делать с отказами, что делать, когда в корпорации десятки команд, когда нужно защищать данные, а когда у вас ресурсы кластера заканчиваются. Этому посвящён посвящено следующее занятие, собственно, а что происходит в момент отказа? То, что вот сегодня спрашивали, что произойдёт, если брокер кавку упал. Что произойдёт при замене диска плановый? Да, у вас заканчивается место на кавке, вы хотите поставить диск побольше. Что произойдёт? А как минимизировать влияние таких отказов? А вообще какое влияние есть? Как сделать так, чтобы оно было небольшим, там измерялось сотнями миллисекунд, а не секундами? Про это про всё поговорим. Как выбирать количество партиций, как выбирать retтенtion период, как вообще прикинуть, хватит вам места или нет. И вы здесь можете подумать, что это скорее за вопросы devopса про количество партий и период. На самом деле нет. Ввопсы вам не скажут, какая у вас будет нагрузка на ваше приложение. Они не скажут, сколько сообщений в секунду вы будете генерить. А обычно такая ответственность про то, чтобы просчитать капаacity кавка кластера, она всё равно ложится на разработчика, потому что именно они понимают бизнес, сколько будет нагрузка. А я помогу переложить эту нагрузку в расчёт того, когда вам нужно будет брокеры расширять. А сколько в целом может выдержать нагрузки один кавка, кластер кавка из трёх нот? Тоже про это поговорю, чтобы вы понимали. Пора вам задумываться о расширении, не пора. А может быть, вам ещё там на десятки лет вперёд хватит вашего небольшого кавка-кластера. Ну, и ещё в этом же занятии мы поговорим про безопасность, то, что как раз спрашивали в чате, как модифицироваться, как раздавать роли, авторизоваться, а как защититься от шумных соседей, то есть от приложений, которые придут, не знаю, какие-нибуд сбойные и задосят ваш кластер до смерти. Вот как от такого защититься? А, и отдельно поговорю про федерацию скавка кластров. А это такая штука, которая нужна для очень высокой надёжности, когда вот вам вообще ни в коем случае нельзя терять данные и прерывать обслуживание, тогда часто принимают, применяют федерацию. Об этом тоже коротко поговорим. Ну, а в качестве практики добавим в Кавку аутификацию и добавим UI к нашей кавке тоже с аутификацией.
Часто бывает такое, что даже если мы умеем с с данными скавкой хорошо работать, быстро из неё читать, переживать отказы, данные нам просто не подходят и хочется с этим что-то делать, а писать кучу кода не хочется. Для этого существуют паттерны стриминговой обработки. Существует, а, так называемый комплекс event. А это такой паттерн, который позволяет обрабатывать события. А я расскажу, как он работает, когда его применять и что вообще в нём есть. как какие быстрые операции там можно делать и расскажу про основные фреймворки для комплекса Processing, которые существуют Flink, КавкастAMS, паch SPK. А мы не будем каждый из них пробовать, просто я расскажу про преимущество каждого из них, как между ними выбрать, э что на них можно быстро решить. Ну, и отдельно бонусом поговорим про евристику. Бывает такое, что вам нужно очень большие объёмы очень быстро анализировать, а, например, вам нужно считать на большом потоке количество вхождения определённого сообщения. А, и вот точно их считать не получается. Вы готовы пожертвовать точностью ради скорости. В этом случае работают эвристические алгоритмы. Мы о них тоже небольшую часть урока поговорим, какие они бывают, а как их можно применять. Ну, и на паchфлин в качестве практики напишем небольшое приложение.
Ну и последнее занятие, оно будет про будущее, про то, что а кавка будет делать дальше. А вам, чтобы не отставать от Мирати, полезно будет знать про то, что появляется, то, что будет применяться, а уже там в следующем году через год, а при использовании кавки, а в том числе для ускорения AI. Сейчас посмотрим, про что здесь будет. А мы поговорим про то, а как сейчас уже можно работать с Кавкой, как ещё год назад было, нельзя. А, собственно, вопрос про то, что в Rabit MQ появляется кавка очереди, тоже поговорим, может ли Кавка заменить Rabit MQ, потому что в Кавке тоже появляются свои очереди. Как хранить огромные объёмы данных Кавке и зачем главное это делать, тоже поговорим. Ну, и немножко про имейли Кавку, про то, как её сейчас используют, для того чтобы вашим MCP-серверам доставались э свежие данные, которые обновляются в реальном времени. Как это всё интегрировать, тоже отдельно поговорим.
В итоге, когда пройдём этот полуторамесячный курс, а вы освоите кавку на продвинутом уровне и систематизируете свои знания. Поймёте, как кавка работает внутри, но главное, как все эти устройства вам могут помочь на практике вам, как бэкэнд-разработчика. А тонкости, подводные камни, лучшие практики, паттерны, грабли, всё, что у меня за последние 7 лет работы с кавкой сложилось и помощи другим людям в работе скавки, я вам расскажу и поделюсь. А вам не нужно ничего читать дополнительно, потому что я уже все эти книжки про Кавку прочитал и вам перескажу, а если спросите, расскажу вам, какие мне понравились больше всего, если вы тоже захотите их прочитать. Ну, а вы научитесь работать, точнее, готовить дизайн сложных систем, опирающихся на кавку. То есть обычно это какие-то распределённые системы suvential consistency. А я покажу на своих занятиях, как кавку можно в разных сценариях здесь применять. А всё это будет на примере ПТ-проекта небольшого. На следующем слайде его, а, картинка, в центре которого, конечно, кавка. Научимся в этот петпроект писать, читать, использовать. схематизацию данных, использовать cкоnнект для загрузки и выгрузки данных из него, использовать стрим processing. Ну, и отдельно немножко поговорим про аа хранение дан, выгрузку данных и скавки для аналитики iberg.
Как будет проходить обучение. А это онлайн-уроки, уроки в Zoom, а будут длиться по полтора часа примерно. Ну вот на самом деле как сегодня, то есть где-то час занятий, ещё полчаса вопроса. А свободное от работы время. Вот на слайде видите вопросы, которые задавали мне ко всяким видео на Ютубе, и мы их тоже, а, будем разбирать. А домашние задания, они будут в виде того, чтобы поднять что-то в кавке и попробовать что-то поделать, а сможете отточить на примере реальных кейсов, которые, ну, мне кажется, должны пригодиться вам в работе. По крайней мере, мне в работе они пригождались. А Q&A сессии, как я уже сказал, они будут происходить для того, чтобы обсуждать ваши вопросы по кавке и домашние задания. Общий чат, в котором можно будет обсудить ваши сценарии кавки с кавкой проблемы. Я смогу вам там помочь, а, ответить на ваши вопросы, ну, и в целом просто оставаться на связи. А учимся мы на своей отдельной платформе. Это портфо Ballon Corses. Ээ, там уже сейчас есть несколько занятий, а мы получаем довольно высокие рейтинги удовлетворённости. Конкретно этот курс, который мы сейчас запускаем, он ещё не имеет никаких оценок, потому что он пока не запущен, но другие курсы, которые запустились на этой платформе, имеют высокий рейтинг. Он 86% рекомендует. А, ну, и ещё у нас есть отдельная страничка на Яндекс-картах, которых, ну, насколько я знаю, нельзя поделать отзывы. Вот там ребята заходят и пишут, что им тоже всё понравилось. У нас только 5:0 оценки. Вот. Ну, и на предыдущем слайде тоже видите, что все ставят высокое количество звёздочек. То есть мы ответственно и с высоким качеством подходим к подготовке нашего контента.
Стоимость, а, доступ на 1 год или на 2 года. Разница только в этом, насколько вам нужен доступ. И там, и там будет шесть онлайнзанятий, о которых я поговорил чуть раньше. А будут домашние задания, Q&A сессии, чаты, дополнительный материал. Разница только в том, насколько вы получаете доступ к этим материалам. Сейчас, да, стоимость вы видите на экране, 45.000 и 50.000. Соответственно, сейчас скидка для тех, кто а пришёл на это занятие, 12.000 руб. Она действует в течение 2 24 часов.
Немножко о том, кто уже у нас учится. На экране вы видите компании. Возможно, вы среди этих компаний узнаёте своего работодателя. А у нас можно учиться за счёт вот этих компаний. Они с нами сотрудничают и оплачивают обучение. Но на самом деле не только за счёт них. Если вашей компании здесь нет, можно вполне спросить у своего работодателя: "А не могли бы вы оплатить мне, пожалуйста, курс?" А, как видите, большинство компаний идут навстречу и согласуют, оплачивают курсы на нашей платформе.
Если у вас будут вопросы, пожалуйста, заполните форму обратной связи. Она есть на сайте. Насколько я помню, мне коллеги подсказывали, что форма обратной связи будет и в чатике тоже. Для меня это суперважно понять, было ли вам ценно то, что я вам сегодня рассказывал, не было ли бы слишком просто, не было ли слишком сложно, не было ли слишком быстро. Пожалуйста, пишите. Это поможет мне в следующий раз делать занятие ещё лучше. Я каждый ответ читаю. Мне прямо правда это помогает. Аа, да, Telegram тоже есть виджет быстрой связи, который ведёт в Telegram. А завтра, ещё раз напоминаю, есть Q&A сессия с 19:00 до 20:00 для того, чтобы ответить на те вопросы, на которые я не отвечу сегодня или подробно что-то разобрать. А созон будет закрытым, без записи, а можно будет даже рабочий ваш вопрос задать. А тем, кто придёт на Q&A сессию, мы дадим ещё одну дополнительную скидку, дополнительную той, что давали уже сегодня, чтобы можно было ещё дешевле купить курс. Так, ещё больше знаний, применимых на практике на Ютубе, Telegram-канале и ВКонтакте B Corses.