Всем привет!

Меня зовут Леонид Ченский, и я решил начать вести свой канал, посвященный разным темам из жизни разработчика.

Расскажу немного о себе:
➡️мне 25 лет
➡️закончил университет им.Баумана, факультет Информационного Управления с красным дипломом
➡️проф.погружение в IT началось с 1.5 годового курса от Mail.Ru “Технопарк”
➡️в IT работаю с 2019г.
➡️ex. Golang-разработчик
➡️уже 3 года как Teamlead
➡️выпустил 4 потока обучения Go разработчиков в Ozon Школе “Route256”: прошел путь от тьютор до декана школы
➡️приглашенный спикер подкаста Reg.ru ▶️
➡️учасник golang meetup-а ▶️
➡️"человек который творил эту эпоху и сам стал эпохой" (ну вы поняли😉)


На данный момент являюсь Teamlead-ом команды DBaaS ScyllaDB в Ozon Tech в департаменте платформы.
До этого 2 года был руководителем команды в Логистике Ozon, а еще до этого - golang разработчиком в этой же команде. К слову, в этой команде мне приходилось проектировать сервисы, способные держать более 450k запросов пользователей в секунду. Highload-а было много.

Помимо разработки я также делился своей экспертизой в школе Route256 (школа от Ozon для разработчиков уровня middle). Сначала был тьютором, проверял домашние задания и консультировал учеников, далее был преподавателем и лектором, а после дошел до позиции декана в Route256.

Здесь в канале я планирую продолжать делиться своей экспертизой, а также выносить какие-то важные темы для обсуждения, советовать полезные, на мой взгляд, материалы и просто публиковать своими мысли 📢

Добро пожаловать!👋

🚀КАК С НУЛЯ РАЗРАБОТАТЬ МИКРОСЕРВИСЫ, КАК В BIGTECH?

📆 Уже сегодня в 18:00 по МСК я проведу бесплатный открытый урок по микросервисам!

🎥Трансляция будет доступна по этой ссылке.

Курс будет посвящен разработке микросервисов, где я буду рассказывать про самые актуальные темы и проблемы. Лендинг курса можно посмотреть по этой ссылке.

Когда меня спрашивают, почему я выбрал 👩‍💻 в качестве языка разработки.

Я просто выбрал быть более продуктивным разработчиком⚡️

А вообще мой первый язык разработки 👩‍💻 и я 2 года на нем разрабатывал и он мне очень понравился, но как говорится, лучше больше, чем меньше.

📣 Вчера состоялся открытый урок по микросервисам! Спасибо всем, кто подключился, надеюсь вам понравилось!

📹Как и обещал, запись открытого урока уже доступна по ссылке.

У меня есть одна хорошая, на мой взгляд, привычка подробно погружаться во внутреннее устройство любой технологии: языка программирования, базы данных, брокера сообщений и т.д.

Почему я советую поступать также? Во-первых, это помогает понять все сильные и слабые стороны инструмента, которым вы пользуетесь или планируете пользоваться. А во-вторых у вас появляется большое преимущество в компании и на рынке перед остальными разработчиками - вы становитесь экспертом в данной технологии, и те решения, которые вы сможете принимать и внедрять, будут приводить к максимально хорошим и продуктивным результатам.

👩‍💻 Язык Go не стал исключением и я подробно погрузился в его устройство. Что я узнал:
🟠Go написан на go - да, как бы странно это не звучало, но всем, чем мы пользуемся в go, написано на нем же, все исходные файлы открыты и их можно изучать.
🟠Go не просто язык программирования, go - это целая экосистема!
🟠Основные 3 кита, делающих go таким, каким мы его знаем: планировщик, сборщик мусора и устройство памяти, и netpoller.

У меня ушло немало времени, чтобы разобраться во всех тонкостях устройства данного языка. По итогу я собрал самые лучшие материалы раскрывающие подробно все нюансы Go и решил поделиться ими с вами в своем репозитории: https://github.com/moguchev/golang. Периодически я актуализирую данный список источников, добавляю новые статьи, видео и новые темы, поэтому советую добавить в избранное🌟

А какие технологии хорошо знаете вы?

#go

‼️ЗАДАЧА О ДВУХ ГЕНЕРАЛАХ. ЧАСТЬ 1.

Зачем я спрашиваю на собеседовании у Senior разработчиков задачу о 2-ух генералах?

Давайте начнем с самой задачи:

Две армии, каждая руководимая своим генералом, готовятся к штурму города. Лагеря этих армий располагаются на двух холмах, разделённых долиной. Единственным способом связи между генералами является отправка посыльных с сообщениями через долину. Но долина занята противником и любой из посыльных может быть перехвачен. Проблема заключается в том, что, генералы заранее (пока была связь) приняли принципиальное решение о штурме, но не согласовали точное время штурма.
Для успешного штурма генералы должны атаковать город одновременно. Штурм, предпринятый только одной армией, приведёт к катастрофическим последствиям для атакующих (фактически к поражению).
Требуется найти алгоритм обмена сообщениями, после которого каждый генерал был бы уверен, что они оба атакуют в указанное время.

Достичь такого соглашения (в случае надёжного канала связи) очень просто — достаточно одного сообщения с временем начала штурма и одного сообщения, подтверждающего согласие.
Сложность задачи заключается в невозможности разработать алгоритм гарантированного обмена этими сообщениями при ненадежном канале связи: т.е сообщение может потеряться, или мы можем не получить подтверждение.

ПРИЧЕМ ЗДЕСЬ РАЗРАБОТКА? Все просто: в большинстве микросервисных системах так или иначе используются брокеры сообщений (тот самый посыльный). Когда два сервиса обмениваются асинхронно сообщениями, они как 2 генерала на двух холмах, не знают дошло ли сообщение или нет.

‼ЗАДАЧА О ДВУХ ГЕНЕРАЛАХ. ЧАСТЬ 1.

Конечно технологии идут вперед и брокеры сообщений пытаются обеспечить надежную доставку сообщений, но нет 100% гарантии. Поэтому при работе с брокерами сообщений очень важно понимать следующие семантики:

➡️ at least once («хотя бы один раз») - если мы не получили подтверждение от «посыльного», мы можем отправить еще одного через какое-то время. В чем тут проблема: получатель может получить оба этих письма, и хорошо если в них одинаковые сообщения, а если разные?)
➡️ at most once («не более одного раза») - если мы не получили подтверждение от «посыльного», мы ничего повторно не отправляем, дабы избежать путаницы в сообщениях у получателя. Тут проблема, что часть посланий получатель может не получить, а это может оказаться критичным для ряда случаев (например при штурме замка, или если вы отправляете событие в логистику о создании заказа)
➡️ exactly once («строго однократная доставка») - то чего, как мы поняли из задачи, добиться очень тяжело. Если мы отправим несколько посыльных, получатель должен получить только одно письмо. Чаще всего это достигается с помощью специальной «пометки» на письме - ключа идемпотентности. Получатель (или коллективный разум посыльных, если такой бы был) по этой метке понимает, является ли данное сообщение дубликатом уже прочитанного сообщения или нет, и игнорирует его.

Одним из инструментов, позволяющим реализовать любую из данных семантик, является Apache Kafka. Это довольно гибкий и производительный брокер сообщений. Но за счет его гибкости на разработчика возлагается БОЛЬШАЯ ответственность при разработке системы: от выбора семантики обмена сообщениями, до выставления необходимых настроек на клиенте и брокере. Поэтому, я считаю, что понимание данных основ обязательно для Senior разработчиков.
__________________________

❓А каких еще брокеров сообщений вы знаете, и какие семантики они способны обеспечить?

👩‍💻 ВНУТРЕННЕЕ УСТРОЙСТВО ПЛАНИРОВЩИКА GO!

Ранее я говорил, что очень не равнодушен к статьям и докладам про внутренние устройство языков и технологий. А особенно, если это про Go!

📆 23 апреля в 19:00 по МСК мой коллега по цеху, Владимир Балун, проведет бесплатный открытый урок по внутреннему устройству планировщика Go.

Если вы давно хотели разобраться как устроен Go под капотом — это отличная возможность! В программе открытого урока множество тем, которые обычно любят задавать на собеседовании.
Не пропустите такую возможность, регистрируйтесь на открытый урок!

Регистрация доступна по ссылке.

📌 Частый вопрос на собеседование про SQL: последовательность выполнения SQL команд.

Обратите внимание, что LIMIT и OFFSET выполняются в самом конце. Т.е если вы делаете пагинацию через LIMIT+OFFSET, то БД будет проделывать всю выборку и только потом ограничивать выдачу запроса.

На эту тему есть хорошая статья про пагинацию в PostgreSQL.

👩‍💻 PostgreSQL - СОВЕТЫ ПО ЭФФЕКТИВНОЙ РАБОТЕ.
ЧАСТЬ 1.

PostgreSQL - в настоящая время одна из самых популярных СУБД на рынке. Все компании и разработчики любят Posgtres за его надежность, производительность, поддержку ACID транзакций и многое другое. Я бы сказал что PostgreSQL - это швейцарский нож в кармане любого уважающего себя backend-разработчика.

PostgreSQL - тот инструмент, который легко внедрить и использовать в production решениях. Но с ростом проекта и нагрузок на первый взгляд может показаться, что производительности PostgreSQL уже не хватает. На самом деле это не всегда так. И вот верные способы выжать ПО МАКСИМУМ из этого прекрасного слоника:

1️⃣CONNECTION POOLER

ОБЯЗАТЕЛЬНО используйте пуллер соединений. Для чего он нужен? Когда у вас много инстансов вашего приложения, становится очень сложно контролировать количество соедиенеий к Postgres, а на каждое соединение СУБД тратит не мало ресурсов на их обслуживание. Пуллеры соединения решают эту проблемлему: они становятся прокси серверами между вашим приложением и БД и контролируют заданное число соединений, да еще и утилизируют из по максимум. github.com/yandex/odyssey - один из самых лучших пуллеров соедиеней на сегодняшний день.

2️⃣НИКАКОЙ БИЗНЕС ЛОГИКИ В БД

Откажитесь от триггеров, хранимых процедур, внешних ключей, лишних и жестких сonstraint-ов, которые лишний раз валидируют то, что должно валидировать ваше приложение! В 2024 году ваше приложение должно заботиться о валидности и консистетности данных. БД - просто инструмент для хранения и получения данных. Помните: приложение масштабировать (скейлить) сильно проще, чем вычислительные ресурсы БД.

3️⃣ИЗБЕГАЙТЕ ШИРОКИХ ТАБЛИЦ

Если в вашей таблице 40+ колонок, вы что-то явно делаете не так. Дело все в том, что Postgres хранит записи таблицы в файлах по строчно друг за другом, и когда вы делаете обновление строк, на самом деле это запись новой версии строки, и, если обновляете 2-3 поля, остальные ваши поля кочуют баластом. PostgreSQL на много лучше управляет относительно небольшими строками, а если они еще и фиксированной длинны, тогда место на дисках и в кеше экономится значительно больше. Также лучше все колонки переменной длинны располагать в конце таблицы.

4️⃣ИЗБЕГАЙТЕ ТАБЛИЦ С ГИГАНТСКИМ КОЛИЧЕСТВОМ СТРОЧЕК

Тут все просто - чем больше записей в таблице - тем больше размер индекса. Чем больше размер индекса - тем больше файлов индекса требуется прочитать БД. Если индекс весит несколько гигабайт, он не умещается в оперативной памяти Postgres и тогда происходит уже чтение с диска, а это довольно медленная операция. Но как быть если записей и правда много и нам все их надо хранить? Ответ кроется в следующем пункте.