Вопросы, которые задают в крупных компаниях: что происходит с сервисом под нагрузкой и почему. Каждая тема опирается на основы — очереди на законе Литтла, consistent hashing на хеш-таблице, LSM на сортировке слиянием. Очереди, балансировку, кольцо хешей, ограничители частоты, LRU и фильтр Блума можно покрутить руками.
Распределение задержек сильно скошено: большинство запросов быстрые, но есть длинный хвост. Среднее его прячет, а p95/p99 показывает, что видят самые невезучие пользователи.
Запросы приходят неравномерно, и при высокой загрузке они ждут в очереди. Время ожидания растёт как ρ / (1 − ρ): при 50% загрузки ожидание равно времени обработки, при 90% — в 9…
Round robin — по кругу, хорош при одинаковых серверах и запросах. Least connections / least requests — тому, у кого меньше активных, учитывает медленные запросы и серверы. Power…
Ключи и узлы хешируются на одно кольцо; ключ принадлежит первому узлу по часовой стрелке. При добавлении или удалении узла переезжает только ~1/N ключей, а не почти все, как при…
Token bucket — ведро на B жетонов пополняется со скоростью R; запрос забирает жетон, нет жетона — отказ. Допускает всплески до B, в среднем не больше R.
Backpressure — механизм, которым медленный потребитель заставляет источник замедлиться, вместо того чтобы копить работу без предела.
LRU выбрасывает то, к чему дольше всего не обращались. O(1) на операцию даёт пара хеш-таблица + двусвязный список: таблица находит узел, список хранит порядок использования.
Битовый массив и k хеш-функций. Добавление — выставить k бит; проверка — все k бит выставлены? Ответ «точно нет» или «возможно есть».
Масштабируется только параллельная часть работы. Закон Амдала: если 5% работы последовательны, ускорение не превысит 20× при любом числе узлов. А координация между узлами…
Модель «поток на соединение» упирается в память стеков и переключения. Решение — неблокирующие сокеты + epoll: один поток спрашивает ядро «какие из 100 000 сокетов готовы?» и…
Нагрузка на базу = поток × доля промахов. Рост hit ratio с 90% до 99% снижает нагрузку на базу в 10 раз. Обратная сторона: если база рассчитана только на промахи, падение кэша …
Установка соединения — TCP, TLS, аутентификация, а в PostgreSQL ещё и новый процесс: миллисекунды и память. Пул держит готовые соединения и ограничивает их число.
Лидером может стать только узел, за которого проголосовало большинство. Два большинства всегда пересекаются, поэтому в одном «сроке» (term) не бывает двух лидеров — это защищает…
Count-min sketch — таблица d × w счётчиков и d хеш-функций: при событии увеличиваем по одному счётчику в каждой строке, оценка частоты — минимум из d счётчиков. Только завышает, с…
Клиенты держат постоянное соединение (WebSocket) с шлюзами; сообщение пишется в хранилище, шардированное по chat_id, получает порядковый номер в чате и доставляется…
Состояние лимита — в общем быстром хранилище (Redis), проверка и списание — атомарно одним скриптом (Lua) или командой. Лимитер — в шлюзе или сайдкаре, до бизнес-логики.
Главный выбор — когда собирать ленту. Fan-out on write: при публикации положить id поста в ленты всех подписчиков — чтение мгновенное. Fan-out on read: собирать при открытии из…
Две дорожки: быстрая приближённая — потоковые агрегаторы считают топ по минутным окнам (count-min sketch + куча или Space-Saving) и сливают в топ за час; медленная точная …
Варианты: автоинкремент (просто, но одна точка и угадываемость), UUIDv4 (без координации, но случайный — плохо для B-дерева), UUIDv7 / Snowflake (время в старших битах — почти…
Чтений в 100 раз больше записей: редирект из кэша за миллисекунды, код — base62 от уникального числа (счётчик с выдачей диапазонов или Snowflake), хранилище key-value с…
Не делать UPDATE views = views + 1 на каждый просмотр: одна строка вирусного видео станет узким местом. События — в очередь, счётчики — агрегировать пачками в памяти и сбрасывать…
Активные проверки — балансировщик сам опрашивает /health; пассивные — следит за ошибками и задержками реальных запросов и выкидывает выбросы (outlier detection).
Горячий ключ не делится ни хешем, ни consistent hashing: все запросы к нему идут в один узел. Нужно размножить ключ для чтения или разбить его для записи.
Точный подсчёт требует хранить все уникальные id. HyperLogLog оценивает их число с ошибкой ~0,8%, используя 12 КБ на любое количество — от тысячи до миллиардов.
L4 видит только IP и порты и распределяет соединения: быстро, дёшево, не понимает содержимого. L7 разбирает HTTP и распределяет запросы: маршрутизация по пути и заголовкам, TLS…
При перегрузке лучше быстро отказать части запросов, чем медленно обслуживать все: иначе очереди растут, все запросы опаздывают, клиенты повторяют, и пропускная способность падает…
Команды Redis выполняются в одном потоке — одна медленная команда (KEYS, большой HGETALL, долгий Lua) задерживает всех. Отсюда главные правила: не трогать большие структуры…
Запись ушла в лидера, а чтение — на асинхронную реплику, которая ещё не догнала. Это нормальное поведение асинхронной репликации; приложение должно давать нужные гарантии само.
С одним лидером — все записи через лидера, реплики повторяют его журнал. С несколькими лидерами — запись в любом дата-центре, конфликты разрешаются потом. Без лидера — клиент…
Переносить данные по частям, пока система работает: копия + догоняющий поток изменений + переключение маршрутизации по одной части и проверка.
Шардирование делит данные между узлами по ключу шардирования. Ключ выбирают так, чтобы частые запросы шли в один шард, а нагрузка распределялась равномерно.
Синхронная — лидер подтверждает запись, когда реплика её сохранила: потерь при падении лидера нет, но задержка записи растёт, а отказ реплики может остановить запись. Асинхронная…
Хвосты неизбежны: сборка мусора, фоновые задачи, соседи по машине, переключения. При fan-out они становятся нормой. Главные приёмы — не ждать медленного: дублирующие запросы…
Таймаут у каждого сетевого вызова — по p99.9 зависимости, а не «по умолчанию». Повторы — только идемпотентных операций, с экспоненциальной отсрочкой и джиттером, ограниченным…
Обычная отдача файла: диск → page cache → буфер приложения → буфер сокета → сеть: 4 копирования и 4 переключения режима. sendfile передаёт данные из page cache в сокет внутри ядра…
sotto слышит вопрос и сразу показывает короткий ответ. Оставьте контакт — пришлём доступ и промокод.
sotto