Всем привет!

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

Расскажу немного о себе:
➡️мне 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 и тогда происходит уже чтение с диска, а это довольно медленная операция. Но как быть если записей и правда много и нам все их надо хранить? Ответ кроется в следующем пункте.

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

5️⃣РАЗДЕЛЯЙ И ВЛАСТВУЙ

При проектировании схемы БД и модели данных сразу прогнозируйте объем данных через год-два. Если вы понимаете, что число записей сильно переваливает за миллион, стоит задумать о том по какому принципу стоит делить эти данные. Например, если у вас интернет магазин и вы храните записи о заказа клиента, скорее всего заказы сделанные давно вам редко будут нужны. В этом случае поможет партиционирование таблицы по временному интервалу (в данном случае ключ партиционирования - время создания заказа). Postgres будет иметь набор условно маленьких табличек, каждая из которых содержит свои маленькие индексы. в 90% случаях вы будете работать со свежими заказами, и все запросы будут идти в последние партиции, которые уже полностью могут помещаться в кеш Postgres. Вы можете выбрать ключом партиционирования что угодно, главное, чтобы партиции были +- одного размера и обращения происходили к минимальному их количеству.

6️⃣RAM - НАШЕ ВСЁ

Берегите оперативную память Postgres. Не бойтесь накидывать больше оперативной памяти кешу Postgres - чем больше он, тем больше данных там поместится, и тем меньше будет чтений с диска, и, соотвественно, меньше задержек. Но оперативная память нужна не только кешу, она нудна также для обработки запросов приложения. Следите за потреблением памяти вашими запросами, старайтесь доставать как можно меньше данных из БД. По максимум фильтруйте записи, где это возможно. Не делайте 10 JOIN-ов ради того, чтобы обогатить ответ парочкой полей, которые могли бы хорошо закешироваться в вашем приложении.

7️⃣ДЕНОРМАЛИЗАЦИЯ ДАННЫХ

3-я нормальная форма - это конечно хорошо, но если 90% запросов в БД - это чтение с постоянными одними и теме же JOIN-ами, то стоит задуматься о денормализации данных. Денормализованные данные сложнее обновлять, но довольно просто получать по одному ключу.

8️⃣ДОЛГИЕ ТРАНЗАКЦИИ - ЗЛО

Любая транзакция несет много накладных расходов, а долгоживущая транзакция - это ноша, которая тяжелеет с каждой новой параллельно выполненной транзакцией. Долгая транзакция также не позволяет пуллеру переиспользовать соединение с БД для других запросов. Также не стоить делать большое число изменений/удалений в рамках одной транзакции, это может вызвать bloat.
Маленькие быстрые транзакции лучше себя ведут.

9️⃣МАСШТАБИРОВАНИЕ

Postgres можно мастшабировать двумя способами:

1. За счет добавления реплик и чтения из них. В этом случае не стоит использовать мастер только на запись, так как Postgres собирает статистику использования данных только с мастера. Эта статистика очень хорошо помогает при планировании исполнения запросов. При чтении с мастера эта статистика попадет в реплики и они начнут более эффективно строить планы запросов.
2. За счет шардирования. Тут все просто, вы разделяете ваши данные по разным инстансам и контролируете где какие лежат. К сожалению из коробки PostgreSQL не умеет шардировать данные и вам скорее всего придется использовать сторонние решения.

🔟 МОНИТОРИНГ

Ну и последний совет: собирайте статистику и метрики, которые предоставляет Postgres. Обеспечьте мониторинг вашей БД 24/7 и своевременно находите узкие места. Анализируйте запросы. Не увлекайтесь ненужными индексами, они не всегда ускоряют запросы. Создавайте индексы под определенные частые запросы.