Погнали в Авито работать?
Я тут регулярно вкидываю, что мне работа ща по кайфу идёт и тут у вас варик возник попробовать побыстрому залететь в Авито. Если всё выгорит, то будете обмазываться кайфовыми процессами и общаться с интересными людьми.
13 и 14 апреля намечается Weekend Offer для Go-разработчиков.
Флоу такой:
* Подаёте заявку до 11 апреля
* Решаете тест до 12 апреля
* Проходите телефонное интервью до 12 апреля
* Проходите собеседования онлайн
* Получаете оффер
* Кайфуете!
Регаться и узнать детали можно тут -> Weekend Offer от Avito
P.S. Если есть вопросы пишите)
Я тут регулярно вкидываю, что мне работа ща по кайфу идёт и тут у вас варик возник попробовать побыстрому залететь в Авито. Если всё выгорит, то будете обмазываться кайфовыми процессами и общаться с интересными людьми.
13 и 14 апреля намечается Weekend Offer для Go-разработчиков.
Флоу такой:
* Подаёте заявку до 11 апреля
* Решаете тест до 12 апреля
* Проходите телефонное интервью до 12 апреля
* Проходите собеседования онлайн
* Получаете оффер
* Кайфуете!
Регаться и узнать детали можно тут -> Weekend Offer от Avito
P.S. Если есть вопросы пишите)
🔥9🐳4👍2
Forwarded from 📍Олег Козырев - IT и жизнь ️
КАК УСТРОЕН ПЛАНИРОВЩИК В GOLANG?
На гошных собесах часто спрашивают вопросы про горутины, планировщик и прочие прелести из runtime. Вопросы эти частенько душные и ты небось и сам когда-то сыпался на них. Этот ролик поможет тебе закрепить базу про планировщик в гошке и накинет немного кринжа, чтобы было не так грустно. И смотрите ролик до конца, чтоб ютуб мне потом ночью не звонил и не предъявлял: "а чего это трафик то просел, опять прод уронил?"😂
P.S. У Коли Тузова скоро тоже ролик на эту тему будет, так что сейчас чашечку кринжа наберем, зачилим, а как Коля ролик выложит ещё глубже в тему нырнём интереса ради.
https://youtu.be/z9xXThOOMWc
На гошных собесах часто спрашивают вопросы про горутины, планировщик и прочие прелести из runtime. Вопросы эти частенько душные и ты небось и сам когда-то сыпался на них. Этот ролик поможет тебе закрепить базу про планировщик в гошке и накинет немного кринжа, чтобы было не так грустно. И смотрите ролик до конца, чтоб ютуб мне потом ночью не звонил и не предъявлял: "а чего это трафик то просел, опять прод уронил?"😂
P.S. У Коли Тузова скоро тоже ролик на эту тему будет, так что сейчас чашечку кринжа наберем, зачилим, а как Коля ролик выложит ещё глубже в тему нырнём интереса ради.
https://youtu.be/z9xXThOOMWc
👍14🔥7
ГДЕ МОИ ДЕНЬГИ, POSTGRES?
Слушайте, вот вам казус из жизни. Хотел я тут заплатить за аренду квартиры. Переважу лавеху арендодателю, Михал Степанычу. Вроде всё просто, но есть нюанс. Давайте обкашляем вопросики с точки зрения базы данных.
Напомню, что в мире баз данных транзакция — это не просто перевод денег, это целая цепочка операций, которая может включать в себя несколько шагов. Если всё идёт гладко, транзакция завершается операцией комит, и ваши изменения остаются в системе навсегда. А если что-то идёт не так? Тогда надо откатываться операцией ролбек.
Так вот, есть такой уровень изоляции транзакций как READ COMMITTED. Он часто юзается многими бдшками по умолчанию. Под этим уровнем, данные, которые вы читаете в рамках транзакции, уже должны быть закомичены. Иными словами, вы НЕ увидите изменений, пока они официально не войдут в базу данных, через операцию коммит.
Вернёмся к оплате за хату. Пока я переводил кровно заработанные деньги Степанычу, он уже начал их тратить. Я хз, может он шопоголик или что похуже, но прекол вот в чём. Когда он собрался сливать бабки, он уже расчитывал на то, что деньги от меня до него долетели, но транзакция чё-то подвисла и ещё не успела закоммититься. По итогу, купить он ничего не смог, так как его транзакция видела лишь старый баланс, где был шишь без масла ахах и это хорошо, потому что предотвращает ряд возможных проблем, типа тех, что случились с Машей из предыдущей истории. Степаныч в кой века в долги не залезат благодаря рид комитеду)))
Этот уровень изоляции защищает от так называемых "грязных чтений", когда данные видны до их окончательного подтверждения. Это как получить чек на оплату, который ещё не прошёл по банковской системе. Вроде быстро и удобно, но может там всё откатится к чертям и чек твой ничего не значит и надо новый печатать.
А как вы платите за аренду хаты налом или мутите мутки со своим Степаныче по сети? ахаха
P.S. Шлем надел для безопасности, а то говорят же, что надо заботится о безопасности при разработке!)
Слушайте, вот вам казус из жизни. Хотел я тут заплатить за аренду квартиры. Переважу лавеху арендодателю, Михал Степанычу. Вроде всё просто, но есть нюанс. Давайте обкашляем вопросики с точки зрения базы данных.
Напомню, что в мире баз данных транзакция — это не просто перевод денег, это целая цепочка операций, которая может включать в себя несколько шагов. Если всё идёт гладко, транзакция завершается операцией комит, и ваши изменения остаются в системе навсегда. А если что-то идёт не так? Тогда надо откатываться операцией ролбек.
Так вот, есть такой уровень изоляции транзакций как READ COMMITTED. Он часто юзается многими бдшками по умолчанию. Под этим уровнем, данные, которые вы читаете в рамках транзакции, уже должны быть закомичены. Иными словами, вы НЕ увидите изменений, пока они официально не войдут в базу данных, через операцию коммит.
Вернёмся к оплате за хату. Пока я переводил кровно заработанные деньги Степанычу, он уже начал их тратить. Я хз, может он шопоголик или что похуже, но прекол вот в чём. Когда он собрался сливать бабки, он уже расчитывал на то, что деньги от меня до него долетели, но транзакция чё-то подвисла и ещё не успела закоммититься. По итогу, купить он ничего не смог, так как его транзакция видела лишь старый баланс, где был шишь без масла ахах и это хорошо, потому что предотвращает ряд возможных проблем, типа тех, что случились с Машей из предыдущей истории. Степаныч в кой века в долги не залезат благодаря рид комитеду)))
Этот уровень изоляции защищает от так называемых "грязных чтений", когда данные видны до их окончательного подтверждения. Это как получить чек на оплату, который ещё не прошёл по банковской системе. Вроде быстро и удобно, но может там всё откатится к чертям и чек твой ничего не значит и надо новый печатать.
А как вы платите за аренду хаты налом или мутите мутки со своим Степаныче по сети? ахаха
P.S. Шлем надел для безопасности, а то говорят же, что надо заботится о безопасности при разработке!)
🔥11👍7😁2🤪1
ГДЕ МОЙ СТОЛИК, REPEATABLE READ?
Вы же знаете секрет успеха с девушкой? Её надо накормить, а то будет злая и ты резко из нормального парня рискуешь стать бесячим объектом ахахах Стало быть надо бронирования столика в каком-нить заведении. И всё кажется довольно обыденно, пара кликов и столик твой, ноооооо есть нюанс😂
Твою бронь ж надо положить в базу, а то забуд все про тебя. А в базах опять эти транзакции. Надо ж как-то обесопасить рестик от ситуации, когда один и тот же стол бронят несколько человек. А то приходишь на ужин, а там вместо любимой девушки, питонист сидит😨
У транзакции обычно есть два стула или всё приходит идеально, или ничего не выходит. Если всё идёт по плану, транзакция фиксируется операцией коммит, и изменения становятся постоянными. Если что-то идёт не так — в игру вступает ролбек, и всё возвращается на свои места.
На уровне изоляции REPEATABLE READ каждый раз, когда вы запрашиваете данные в рамках одной транзакции, они остаются неизменными, независимо от того, что происходит снаружи этой транзакции.
Хотел я как-то забронировать столик в модном заведении. Открыл приложение, выбрал столик у окна, который был свободен, и перешёл к бронированию. А по сторонам гляжу, стоит рядом зумерок и бронит тот же столик, паразит. Я уж право дело думал система то тупанёт и едовать еду буду с ним. Но нет!
Благодаря уровню изоляции REPEATABLE READ, моя сессия "запомнила" информацию о том, что столик был свободен в момент начала моей транзакции. И пока я завершал бронирование, для меня столик оставался доступным, несмотря на попытки других клиентов его занять. Я успешно завершил бронь, и когда я закончил, система уже показывала следующим клиентам, что столик занят.
Этот уровень изоляции защищает от "неповторяемого чтения", когда данные изменяются другими операциями в базе данных во время вашей транзакции. Таким образом, вы получаете стабильный и предсказуемый результат.
Однако у уровня изоляции REPEATABLE READ и проблем хватает:
Проблема блокировок и долгое выполнение транзакций
REPEATABLE READ удерживает же блокировку на прочитанные данные до конца транзакции, стало быть все остальные запросы, кто хочет эти данные почитать тупо заблочены и ждут. А значит и время ответа в таких запросах будет расти, что конечно печально.
Потенциальные deadlock'и
Ну это классика, когда логики наворатили кучу и получилось, что первая транзакция заблочила вторую, а вторая первую и всё, шах и мат постгресмены ахахах Хлопот новых прибавится в миг.
Увеличение сложности управления
Про дополнительные хлопоты я уже говорил. С таким уровнем изоляции надо заранее подумать о подводных камнях и всяких внештатных ситуациях. Ну и на проде потом сидеть и ловить какие-нить приколы типо дедлоков.
Тем не менее, несмотря на эти сложности, уровень изоляции REPEATABLE READ помог миллениалам вновь победить зумеров и забронить столик ахахаха
Юзаете этот уровень изоляции или рид комитедов обходитесь?
P.S. Судя по фотке выше я таки ничего не забронил)))
Вы же знаете секрет успеха с девушкой? Её надо накормить, а то будет злая и ты резко из нормального парня рискуешь стать бесячим объектом ахахах Стало быть надо бронирования столика в каком-нить заведении. И всё кажется довольно обыденно, пара кликов и столик твой, ноооооо есть нюанс😂
Твою бронь ж надо положить в базу, а то забуд все про тебя. А в базах опять эти транзакции. Надо ж как-то обесопасить рестик от ситуации, когда один и тот же стол бронят несколько человек. А то приходишь на ужин, а там вместо любимой девушки, питонист сидит😨
У транзакции обычно есть два стула или всё приходит идеально, или ничего не выходит. Если всё идёт по плану, транзакция фиксируется операцией коммит, и изменения становятся постоянными. Если что-то идёт не так — в игру вступает ролбек, и всё возвращается на свои места.
На уровне изоляции REPEATABLE READ каждый раз, когда вы запрашиваете данные в рамках одной транзакции, они остаются неизменными, независимо от того, что происходит снаружи этой транзакции.
Хотел я как-то забронировать столик в модном заведении. Открыл приложение, выбрал столик у окна, который был свободен, и перешёл к бронированию. А по сторонам гляжу, стоит рядом зумерок и бронит тот же столик, паразит. Я уж право дело думал система то тупанёт и едовать еду буду с ним. Но нет!
Благодаря уровню изоляции REPEATABLE READ, моя сессия "запомнила" информацию о том, что столик был свободен в момент начала моей транзакции. И пока я завершал бронирование, для меня столик оставался доступным, несмотря на попытки других клиентов его занять. Я успешно завершил бронь, и когда я закончил, система уже показывала следующим клиентам, что столик занят.
Этот уровень изоляции защищает от "неповторяемого чтения", когда данные изменяются другими операциями в базе данных во время вашей транзакции. Таким образом, вы получаете стабильный и предсказуемый результат.
Однако у уровня изоляции REPEATABLE READ и проблем хватает:
Проблема блокировок и долгое выполнение транзакций
REPEATABLE READ удерживает же блокировку на прочитанные данные до конца транзакции, стало быть все остальные запросы, кто хочет эти данные почитать тупо заблочены и ждут. А значит и время ответа в таких запросах будет расти, что конечно печально.
Потенциальные deadlock'и
Ну это классика, когда логики наворатили кучу и получилось, что первая транзакция заблочила вторую, а вторая первую и всё, шах и мат постгресмены ахахах Хлопот новых прибавится в миг.
Увеличение сложности управления
Про дополнительные хлопоты я уже говорил. С таким уровнем изоляции надо заранее подумать о подводных камнях и всяких внештатных ситуациях. Ну и на проде потом сидеть и ловить какие-нить приколы типо дедлоков.
Тем не менее, несмотря на эти сложности, уровень изоляции REPEATABLE READ помог миллениалам вновь победить зумеров и забронить столик ахахаха
Юзаете этот уровень изоляции или рид комитедов обходитесь?
P.S. Судя по фотке выше я таки ничего не забронил)))
🔥11👍3
Го стримчик в этом канале в воскресенье вечерком?:) Расскажу вам всякого интересного не только про айти, да на вопросы поотвечаю)
Anonymous Poll
69%
Го
20%
Стрим стримом, но Когда курс?
11%
Я занят
Что почитать по gRPC?
Меня тут порой спрашивают про gRPC, мол чего такого интересно про него можно почитать. Сейчас накину вам немного материальчика по теме. Что-то будет базой, что-то материалом поглубже)
Такой ответ мне как-то дал знакомый из платформенной команды Озона))) В целом база, но иногда хочется человеческого чтива ахаха
1) Из того, что на русском на ум приходит книга с уткой. В ней дана база, которая в водит в мир межпроцессного взаимодействия. Из прикольного там рассказывается как именно protobuf сериализует данные.
2) Есть книженция на английском, которая ещё и тему тестирования и деплоя покрывает. В целом даже те, кто в английском не силен поймут половину и так, а вторую переведут в браузере.
3) Ясно дела самая база у меня в видосе есть. Я там на примере гошки показываю шаг за шагом, как намутить простецкий gRPC сервачек и клиент к нему. Ссылка на репу в описании есть.
4) А если кому-то хочется материальчик поглубже, то в игру вступает мой знакомый из Озона. Доклад о плагинах в protobuf. Свят рассказал, как начать мутить свои плагины и нафига это нужно. Доклад самое оно, чтоб преисполниться кодогенерацией.
5) И ещё один доклад от кайфового паренька из Озон. На сей раз Свят рассказал о том, как устроена кодогенерация в Озоне. Мы ж с вами, кто юзал gRPC, привыкли ко всяким protoc или buf, а в Озоне свою тулзу напилили. Свят рассказал зачем они это сделали и как.
Меня тут порой спрашивают про gRPC, мол чего такого интересно про него можно почитать. Сейчас накину вам немного материальчика по теме. Что-то будет базой, что-то материалом поглубже)
Читай исходники
Такой ответ мне как-то дал знакомый из платформенной команды Озона))) В целом база, но иногда хочется человеческого чтива ахаха
1) Из того, что на русском на ум приходит книга с уткой. В ней дана база, которая в водит в мир межпроцессного взаимодействия. Из прикольного там рассказывается как именно protobuf сериализует данные.
2) Есть книженция на английском, которая ещё и тему тестирования и деплоя покрывает. В целом даже те, кто в английском не силен поймут половину и так, а вторую переведут в браузере.
3) Ясно дела самая база у меня в видосе есть. Я там на примере гошки показываю шаг за шагом, как намутить простецкий gRPC сервачек и клиент к нему. Ссылка на репу в описании есть.
4) А если кому-то хочется материальчик поглубже, то в игру вступает мой знакомый из Озона. Доклад о плагинах в protobuf. Свят рассказал, как начать мутить свои плагины и нафига это нужно. Доклад самое оно, чтоб преисполниться кодогенерацией.
5) И ещё один доклад от кайфового паренька из Озон. На сей раз Свят рассказал о том, как устроена кодогенерация в Озоне. Мы ж с вами, кто юзал gRPC, привыкли ко всяким protoc или buf, а в Озоне свою тулзу напилили. Свят рассказал зачем они это сделали и как.
🔥10👍6👨💻2
Вчера на стриме просили поделится статистикой прошедшего потока. Делюсь)
Отдельно обращу внимение на один момент, который сам не так давно осознал) Раньше почему-то казалось, что те, кто не дошел до конца ничего полезного с курса и не получили. Но по факту то это не так, половину курса прошел, половину пользы получил и кому-то это норм) И сразу после этого осознания как-то легче на душе стало ахахах
Там, например, есть чувак, который чуть больше половины домашек сдал, а сам уже гляжу в Авито залетел) Ну а так, кажется картина доходимости плюс минус по рынку) 20% дошли до конца
И тут должен быть пафосный вывод "А в какой группе окажешься ты? Тех, кто дошел или тех, кто сдался?"😂😂😂 Кринж конечно, когда такое на серьезных щах пишут)
Отдельно обращу внимение на один момент, который сам не так давно осознал) Раньше почему-то казалось, что те, кто не дошел до конца ничего полезного с курса и не получили. Но по факту то это не так, половину курса прошел, половину пользы получил и кому-то это норм) И сразу после этого осознания как-то легче на душе стало ахахах
Там, например, есть чувак, который чуть больше половины домашек сдал, а сам уже гляжу в Авито залетел) Ну а так, кажется картина доходимости плюс минус по рынку) 20% дошли до конца
И тут должен быть пафосный вывод "А в какой группе окажешься ты? Тех, кто дошел или тех, кто сдался?"😂😂😂 Кринж конечно, когда такое на серьезных щах пишут)
🏆7👍4🎉1
Паттерны проектирования микросервисов: Как построить устойчивую систему
Здарова, бандиты! 👋 Сегодня хочу накинуть вам про паттерны проектирования микросервисов.
Когда я впервые окунулся в мир микросервисов, я подумал "какой же я тупой?!". Миновало три года и я уже точно могу сказать "какой именно я тупой"ахаха Все эти мутки с микросервисами напоминают то, как я в детстве с бабушкой пазлы собирал на 1000 штук. Сначала вообще не понятно, что к чему. Но потом на помощь приходят мама с папой и дело уже идёт хорошо. Вот такими мамой с папой для микросервисов и есть эти паттерны, про которые было в заголовке. Такие себе проверенные временем рецепты для типичных проблем.
Начнем что-ли с API Gateway. Представьте, у вас куча микросервисов, каждый со своим эндпоинтом. Без API Gateway пользователи бы сходили с ума, пытаясь добраться до каждого сервиса, ну или фронтендеры бы разбрызгали свой раф в попытках найти нужный адрес. API Gateway – это как консьерж в отеле, который управляет всеми запросами, обеспечивает безопасность и даже может кешировать ответы, чтобы всё работало быстрее.
Следующий важный паттерн – Service Discovery. В мире микросервисов сервисы появляются и исчезают, как грибы после дождя. Service Discovery помогает им находить друг друга автоматически. Это как на вечеринке, где каждый гость постоянно меняет место, а хост всегда знает, кто где сидит. Короч, чтоб не завязываться на конкретный IP мы просто юзаем сервис дискавери, а тот сам всё разыщет кого надо)
И, конечно, Circuit Breaker. Этот паттерн спасает, когда один из микросервисов начинает тупить. Circuit Breaker – это как предохранитель в электропроводке: если где-то сбой, он не даёт всей системе рухнуть. Он просто начинается дропать запросы, пока сервис не раздуплится и не будет готов к дальнейшей работе.
Эти паттерны только верхушка айсберга. Их гораздо больше, и каждый решает свою конкретную задачу.
А вы такие или подобные паттерны юзаете или всегда велосипедите в своих сервисах?
Накидывайте клубничек, если хотите прочесть про другие паттерны)
Здарова, бандиты! 👋 Сегодня хочу накинуть вам про паттерны проектирования микросервисов.
Когда я впервые окунулся в мир микросервисов, я подумал "какой же я тупой?!". Миновало три года и я уже точно могу сказать "какой именно я тупой"ахаха Все эти мутки с микросервисами напоминают то, как я в детстве с бабушкой пазлы собирал на 1000 штук. Сначала вообще не понятно, что к чему. Но потом на помощь приходят мама с папой и дело уже идёт хорошо. Вот такими мамой с папой для микросервисов и есть эти паттерны, про которые было в заголовке. Такие себе проверенные временем рецепты для типичных проблем.
Начнем что-ли с API Gateway. Представьте, у вас куча микросервисов, каждый со своим эндпоинтом. Без API Gateway пользователи бы сходили с ума, пытаясь добраться до каждого сервиса, ну или фронтендеры бы разбрызгали свой раф в попытках найти нужный адрес. API Gateway – это как консьерж в отеле, который управляет всеми запросами, обеспечивает безопасность и даже может кешировать ответы, чтобы всё работало быстрее.
Следующий важный паттерн – Service Discovery. В мире микросервисов сервисы появляются и исчезают, как грибы после дождя. Service Discovery помогает им находить друг друга автоматически. Это как на вечеринке, где каждый гость постоянно меняет место, а хост всегда знает, кто где сидит. Короч, чтоб не завязываться на конкретный IP мы просто юзаем сервис дискавери, а тот сам всё разыщет кого надо)
И, конечно, Circuit Breaker. Этот паттерн спасает, когда один из микросервисов начинает тупить. Circuit Breaker – это как предохранитель в электропроводке: если где-то сбой, он не даёт всей системе рухнуть. Он просто начинается дропать запросы, пока сервис не раздуплится и не будет готов к дальнейшей работе.
Эти паттерны только верхушка айсберга. Их гораздо больше, и каждый решает свою конкретную задачу.
А вы такие или подобные паттерны юзаете или всегда велосипедите в своих сервисах?
Накидывайте клубничек, если хотите прочесть про другие паттерны)
🍓53🔥4🤡2👍1😱1🤬1🤮1💩1
Сгонял к ребятам из Cloud.ru на подкаст:) Поговори про много что) И про гошку, и про микросервисы, и про курс и даже про проблемы женщин:)
Forwarded from Cloud.ru
This media is not supported in your browser
VIEW IN TELEGRAM
На этот раз у нас в гостях Олег Козырев, backend-разработчик из Авито.
Поговорили про:
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥9👍4
Подключайтесь к стриму с опытной IT-рекрутеркой. Мы уже начинаем)
Планируем обсудим, как попасть в IT в 2024 году, разберем популярные стереотипы и мифы о найме в этой сфере. Думаю будет увлекательная беседа о том, как разработчики и рекрутеры видят процесс трудоустройства, с чего начать карьеру в IT и как выделиться среди конкурентов.
Залетайте на стрим и задавайте свои вопросы в прямом эфире!
https://youtube.com/live/QJnkx5bHvRI?feature=share
Планируем обсудим, как попасть в IT в 2024 году, разберем популярные стереотипы и мифы о найме в этой сфере. Думаю будет увлекательная беседа о том, как разработчики и рекрутеры видят процесс трудоустройства, с чего начать карьеру в IT и как выделиться среди конкурентов.
Залетайте на стрим и задавайте свои вопросы в прямом эфире!
https://youtube.com/live/QJnkx5bHvRI?feature=share
🔥7👍2
Ко мне пригнал в гости мой хороший друг Шемистан:) Знакомлю вас с ним, потому что он будет помогать мне проверять домашки на грядущем потоке курса по микросервисам, чтобы больше человек смогло залететь:) а то в прошлый раз мне нормально так людей писало, что не успели
Шемик уже три года пишет на гошке и тоже, как и я, работает в Авито:) А вообще мы оба учились в одном классе и сидели за одной партой:) Также у него крайне интересная история жизни и тернистый путь попадания в IT, о котором можно почитать в его канале.
Хоть у Шема и хороший опыт в гошке, я перед тем, как его брать ревьювером на курс, заставил его целиком пройти курс самостоятельно😂 Чтоб он на своей шкуре почувствовал каково это ахахаха А самое главное, он весьма эмпатичный человек, который помогает советами по коду, пока не увидит, что человек понял и начал шпарить прогу дальше) Кажется это очень важно для того, кто дает тебе фидбек
А в преддверии запуска нового потока мы хотим поотвечать на ваши вопросы:) Можно про курс задавать вопросы, про го, да и в целом на общие темы) Пишите их в комменты и мы там же будет отвечать на них кружочками:)
P.S. На фотке мы показываем на свой родной город:)
Шемик уже три года пишет на гошке и тоже, как и я, работает в Авито:) А вообще мы оба учились в одном классе и сидели за одной партой:) Также у него крайне интересная история жизни и тернистый путь попадания в IT, о котором можно почитать в его канале.
Хоть у Шема и хороший опыт в гошке, я перед тем, как его брать ревьювером на курс, заставил его целиком пройти курс самостоятельно😂 Чтоб он на своей шкуре почувствовал каково это ахахаха А самое главное, он весьма эмпатичный человек, который помогает советами по коду, пока не увидит, что человек понял и начал шпарить прогу дальше) Кажется это очень важно для того, кто дает тебе фидбек
А в преддверии запуска нового потока мы хотим поотвечать на ваши вопросы:) Можно про курс задавать вопросы, про го, да и в целом на общие темы) Пишите их в комменты и мы там же будет отвечать на них кружочками:)
P.S. На фотке мы показываем на свой родной город:)
❤11🔥7👍4🥰1
А вот пошел бы Дуров к нам на курс, не падала бы так телега😂 Тогда б наверное и вовсе не подняли😁
Please open Telegram to view this post
VIEW IN TELEGRAM
🤣24👏2
🌹Rate Limiter: что, как и нафига
Го поговорим о Rate Limiter. Это штукень, которая ограничивает количество запросов к серверу за определённое время. Типа как раньше еду по карточкам давали, вот и тут та же картина с запросами к серваку. Вариков как именно ограничивать трафик много, глянем на четыре из них.
ВИДЫ АЛГОРИТМОВ
1. Fixed Window: Всё просто — допустим допускается 100 запросов в минуту. Но на границе интервалов возможны пики, и тогда сервер офигеет. Типо 99 запросов прилетит в последнюю секунду первой минуты, и в первую секунду второй минуты. В итоге за 2 секунды прилетит 198 запросов.
- Плюсы: Легко реализовать.
- Минусы: Возможны пиковые нагрузки на границах интервалов.
2. Sliding Window: Этот варик поумнее. Считает запросы в скользящем окне времени, так что пики сглаживаются, и сервер не перегревается.
- Плюсы: Сглаживает пики, равномерно распределяет нагрузку.
- Минусы: Сложнее реализовать, требует больше ресурсов.
3. Token Bucket: Это буквально ведро с токенами. Каждый запрос берёт один токен. Токены восстанавливаются со временем. Если токенов нет — запрос дропаем. Навалили в ведро 100 токенов и раз в 1/100 минуты докидываем новый токен на фоне. Если трафик летит быстрее этого темпа тут уж сорян, се ля ви.
- Плюсы: Гибкость, равномерное распределение нагрузки.
- Минусы: Может быть сложным в настройке.
4. Leaky Bucket: Ещё одно ведро, только с дыркой!)) Запросы вытекают с постоянной скоростью, а если их слишком много — всё льётся через край, и сервер рад не будет. По сути это очередь, каждый элемент которой обрабатывается через равные промежутки времени. И если очередь переполнится, то лишние запросы начинаем скипать.
- Плюсы: Предсказуемое поведение, стабильная обработка запросов.
- Минусы: Не так гибок, может отбрасывать внезапные пиковые запросы.
RATE LIMITER VS CIRCUIT BREAKER
Рейт лимитер похож ещё на один паттерн, который ограничивает трафик - сёркет брейкер. Вопрос только в чём между ними разница. Фишка в том, что Rate Limiter ограничивает количество запросов за определённое время, а Circuit Breaker предотвращает дальнейшие запросы, если предыдущие попытки завершились ошибкой.
Короче говоря, Rate Limiter юзают, чтоб предотвратить проблему с перегрузкой сервака, а Circuit Breaker, когда жопа уже наступила ахаха
Rate Limiter:
- Плюсы: Предотвращает перегрузку сервера, защищает от DDoS атак.
- Минусы: Не шарит за ошибки внутри сервиса.
Circuit Breaker:
- Плюсы: Изолирует ошибочные компоненты, предотвращает каскадные отказ системы.
- Минусы: Не предотвращает перегрузку, работает только после возникновения проблемы.
А если вам хочется поразвлекаться с рейт лимитером в живую, а не только слушать офигительные рассказы, то го сюда. В этой папке я собрал простенький grpc сервачок с метриками, рейт лимитером и прометеус в докер-компоуз запихал. Берете локально это добро поднимаете и команду из мейк файла вызываете. В итоге там утилитка ghz начинает хреначит трафиком по ручке, а вы потом увидите на графике в прометеусе, как рейт лимитер обрезает нагрузку.
ПРИМЕР ТЕСТОВЫЙ, В ПРОД ТАКОЕ НЕ ТАЩИТЕ!
Писали когда-нить свой рейт лимитер или всё готовые юзали?
P.S. На фотке держим ведра с токенами😁
Го поговорим о Rate Limiter. Это штукень, которая ограничивает количество запросов к серверу за определённое время. Типа как раньше еду по карточкам давали, вот и тут та же картина с запросами к серваку. Вариков как именно ограничивать трафик много, глянем на четыре из них.
ВИДЫ АЛГОРИТМОВ
1. Fixed Window: Всё просто — допустим допускается 100 запросов в минуту. Но на границе интервалов возможны пики, и тогда сервер офигеет. Типо 99 запросов прилетит в последнюю секунду первой минуты, и в первую секунду второй минуты. В итоге за 2 секунды прилетит 198 запросов.
- Плюсы: Легко реализовать.
- Минусы: Возможны пиковые нагрузки на границах интервалов.
2. Sliding Window: Этот варик поумнее. Считает запросы в скользящем окне времени, так что пики сглаживаются, и сервер не перегревается.
- Плюсы: Сглаживает пики, равномерно распределяет нагрузку.
- Минусы: Сложнее реализовать, требует больше ресурсов.
3. Token Bucket: Это буквально ведро с токенами. Каждый запрос берёт один токен. Токены восстанавливаются со временем. Если токенов нет — запрос дропаем. Навалили в ведро 100 токенов и раз в 1/100 минуты докидываем новый токен на фоне. Если трафик летит быстрее этого темпа тут уж сорян, се ля ви.
- Плюсы: Гибкость, равномерное распределение нагрузки.
- Минусы: Может быть сложным в настройке.
4. Leaky Bucket: Ещё одно ведро, только с дыркой!)) Запросы вытекают с постоянной скоростью, а если их слишком много — всё льётся через край, и сервер рад не будет. По сути это очередь, каждый элемент которой обрабатывается через равные промежутки времени. И если очередь переполнится, то лишние запросы начинаем скипать.
- Плюсы: Предсказуемое поведение, стабильная обработка запросов.
- Минусы: Не так гибок, может отбрасывать внезапные пиковые запросы.
RATE LIMITER VS CIRCUIT BREAKER
Рейт лимитер похож ещё на один паттерн, который ограничивает трафик - сёркет брейкер. Вопрос только в чём между ними разница. Фишка в том, что Rate Limiter ограничивает количество запросов за определённое время, а Circuit Breaker предотвращает дальнейшие запросы, если предыдущие попытки завершились ошибкой.
Короче говоря, Rate Limiter юзают, чтоб предотвратить проблему с перегрузкой сервака, а Circuit Breaker, когда жопа уже наступила ахаха
Rate Limiter:
- Плюсы: Предотвращает перегрузку сервера, защищает от DDoS атак.
- Минусы: Не шарит за ошибки внутри сервиса.
Circuit Breaker:
- Плюсы: Изолирует ошибочные компоненты, предотвращает каскадные отказ системы.
- Минусы: Не предотвращает перегрузку, работает только после возникновения проблемы.
А если вам хочется поразвлекаться с рейт лимитером в живую, а не только слушать офигительные рассказы, то го сюда. В этой папке я собрал простенький grpc сервачок с метриками, рейт лимитером и прометеус в докер-компоуз запихал. Берете локально это добро поднимаете и команду из мейк файла вызываете. В итоге там утилитка ghz начинает хреначит трафиком по ручке, а вы потом увидите на графике в прометеусе, как рейт лимитер обрезает нагрузку.
ПРИМЕР ТЕСТОВЫЙ, В ПРОД ТАКОЕ НЕ ТАЩИТЕ!
Писали когда-нить свой рейт лимитер или всё готовые юзали?
P.S. На фотке держим ведра с токенами😁
👍16🔥10❤1💯1👨💻1