🎬 ОТКРЫТОЕ СОБЕСЕДОВАНИЕ GO РАЗРАБОТЧИКА

Первое мое открытое mock собеседование: https://www.youtube.com/watch?v=sy09jrBhWzY

Задал самые частые вопросы и темы по теории Golang. К сожалению не хватило времени на вопросы про дженерики и паттерн контекст.

✔️100 ПОДПИСЧИКОВ ✔️

Спасибо всем, кто подписан на мой канал, это, правда, очень важно для меня ☝🏻

Сейчас нахожусь в отпуске. В следующем посте поделюсь впечатлениями о 2-х странах для релокации: Турция и Грузия.

ИДЕАЛЬНАЯ СТРАНА ДЛЯ РЕЛОКАЦИИ РАЗРАБОТЧИКА

В эпоху удаленной работы, высоких зарплат в IT и некоторых событий 🆘 — переезд за рубеж на некоторое время или на совсем перестал быть только мечтой. Наверное, сейчас у каждого есть хотя бы один знакомый из IT, уехавший куда-то из России.

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

Итак, первая страна — Турция🇹🇷. В 2022 большой поток русских устремился именно туда. Первая причина — на тот момент там было все сильно дешевле, чем в России. Вторая причина — Турция - это довольно развитая, южная страна с хорошей инфраструктурой, солнцем, морем и т.д. Сейчас в Турции цены сильно выросли и недвижимость тоже, так что финансово свободно там себя уже не почувствуешь. Совет по городам для проживания: Стамбул (развитый город со всеми привычными благами цивилизации), Измир (современный город без туристов), Каш (тихий городок у моря, подойдет для жизни пару месяцев летом).

Вторая популярная страна для «релокантов» стала… ГРУЗИЯ!🇬🇪
Не просто так: граничит с Россией и можно даже на машине туда попасть, вкусная еда, красивые виды, есть море. Многие говорят на русском (хоть сейчас там антироссийские настроения, на русском и английском вас всегда поймут). В Грузии я выделил два города, где большинству будет привычно - Тбилиси (столица со своей атмосферой, антуражем) и Батуми («мини Дубай» в стадии зачатка с огромным числом продающейся и сдающейся недвижимости). Но цены там не ниже московских, а на что-то даже выше.

Армения 🇦🇲 — дружественная страна для России. Здесь принимают карту МИР (актуально для тех у кого нет зарубежной), все спокойно говорят на русском. Для жизни подойдет наверное больше всего Ереван. Но будьте готовы, наши соотечественники вызвали тут рост цен во всех сегментах: аренда жилья, цены в ресторанах, аренда авто, отели, гостиницы и т д. Жизнь тут в среднем на 15-45% дороже чем в Москве.

Азербайджан 🇦🇿 — почему-то не такая популярная страна и, на мой взгляд, недооцененная. Выбор тут из городов для жизни, пожалуй, единственный, но очень хороший - Баку. Поистине столица! Тут точно есть все условия для жизни, инфраструктура, жилье и прочее. А цены на жизнь и аренду еще не разогнаны до околокосмических цифр.

——————

Надеюсь, было интересно. Если кто-то живет сейчас в этих странах, поделитесь пожалуйста в комментариях🙂

⚡️ЗНАНИЕ И ПОНИМАНИЕ ЭТИХ ТЕРМИНОВ И ТЕОРЕМ ПОВЫСИТ ВАШ ГРЕЙД НА СОБЕСЕДОВАНИИ. ЧАСТЬ 1⚡️

Мы сейчас живем в эру микросервисов, а это значит, что так или иначе разработчику приходится сталкиваться с распределенными системами. Понимание теории и принципов построения распределенных систем поможет вам не только на собеседовании, но и при решение рабочих задач. Итак, начнем!

👀Дисклеймер:

Понятие согласованности — одно из самых неоднозначных в ИТ.
❗️Важно: значение термина меняется, если речь идет о БД или распределенных системах. В CAP, ACID и модели согласованности данных - термин согласованность имеет разные оттенки смысла.

CAP - теорема (теорем Брюера)

В CAP говорится, что в распределенной системе возможно выбрать только 2 из 3-х свойств:

-🔠 Consistency — согласованность данных. На всех не отказавших узлах одновременно одинаковые (с точки зрения пользователя) данные.
-🔠 Availability — доступность. Каждый не отказавший узел всегда успешно отвечает (на чтение и запись).
-🔠 Partition tolerance — устойчивость к фрагментации. Даже если между узлами нет связи, они продолжают работать независимо друг от друга.

Следствие из этой теоремы: распределённые системы делятся на три класса в зависимости от поддерживаемых свойств — CA, CP, AP.

🟧CA
В системах класса CA во всех узлах данные согласованы и обеспечена доступность, при этом она жертвует устойчивостью к распаду на части. Другими словами, мы можем достичь высокой степени согласованности при относительно небольшом времени простоя, но мы рискуем, что проблемы с сетью приведут к сбою всей системы или, по крайней мере, вызовут сбои.
Системы CA обычно основаны на традиционных реляционных базах данных, таких как MySQL👩‍💻, PostgreSQL👩‍💻, MSSQL👩‍💻 или Oracle.

🟧CP
Система вычислений класса CP в каждый момент обеспечивает целостный результат и способна функционировать в условиях распада, но достигает этого в ущерб доступности: может не отвечать на запрос. Самый популярный пример CP системы — MongoDB👩‍💻.

🟧AP
В системе вычислений класса AP не гарантируется свойство согласованности данных, но при этом выполнены условия доступности и устойчивости к разделению. Большинство NoSQL-систем принципиально не гарантируют целостности данных, и ссылаются на теорему CAP как на мотив такого ограничения. Яркий пример AP системы — CouchDB, Cassandra, ScyllaDB.

Поскольку в AP системах мы не можем добиться очень важного свойства - согласованности данных (а, если быть точнее, в терминах моделей согласованности - строгой согласованности), то главной задачей при построении AP-систем становится обеспечение некоторого практически целесообразного уровня целостности данных (т.е. понижения требования к свойству согласованности). В этом случае про AP-систем, как правило, говорят, либо как о «согласованных в конечном итоге» (eventually consistent) или как о «слабо согласованных» (weak consistent).

💫 В следующей части рассмотрим модель согласованности данных.

В дополненни к прошлому посту ⬆️

AP СИСТЕМЫ

AP-системы, которые обеспечивают доступность (Availability) и устойчивость к разделениям (Partition Tolerance) в ущерб строгой согласованности (Consistency), необходимы в ситуациях, где важно, чтобы система всегда оставалась доступной, даже в условиях разделений сети или отказов отдельных узлов.

Вот несколько примеров самых популярных AP-систем:

1️⃣ Социальные сети

Facebook, Twitter и Instagram часто используют AP-системы для хранения и доставки контента, такого как посты и комментарии, которые могут быть временно несогласованными (eventually consistency), но всегда доступны.

2️⃣ Мессенджеры

WhatsApp, Telegram, Slack, VK, ... должны гарантировать, что сообщения доставляются пользователям, даже если некоторые серверы временно недоступны:

- Availability: Пользователи должны иметь возможность отправлять и получать сообщения в любое время.
- Partition Tolerance: Сообщения могут доставляться с некоторыми задержками или повторениями, но система продолжает работать даже при разделении сети.

Опять же в большинстве случаев применяется eventually consistency (сообщения в чатах в итоге на разных узлах серверов будут согласованы со временем)

3️⃣ Файловые системы и системы хранения данных

Пример: S3 - должен быть всегда доступными для чтения и записи данных, даже если часть серверов недоступна.

4️⃣ Системы доставки контента (CDN)

CDN — это распределенная сеть серверов, которая предоставляет контент пользователям с ближайших к ним серверов. Примеры CDNs включают Akamai, Cloudflare, ...

- Availability: CDN всегда старается предоставить пользователю контент. Если один из серверов недоступен, запросы будут перенаправлены на ближайший доступный сервер.

- Partition Tolerance: CDN продолжает работать даже при разделении сети. Пользователи будут обслуживаться ближайшими доступными серверами, даже если некоторые части сети становятся недоступными.

CDN может кэшировать устаревшую версию контента для обеспечения доступности. Обновления контента могут быть задержаны или не синхронизированы мгновенно между всеми серверами (опять eventually consistency)

5️⃣ DNS (Domain Name System)

- Availability: DNS должен всегда отвечать на запросы, чтобы пользователи могли находить нужные веб-сайты. Если один DNS-сервер недоступен, запросы будут отправлены на другой сервер.

- Partition Tolerance: DNS продолжает функционировать даже при разделении сети. Различные DNS-серверы могут продолжать работать независимо друг от друга.

В некоторых случаях обновления DNS-записей могут не сразу распространяться по всем серверам, что приводит к возможным несогласованностям в краткосрочной перспективе.

6️⃣Базы данных Scylla, Cassandra

Лучше всего описано в первоисточниках тут и тут.

📏📏📏📏📏📏📏📏📏

Как достигается "достаточная согласованность"? Все зависит от системы, необходимого уровня консистентности данных (будем рассматривать позже) и применяемых алгоритмов консенсуса (2PC, Gossip, Paxos, ...). Чаще всего eventually consistency достигается дополнительными фоновым процессами приводящие данные на разных узлах в согласованное состояние.

🔔 ВНИМАНИЕ 🔔

📆2 августа ваш покорный слуга выступает с докладом на Ural Digital Weekend с темой:
«50 оттенков кеширования: от in memory к многослойному redis-кластеру».

В своем докладе расскажу про задачи, которые стояли перед моей командой в Ozon, как мы их решали и адаптировали нашу архитектуру кеширования данных на примере Redis. Также поведаю какие ошибки мы совершали и к чему в итоге пришли.

Делюсь с вами личным промокодом CHENSKYGIFT10, который дает СКИДКУ 10% на билет Ural Digital Weekend 2024. Количество билетов ограничено! Следите за новостями конференции по ссылке и на канале конфы!

Жду вас на конференции и до встречи!

Конференция организована компанией Spectr при поддержке Тэглайна

📹ЗАПИСЬ ОТКРЫТОГО УРОКА ПО KUBERNETES 👩‍💻

https://www.youtube.com/watch?v=NbXtSLv2ek0

⬇️Презентация урока ниже ⬇️

⚡️ЗНАНИЕ И ПОНИМАНИЕ ЭТИХ ТЕРМИНОВ И ТЕОРЕМ ПОВЫСИТ ВАШ ГРЕЙД НА СОБЕСЕДОВАНИИ. ЧАСТЬ 2 МОДЕЛЬ СОГЛАСОВАННОСТИ ДАННЫХ ⚡️

Продолжаю серию статей об основных терминах в распределенных системах, которые стоит знать и понимать Senior разработчику. Часть 1 👉 тут.
Поехали!

Первое определение, которое интуитивно понятно, но нужно нам для понимания "тривиальных" вещей:

Согласованность данных (консистентность данных, англ. data consistency) — согласованность данных друг с другом, целостность данных, а также внутренняя непротиворечивость.

Отсюда нам важно два пункта: согласованные данные - целостны и непротиворечивы.

Теперь дадим определение модели согласованности:

Модель согласованности — подход, используемый в той или иной распределённой системе (пример: распределённой общей памяти, СУБД, файловой системе, микросервисы, ...) для обеспечения гарантий согласованности данных.

Поэтому модель согласованности актуальна на аппаратном уровне, на программном уровне и на архитектурном уровне.

Основные модели согласованности:
🟠Строгая согласованность (англ. strict consistency)
🟠Последовательная согласованность (англ. sequential consistency)
🟠Причинная согласованность (англ. causal consistency)
🟠PRAM-согласованность (англ. PRAM consistency)
🟠Процессорная согласованность (англ. processor consistency)
🟠Слабая согласованность (англ. weak consistency)
🟠Согласованность в конечном счете (англ. eventual consistency)
🟠Согласованность по выходу (англ. release consistency)
🟠Согласованность по входу (англ. entry consistency)

СТРОГАЯ СОГЛАСОВАННОСТЬ

Моделью строгой согласованности, называется модель удовлетворяющая условию:

Операция чтения переменной X должна возвращать значение, записанное самой последней операцией записи переменной X,


Все однопроцессорные системы обеспечивают строгую согласованность, но в распределенных многопроцессорных системах ситуация намного сложнее…

Предположим, что переменная Х = 1 расположена в памяти/ на диске нашей базы данных (БД), и процесс, который выполняется в нашем сервисе Р1, пытается прочитать значение этой переменной в момент времени T1. Для этого сервис посылается запрос чтения переменной X. Немного позже, в момент времени T2 > T1, другой процесс P2, производит операцию записи нового значения в переменную X = 2. Для обеспечения строгой консистентности операция чтения должна возвратить в процесс P1 старое значение переменной (X = 1) вне зависимости от того, где расположен наш сервис (P1) и насколько близки между собой два момента времени T1 и T2.

Однако, если между разница между T1 и T2 мала, и по каким-то причинам процесс P2 смог быстрее выполнить операцию (за счет меньших сетевых издержек, или P2 этот локальный процесс в БД), P1 получит результат X = 2.

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

——————

Ставьте 🔥 если хотите узнать подробнее про остальные модели согласованности данных, 🗿 — новая тема.

Ozon Tech Community Go Meetup 🧑‍💻

31 июля | 18:30 мск | офлайн + онлайн
📍Москва, Нижняя Сыромятническая 11, к1, 3 этаж

Собираемся в новой локации — в уютном лофте. Комфортно нетворкать, играть и, конечно, слушать полезное.

Ускорим автобиддеры, минимизируем ошибки в бизнес-логике и подискутируем о надёжности микросервисов — будет интересно, присоединяйтесь!

Подробнее о докладах:

➡️ «Кэш на кэш: как ускоряли автобиддеры»
— поговорим о подходах к выбору In-memory кэша, сравним технические реализации в Go-библиотеках In-memory кэширования, поделимся опытом эксплуатации кэшей в наших сервисах.

➡️ «Снижение ошибок в бизнес-логике»
— разберёмся в видах и источниках ошибок, обсудим, какое влияние они оказывают на наши системы и пользователей. А потом поговорим про инструменты Go, которые повышают надёжность релизов.

➡️ А ещё готовим для вас панельную дискуссию с приглашёнными экспертами по теме обеспечения стабильности микросервисов.

Регистрируйтесь на офлайн или онлайн на нашем сайте.

#ozontech_meetup #golang

Какие люди на Ural Digital Weekend!

Ждите их на докладах, ловите в кулуарах, наслаждайтесь общением.

↪Как создавать идеальные фичи и избегать багов, объединяя тестировщиков и разработчиков.
Олег Пендрак, техлид SDET, поделится нюансами синхронизации коллег, инструментами для совместной работы и процессом создания культуры безопасности.

↪gRPC-стримы на практике: к чему готовиться и где применять.
Сергей Антоничев, ведущий разработчик информационных систем, расскажет, как работают gRPC-стримы, когда запросы нужны асинхронно, много и постоянно.

↪50 оттенков кэширования: от in memory к многоуровневому Redis-кластеру.
Леонид Ченский, руководитель группы разработки, покажет, как адаптировали архитектуру к кратному росту нагрузки год от года.

А ещё весь день на связи Виктор Корейша, руководитель направления Managed Services. Витя будет модерировать секцию «Разработка».

Подключайтесь онлайн тут, если вы не там 📱

На днях вышел подкаст со мной от «Разрабы.Подкаст» ▶️

На подкасте обсуждали зачем нужна платформа в BigTech компаниях, чем занимаются разработчики в платформенных командах и конечно много жизненных историй из IT!

Приятного просмотра ❤️

Вносить правки в презентацию за пару часов до выступления - это база 😅

Для тех, кто не сможет сегодня присутствовать очно на конференции Ural Digital Weekend в Перми, делюсь ссылкой на трансляцию 📺

▶️ 50 оттенков кеширования: от in memory к многоуровневому redis-кластеру

Для тех, кто не смог посмотреть мой доклад на конференции Ural Digital Weekend и у кого YouTube не хочет работать 📺

❤️В докладе рассказывал как мы в команде адаптировали архитектуру к кратному росту нагрузки (вплоть до 210k rps) год от года.