Путь чтения в LSM индексах: как найти иголку в стоге сена

В прошлом посте мы выяснили, что Cassandra ради скорости записи создает на диске десятки файлов - SSTable. Это порождает главный вопрос: "Окей, а как потом эффективно все это читать?"

Давай пройдем путь твоего SELECT запроса и посмотрим, чего стоит эта скорость.

1️⃣ Шаг 1: Поиск ответственных реплик

Ты отправляешь запрос SELECT * FROM users WHERE user_id = 'alex'; на любой узел кластера (он становится координатором)

Координатор не ищет данные "по всему миру". Он использует The Ring (разбирали в этом посте), чтобы по ключу alex мгновенно определить, какие именно узлы отвечают за эти данные. Это узлы-реплики. Именно им (и только им) он и отправляет запросы на чтение.

2️⃣Шаг 2: Сбор данных внутри узла-реплики

Каждый узел-реплика должен найти данные для alex у себя. А они могут быть в двух местах:
- В Memtable в памяти
- В десятках SSTable-файлов на диске

Просто сканировать все SSTable — это катастрофа для производительности. Поэтому Cassandra использует арсенал хитростей, чтобы минимизировать чтение с диска.

Как избежать сканирования диска

🟡 Фильтр Блума (Bloom Filter)

Прежде чем трогать SSTable-файл, Cassandra задает вопрос его Фильтру Блума: "Есть ли ключ alex в этом файле?"

Ответ "Точно нет" ▶️ Cassandra пропускает этот файл и экономит кучу дисковых операций

Ответ "Может быть, да" ▶️ Это не 100% гарантия, но сигнал, что нужно проверить этот файл внимательнее

🟡Кэши и "оглавление" — ищем точный адрес

Итак, Фильтр Блума сказал "может быть". Теперь нужно найти ключ внутри SSTable

Сначала Cassandra проверяет Partition Key Cache. Это кэш в памяти для "горячих" ключей, где хранятся их прямые адреса на диске. Если повезло — мы сразу прыгаем в нужную точку файла.

Если в кэше пусто, Cassandra смотрит в Partition Summary. Это как "оглавление" для SSTable, тоже в памяти. Оно не дает точный адрес, но помогает определить небольшой диапазон на диске, который нужно просканировать.

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

3️⃣Шаг 3: Финальное слияние

1️⃣ Каждый узел-реплика собирает все найденные версии данных для alex из Memtable и SSTable и отдает их координатору
2️⃣ Координатор получает ответы от всех реплик
3️⃣ Он применяет правило Last Write Wins (LWW): из всех полученных версий он выбирает одну — с самой свежей временной меткой
4️⃣ Эта финальная версия возвращается твоему приложению

Смотри схему в посте, которая наглядно показывает процесс чтения

Финал 👌

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

Теперь ты видишь, почему для Cassandra так важны правильная модель данных (чтобы запросы были по Partition Key) и настроенный Compaction (чтобы SSTable-файлов было поменьше)

А в следующем посте этой серии поговорим про согласованность данных в кластере

〰️〰️〰️〰️〰️〰️〰️〰️〰️

Именно понимание согласованности критически важно для работы с распределенными системами.

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

Большинство распределенных БД не гарантируют заявленный уровень надежности

Есть ребята из Jepsen — они профессионально ломают распределённые системы: делают перебои сети, имитируют сбои и смотрят, что реально происходит с данными (Kafka, Cassandra, Zookeeper etc)

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

Почему это важно для тебя как разработчика/архитектора:
🔵Ты строишь поверх БД бизнес-логику, которая не должна ломаться
🔵“eventual consistency” vs “linearizability” — это не теоретическая разница, а реальные баги в деньгах, заказах и транзакциях
🔵Выбор БД сводится к пониманию гарантий БД и требований твоей системы

Поэтому если хочешь заиспользовать какое-то решение для распределенных систем - изучи кейсы внедрения и какие ошибки были найдены

Одна из самых сложных систем, которую спрашивают в Ru Big Tech

Недавно гонял на собес в один Big Tech и был на секции system design. Решил рассказать про систему, которую давали😼

Очень часто на собеседовании тебя просят задизайнить что-то eventual consistency подобное. Где данные в одной части системы могут временно отличаться от другой.

Или же, где механики позволяют делать запросы к мастеру. Допустим, твоя страница ленты идет к мастеру, а у остальных пользаков - к slave

Но что если тебя просят задизайнить что-то, где требование строгой согласованности важнее доступности?

Вот здесь и выступают на первый план
🟢CAP теорема
🟢Понимание репликации внутри 1 ДЦ и кросс-ДЦ
🟢Что такое rack в ДЦ и почему важно реплицировать данные между разными стойками внутри 1 ДЦ
🟢Модели консистентности: weak, eventual, causal, strong
🟢Распределенные блокировки


Тема достаточно сложная, но распишу ряд шагов, которые упростят твое проектирование

0️⃣Обстучали функциональные требования
Не сразу бросились считать что-то, а проговорили с интервьюером, правильно ли понимаем задачу

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

То есть нужно показать, что ты умеешь проектировать такие системы и знаешь реальные проблемы

Именно в таких рассуждениях мы пришли к тому, что систему можно будет масштабировать по всему миру

1️⃣Посчитали нефункциональные требования

Хоть мы и создаем счета и переводим деньги - запрос текущего баланса является гораздо более частой операцией.

read / write = 2/1

2️⃣Раскидали домены
База, про которую уже много раз говорили.
Не кидаемся проектировать слепо

3️⃣Проектируем все в рамках 1-го ДЦ и даже 1 сервера
Не нужно бросаться делать сложную систему на весь мир.

Идем поступательно
🟢Как гарантировать синхронизацию данных в рамках 1 инстанса БД. А как в рамках двух инстансов? Тут вспоминаем про синхронные и полусинхронные репликации. А также про ack от хотя бы 2-ух ДЦ
🟢Как делать блокировки в рамках 1-го инстанса и далее в рамках 2 и более? Для 1-го можно обойтись optimisitc или pessimistic locking. Но вот для распределенных систем такое решение уже не подойдет
🟢Как данные могут потеряться при переводах?

4️⃣Масштабируем систему
Здесь погружаемся в сложности, которые упомянули в прошлом пункте.

Также не забывай, что данные нужно синхронить между ДЦ. Будем ли использовать MirrorMaker, встроенные решения у NewSQL (CockroachDB, YDB) или самописные велики?

Не забываем про majority rule для машин в кластере

Также смотрим на профиль нашей системы: можно выделить в разные сервисы чтение и запись и масштабровать их отдельно.

5️⃣Помним про безопасность
Не паримся и используем готовые IdP решения по типу Keyсloak

6️⃣Как будем раскатывать?
По регионам/юзерам или как-то еще? Здесь лучше взять canary release и продумать механику плавного открытия

7️⃣Метрики, надежность и все вокруг этого


Сохрани эти заметки для проектирования подобных систем

Принцип, которому следуют все распределенные БД

Продолжим серию постов про устройство больших систем на примере Cassandra.

По дефолту Cassandra - AP система (Availability > Consistency). Но ее крутость в том, что она дает тебе возможность управлять этим компромиссом. Это можно делать благодаря Consistency Level (CL, Уровень Согласованности)

Вспоминаем базу

🟡Replication Factor (RF): Сколько всего копий данных хранится в кластере. Обычно 3
🟡Координатор: Узел, который получил твой запрос и управляет его выполнением на других узлах. Прочитать подробнее можешь в этом посте

Consistency Level — это правило для координатора: от скольких реплик нужно дождаться ответа, чтобы считать операцию успешной.

Давай разберем самые популярные уровни на примере RF = 3

🚀 CL = ONE: быстро и просто

🟡Как работает: Координатор ждет ответа от одной ближайшей реплики и сразу говорит "ОК"
🟡Плюсы: Максимальная скорость. Запрос успешен, даже если 2 из 3 реплик лежат
🟡Минусы: Ты можешь записать данные, а при следующем чтении попасть на узел, который еще не успел их получить, и увидеть старую версию
🟡Когда использовать: Лайки, счетчики просмотров, логи — там, где скорость важнее 100% точности в моменте.

🐢 CL = ALL: надежно, но долго

🟡Как работает: Координатор ждет ответа от всех реплик
🟡Плюсы: Гарантия, что все копии данных идентичны прямо сейчас
🟡Минусы: Если хотя бы одна реплика недоступна, запрос упадет
🟡Когда использовать: Крайне редко. Например, при изменении пароля, но и то с оговорками. В 99% случаев есть варианты получше

⚖️ CL = QUORUM: золотая середина

🟡Как работает: Координатор ждет ответа от большинства реплик. Формула: (RF / 2) + 1. Для RF=3 это 2
🟡Плюсы: Отличный баланс. Кластер переживет отказ одной реплики
🟡Минусы: Медленнее, чем ONE

Есть и другие уровни (TWO, THREE, LOCAL_QUORUM), но эти три — основа, с которой ты будешь работать чаще всего. Можешь более подробно глянуть про них вот здесь


Главная суть в формуле: R + W > N

Вот тут важный момент. Cassandra — это eventual consistency система. Но с помощью CL ты можешь добиться поведения, очень похожего на строгую согласованность, для конкретных операций.

Формула проста: R + W > N
🟡N — твой Replication Factor (например, 3)
🟡W — CL для записи (Write)
🟡R — CL для чтения (Read)

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

Пример:
N = 3
🟡Ты пишешь данные с W = QUORUM (ждешь ответа от 2 реплик)
🟡Ты читаешь данные с R = QUORUM (читаешь с 2 реплик)

Подставляем: 2 (R) + 2 (W) > 3 (N). Условие выполняется.

Почему это работает?

Из-за пересечения множеств. Если ты успешно записал данные на 2 из 3 узлов, а потом читаешь с 2 из 3, эти два множества гарантированно пересекутся как минимум на одном узле. А значит, ты обязательно зацепишь узел с самой свежей версией данных

Итог 🏁

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

🟡Нужна скорость? W=ONE, R=ONE
🟡Нужен баланс и надежность? W=QUORUM, R=QUORUM

Данный принцип используется во многих БД и системах (MongoDB, CockroachDB)

В следующий раз поговорим о том, что происходит, когда узел все-таки падает, и как Cassandra лечит сама себя с помощью Hinted Handoff и Read Repair

🔥 - если понял про устройство quorum

Одна из самых подлых ошибок в распределенных системах

Сегодня расскажу про один из самых подлых классов отказов в распределённых системах — metastable failures. Изначально кажется, что это редкое событие, но на самом деле систематичное и предсказуемое, если знать, на что смотреть


Что это? 🙋

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

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

Ключевой момент: это не обычный overload системы. Система может запросто работать при той же нагрузке в нормальных условиях.

Проблема в цикле ошибок, которые не дают системе выбраться.


Три фазы коллапса

1️⃣Stable — система работет стабильно. Какие-то сбои/ошибки не выводят систему
2️⃣Vulnerable — система работает эффективно, но есть явные риски, что может что-то пойти не так
3️⃣ Metastable — триггер кинул систему в цикл проблем, из которого она уже не вылезает сама


Классический пример: Retry storm

Система обрабатывает 280 RPS нормально. Клиенты при таймауте делают 2 retry.

Случается короткий сетевой сбой. Когда связь восстанавливается, все пакеты ретранслируются, нагрузка скачет до 560 RPS. БД начинает отвечать долго, запросы таймаутят... и вместо 280 RPS система получает 560+ RPS в виде волны retry

БД не может справиться, latency растёт, timeout timeout timeout — система заходит в цикл. Даже если сетевой сбой уже прошёл, система остаётся перегруженной потому что сама себе создаёт нагрузку

Клиенты получают только таймауты.


Другие примеры

🔵Cache cold start: теплый кэш даёт 90% hit rate, но если процесс крэшнулся и кэш потерян? Вдруг 10x нагрузка на БД → БД захлёбывается → кэш так и не заполняется. Тут стоит сказать, что базово решение "поставил кеш → спас БД от перегруза" - плохое. БД должна выдерживать нормальную нагрузку системы

🔵Slow error handling: когда система начинает падать, код начинает выполнять дорогие операции (stack traces, DNS lookups, логирование). Это требует ресурсов, которых уже не хватает → система падает быстрее → еще больше ошибок → еще больше ресурсов на обработку ошибок.


Почему это опасно?

🔵Не предсказать: проверяется только в production под высокой нагрузкой
🔵Не очевидна причина: в архитектуре не всегда понятно, какой узел вызвал проблему
🔵Каскадная: может распространяться через весь стек микросервисов


Как защищаться?

1️⃣Load shedding — отбрасывай лишние запросы, когда overload

2️⃣Adaptive retries — умные retry с token bucket

3️⃣Goodput monitoring — смотри на полезную работу, которую систему выполняет, а не только на сухой RPS

4️⃣Chaos engineering — специально убивай дата-центры, перезагружай кэши, создавай сетевые задержки. Если система не восстанавливается без вмешательства → metastable failure

🤝 Prioritization — важные запросы обслуживай первыми даже при overload системы

6️⃣Fast error paths — оптимизируй не только happy path, но и error handling (batch logging, sample stack traces)


TL;DR

Metastable failures — это когда система попадает в цикл проблем и долго выбирается/не выбирается сама. Триггер может быть маленький, а последствия — часовые сбои

Если раньше не знал о metastable failures и зашло, то ставь 👨‍💻

Ходи раз в год на собесы

Вчера проводил эфир “Самая важная секция в Big Tech”, где разбирали секцию про прошлый опыт и в целом как записывать свой опыт, как правильно делать задачи

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

Я сам недавно проходил собесы на Team Lead в один Big Tech РФ.

И это не так сложно, как кажется. Если ты идешь "в разведку"

1️⃣Можно не готовиться. Тебе не страшен провал. Ты скорее импромпту проходишь секции и смотришь на свой уровень

2️⃣Ты не тратишь много времени, так как не готовишься

3️⃣Да, после собеса ты чуток выжатый (вчера был собес, а потом через час открытый урок😑 ). Но в целом это терпимо

В конце 2024 я таким образом получил оффер от VK на 600к+ net совокупного. В 2025 от Авито. Сейчас еще один потенциальный оффер💸

Так что будь в рынке и делай "диагностику" своих знаний и опыта

В следующем посте расскажу основные моменты с вчерашнего открытого урока. Поставь 🔥и пост выйдет раньше 🙂

Самая важная секция в Big Tech

Именно под таким названием прошел открытый урок в этот вторник

Прошлый опыт и умение правильно его преподать является тем, что решает твой финальный грейд

🟣В каких-то компаниях это проходит в рамках финалов
🟣В Яндексе выделяется отдельная секция на 1/1.5 часа, где тебя расспрашивают в деталях
🟣В западных же компаниях есть behavioral interview

Короче, в любой компании тебя будут расспрашивать про это

Важный disclaimer 🏴‍☠️

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

Погнали по пунктам

1️⃣ На всех технических секциях смотрят на твою коммуникацию и насколько ты «слышишь» интервьюера.

Как реагируешь на подсказки, насколько ясно раскладываешь свое предполагаемо решение (а не кидаешься сразу делать)

2️⃣ Записывай свой опыт

🟣Блок в календаре каждые неделю/две, чтобы писать обновления по большим проектам или более мелкие штуки
🟣Для ситуаций можно использовать STAR алгоритм (situation, task, action, result). Это позволит подготовиться к вопросам по типу «Расскажи про ситуацию, где тебе нужно было проявить лидерство» и тд

3️⃣ Нужно правильно делать задачи. От этого будет зависеть, а сможешь ли ты вообще найти нормальную задачу из своего опыта

🟣 Не бросаться сразу кодить задачу
🟣 Анализ постановки задачи и желаемого решения
🟣 Проработка основных фичей и проведение расчетов. Смотрим, можем ли мы что-то переиспользовать внутри компании
🟣 Глубокая архитектура
🟣 Оценка и начало разработки

4️⃣ Краткий и универсальный алгоритм для подготовки рассказа про свой прошлый опыт

🟣 Кто инициировал задачу, в чем суть задачи и какие корректировки внес разработчик. Важно размышлять со стороны бизнеса и техники
🟣 Как проводил проработку и была ли возможность срезать скоуп задачи
🟣 Разработка: архитектура, узкие места системы, технологии и обоснование выбора
🟣 Тестирование и раскатка решения: кто проверял, как убеждались, что все окей
🟣 Сколько решение уже в проде и какие были сложности с ним
🟣 Рефлексия: чему научился, что не получалась на проекте

И есть ряд моментов, на которые смотрят в целом:
🟣 Контроль сроков
🟣 Конфликты и их решение (бизнес, продукт, разработка)
🟣 Лидерство
🟣 Качество продукта и контроль с помощью метрик


В итоге:
🟣Фиксируй опыт
🟣Рефлексируй (помогает понять, а норм ли задачи ты делаешь или стоит что-то менять в жизни)
🟣Делай задачи правильно
🟣Готовься к секции про прошлый опыт

Долгожданный эфир по секции с кодом!

Очень многие из вас ставили реакции и писали в личку, что хочется побольше узнать про секцию с кодом в Big Tech

Поэтому я решил повторно провести эфир🙋

Создал бота, в котором придет ссылка на эфир + подгон после эфира.

🔜Урок будет 21 декабря в 12:00 Мск

Подробности урока и вся инфа: Записаться на эфир

Сразу скажу, что готовьтесь к плотной подаче. Будет супер много инфы: от БД до архитектуры (да, на этой секции могут спросить буквально все)

Также поотвечаю на ваши вопросы

Хороших выходных❄️

PS: делитесь эфиром со своими товарищами

Big Tech сделает твое резюме конкурентным (или нет)?

Сегодня решил затронуть достаточно горячо обсуждаемую тему: идти ли в Big Tech

TL;DR правильного варианта нет 🙂

Меня очень часто спрашивают такого рода вопросы и я всегда отвечаю:

"Отталкивайся от своей долгосрочной цели"

✔️ Идти в случае

1️⃣Ты хочешь связать свою будущую карьеру с ИТ

2️⃣Ты хочешь перенять best practices (разработка, процессы, управление людьми) для своего проекта

3️⃣Ты хочешь быть конкурентным на рынке труда

4️⃣Ты хочешь поехать в западные компании (да и в целом за границу)

5️⃣Тебе важно, что твоя компания занимается каким-то существенным продуктом (не казик, only fans и тд. FYI не осуждаю, если человек работает в этих сферах)

6️⃣Получить network топовых инженеров, руководителей


👎 Не идти в случае

1️⃣Хочется иметь самые высокие вилки в моменте, а не на горизонте n лет

2️⃣Цель - заработать/отложить денег, но не строить долгосрочную карьеру

3️⃣Не смущают юр риски, которые часто бывают в более маленьких компаниях


В целом со всех сторон слышу, что в 2025 найм упал, все стало плохо и тд 😵

Лично я всегда хотел поработать в больших ИТ компаниях, чтобы перенимать опыт. И так получается, что сейчас в резюме есть Сбер, Т-Банк, Яндекс (а офера были чуть ли не в каждую большую компанию РФ)

Так вот, в рамках этого года ко мне приходили сами многие компании (большие и маленькие) и я получил несколько оферов с доходом 500k+ net. А большей части отказывал, так как их предложения были неконкурентные❌

И особенно на секциях с архитектурой и про прошлый опыт мне сильно помогал опыт работы в Big Tech

Вывод каждый сделает для себя сам. Мой же можно проследить в этом посте

Как большие системы могут сами себя чинить?

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

За этой магией стоят два механизма: Hinted Handoff и Read Repair

Проблема: узел-реплика недоступен

Представь, ты пишешь данные с W = QUORUM и RF = 3 (подробнее можешь прочитать в этом посте). Координатор должен записать данные на узлы A, B и C. Узел C молчит. Кворум (2 из 3) есть, твое приложение получает "ОК". Но что будет с данными для узла C?


🔖Hinted Handoff

Координатор видит, что узел C недоступен. Он создает "подсказку" (hint), содержащую данные для С, и сохраняет ее у себя. Как только узел C вернется в строй, координатор отправит ему все накопленные подсказки.

Важный нюанс: Это временная мера для краткосрочных отказов. По умолчанию подсказки хранятся 3 часа. Если узел лежит дольше, считается, что он выведен из строя надолго и его нужно чинить вручную.


🔖Read Repair: Лечение во время чтения

Данные на репликах все равно могут рассинхронизироваться. Read Repair чинит это прямо во время чтения

Как работает:

1. Ты делаешь запрос на чтение

2. Координатор запрашивает у реплик не сами данные, а их дайджест

Что за дайджест? Это просто хэш, короткий "отпечаток" данных. Сравнить два коротких хэша гораздо быстрее, чем гонять по сети полные данные

3. Если дайджесты совпадают — отлично, данные идентичны

4. А вот если дайджесты не совпадают, координатор понимает, что на репликах беспорядок. Тогда он запрашивает полные данные, но не со всех реплик, а только со всех N реплик, ответственных за этот ключ (в нашем примере — с узлов A, B и C)

5. Он сравнивает полученные версии и определяет самую свежую. Для этого он применяет правило Last Write Wins (LWW)

Что за LWW? Мы подробно разберем это в следующем посте, но если кратко: побеждает версия с самой свежей временной меткой (timestamp)

6. Эту свежую версию он возвращает тебе

7. И в фоновом режиме отправляет "лечащий" запрос на запись этой свежей версии на те реплики, где данные были устаревшими

Ключевая мысль: Каждое чтение в Cassandra — это потенциальная мини-операция по починке данных. Система постоянно лечит сама себя.

Итог

- Hinted Handoff помогает пережить краткосрочные отказы при записи
- Read Repair исправляет расхождения между репликами во время чтения

Вместе эти два механизма и обеспечивают ту самую Eventual Consistency. Данные могут на время разойтись, но в итоге они сойдуся к единой версии.


НО ты можешь спросить: "Если я использую R+W > N для строгой согласованности, отменяет ли это Hinted Handoff и Read Repair?"

Краткий ответ: Нет, не отменяет, а делает их работу еще важнее

- Настройка кворума (R+W > N) — это гарантия для тебя, что одна конкретная операция вернет самые свежие данные
- Eventual Consistency (и ее механизмы Hinted Handoff / Read Repair) — это гарантия для кластера, что в итоге все данные на всех репликах сойдутся к единой версии

Поэтому "строгая" операция чтения, обнаружив расхождение на репликах, как раз и становится триггером, который запускает Read Repair для лечения кластера в фоне

В следующий раз мы копнем в сердце механизма разрешения конфликтов — Last Write Wins (LWW) и выясним, почему для Cassandra так важна синхронизация времени

Если разобрался в механизме починки больший систем, то бахни 👍

Пример задачи на траблшутинг из желтого банка

Сегодня давай разберем реальную задачку с интервью

Приложение выкатывается в prod, но первые 5 минут видим в балансере ошибки tcp connection reset и no healthy backends. Потом всё магически стабилизируется. Как это решить?

У данной задачи есть 2 уровня решения


Первый уровень

В кластере настроена политика деплоя recreate

При стратегии Recreate:​
🟢Все старые поды убиваются сразу
🟢Новые создаются и поднимаются
🟢Приложению нужно время на прогрев (инициализация, подключение к БД)

За это время балансер шлёт в пустоту → ошибки

Решение:

Меняем стратегию на RollingUpdate. Пример конфигурации (также можно делать через % от общего кол-во подов):

spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 0  # Ноль подов недоступны
      maxSurge: 1   # На 1 под больше, чем replicas
  
  replicas: 3

Вместо full downtime старые поды работают, пока новые поднимаются

Второй уровень

Добавляем пробы: Startup → Readiness → Liveness

containers:
- name: app
  
  # 1️⃣ Startup — проверяем, поднялось ли приложение (долгая операция)
  startupProbe:
    httpGet:
      path: /health/startup
      port: 8080
    failureThreshold: 30      # 30 попыток = ~150 сек на прогрев
    periodSeconds: 5
  
  # 2️⃣ Readiness — готово ли обслуживать трафик
  readinessProbe:
    httpGet:
      path: /health/ready
      port: 8080
    initialDelaySeconds: 5
    periodSeconds: 10
  
  # 3️⃣ Liveness — живо ли приложение
  livenessProbe:
    httpGet:
      path: /health/live
      port: 8080
    initialDelaySeconds: 30
    periodSeconds: 10
    failureThreshold: 3

Как это работает:​

🟢Startup блокирует остальные пробы, пока app поднимается
🟢Readiness исключает под из балансера, пока он не готов
🟢Liveness выбивает под из балансировки и рестартит контейнер, если он зависнет


Таким образом мы гарантируем безопасную выкатку приложения и мониторим состояние нашего сервиса

Если зашла задачка и хочешь больше подобных разборов, то ставь 🔥

Эфир по паттернам надежности

Сегодня для ребят более 2-ух часов вещал про секцию с кодом в Big Tech. Разобрали траблшутинг, БД, задачку на написание load balancer и много других вещей. Короче теперь я уверен, что ребята больше готовы к своей секции💪


Во вторник проведу для вас второй урок. Всеобщим голосованием выбрали "Паттерны надежности"

Вся инфа об уроке здесь
⌛ Урок будет 23 декабря в 19:00 Мск

PS: если не будет работать переход с лендинга, то @reliability_patterns_bot

Как распределенные системы разрешают конфликты

В серии постов про Cassandra уже не раз упоминали правило Last Write Wins (LWW). Сегодня разберемся, что это такое, почему Cassandra выбрала именно его, и какая у этого выбора огромная цена 😳

Что такое LWW?

Представь, два пользователя одновременно редактируют один и тот же профиль:
🔵В 10:00:01 Маша меняет аватарку
🔵В 10:00:02 Вася (админ) меняет ее email

Оба запроса прилетают на разные узлы-координаторы и в итоге попадают на одни и те же реплики. Как системе понять, какая версия правильная? (Если не читал про координаторы в распределенных БД, то глянь пост)

LWW дает простой ответ: "Побеждает последняя запись". Cassandra просто смотрит на временную метку (timestamp), прикрепленную к каждой операции. Та, у которой timestamp больше, считается "победителем" и перезаписывает все остальные.

🔵Если у записи Васи timestamp больше, сохранится его email, а новая аватарка Маши будет потеряна
🔵Если у Маши — наоборот


Ловушка: что если часы врут? ⌛

У LWW, как и любого решения, есть trade-off. Cassandra слепо доверяет временным меткам

Представь, что и Маша, и Вася редактируют одно и то же поле — status в профиле пользователя

1️⃣Событие 1 (происходит позже в реальном времени):
🔵Реальное время: 10:00:02
🔵Сервер Маши (отстает): думает, что сейчас 10:00:00
Действие: Маша обновляет статус на "Working from home"
Результат: Запись отправляется в Cassandra с timestamp'ом 10:00:00

2️⃣Событие 2 (происходит раньше в реальном времени):
🔵Реальное время: 10:00:00
🔵Сервер Васи (спешит): думает, что сейчас 10:00:01
Действие: Вася обновляет тот же статус на "On vacation".
Результат: Запись отправляется в Cassandra с timestamp'ом 10:00:01.

Что видит Cassandra?
Она получает две конкурирующие записи для одной и той же ячейки (status):
🔵status = "On vacation", timestamp = 10:00:01
🔵status = "Working from home", timestamp = 10:00:00

Руководствуясь правилом LWW, она сравнивает timestamp'ы и видит, что 10:00:01 > 10:00:00.

💥Итог: Запись Васи ("On vacation") побеждает. Обновление Маши, которое в реальном мире произошло позже, будет безвозвратно потеряно, потому что ее сервер "жил в прошлом", и ее timestamp оказался меньше.
Вот это и есть классический пример "потерянного обновления" (lost update) из-за рассинхронизации времени.


NTP: не рекомендация, а требование

Для начала обязательно прочитай пост про NTP, чтобы вникнуть в детали подхода и что это такое

Для Cassandra работающий и настроенный NTP является жизненно важным требованием

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


А как же клиентские timestamp'ы? ⌚

Безусловно, драйверы Cassandra по умолчанию могут отправлять на сервер время с клиентской машины. Но это не решает проблему, а лишь переносит ее.

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

Итог 👍

Выбрав LWW, Cassandra сделала ставку на простоту и скорость. Вместо сложных векторных часов (как в оригинальном Dynamo), она использует простой, но требовательный механизм

Поэтому на уровне инфры должна быть идеальная синхронизация времени во всем кластере. Без этого вся распределенная магия Cassandra не имеет смысла

👍 - если до этого не знал про LWW и теперь разобрался