⚡️ЗНАНИЕ И ПОНИМАНИЕ ЭТИХ ТЕРМИНОВ И ТЕОРЕМ ПОВЫСИТ ВАШ ГРЕЙД НА СОБЕСЕДОВАНИИ. ЧАСТЬ 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) год от года.

ЧТО МЕНЯ УДИВИЛО, КОГДА Я СТАЛ TEAMLEAD-ом?

Когда я стал Teamlead-ом, меня отправили на внутреннее обучение, где учили таких же как и я «зеленых» лидов, быть настоящими руководителями. Много инсайдов узнал я на том обучении. Был очень классный оффлайн формат, отличный преподаватель и вообще тот курс я вспоминаю с ностальгией🥲

Один из инсайдов, который я узнал: есть простая модель DISC, согласно которой человека, в зависимости от его поведенческого стиля, можно отнести к одной из 4-х групп:

D (Доминирующий)
I (Влиятельный)
S (Устойчивый)
C (Добросовестный)

На самом деле у человека редко бывает четко выражен только один стиль поведения. Чаще всего это пара, где преобладает больше 1 (например C и D стили, это не тоже самое что и D и С)

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

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