Синтез по всему юниту распределения данных в формате выбора: лаг репликации и потерянные записи, стратегии партиционирования и горячий шард, consistent hashing против mod-N и выбор CAP/PACELC по кейсу.
SDSenior◷ 13 min
Уровень
ОсновыJuniorMiddleSenior
Шесть вопросов поперёк всего юнита. Каждый — решение, что ты принимаешь, выбирая режим репликации, ключ партиционирования, маршрутизацию ключей к узлам или метку консистентности хранилища — не определение для зубрёжки, а компромисс, на который senior-инженер идёт при реальном отказе.
Подтверди, что умеешь проследить потерянную запись сквозь async-failover, диагностировать горячий шард по ключу партиционирования, выбрать consistent hashing вместо mod-N, посчитать пересечение кворума и поместить нагрузку на спектр консистентности с прямым пониманием CAP и PACELC.
Викторина
Completed
Async-реплицируемая база подтверждает записи #51–53 клиентам, затем лидер падает, отправив лишь до #50. Повышается фолловер на #50. Какое описание верно?
Heads-up Клиенты не держат переигрываемый лог подтверждённых записей, и база их об этом не просила. Записи были лишь на мёртвом лидере и пропали. Долговечность нужна синхронная реплика, а не переигрыш клиента.
Heads-up Это ловушка: при async-репликации ack отправлен до того, как запись долговечна где-либо кроме лидера. Сбой в этом окне тихо теряет подтверждённые записи.
Heads-up Eventual-консистентность — про сходимость чтений, а не про восстановление записей, которые никогда не реплицировались. У #51–53 нет копии для сходимости; они потеряны.
Викторина
Completed
Ты шардируешь пользователей по user_id, ровно по числу. Один шард встаёт на 100% CPU, пока остальные дремлют, сразу после того, как аккаунт знаменитости стал вирусным. Что происходит и чистейшая мера?
Heads-up Числа уже ровны — проблема в НАГРУЗКЕ, сконцентрированной на одном горячем ключе, а не в распределении строк. Ребаланс чисел не уберёт трафик знаменитости с её шарда.
Heads-up Это проблема нагрузки горячего ключа на одном шарде, а не репликация. Больше фолловеров масштабируют чтения широко, но не облегчают единственный ключ, чей трафик весь идёт на один шард.
Heads-up Range не помог бы — единственный ключ знаменитости всё равно ложится на один шард независимо от схемы. Надо размазать именно этот ключ: разбить, закешировать или изолировать.
Викторина
Completed
Флот кеша Redis маршрутизирует ключи через hash(key) mod N. Добавление одного узла (N: 16 → 17) рушит hit rate почти до нуля. Какая починка и почему она работает?
Heads-up При mod-N смена делителя переотображает ПОЧТИ ВСЕ ключи, так что промахивается по сути каждый запрос — не лишь доля нового узла. Прогрев одного узла не починит переотображение всего флота; consistent hashing предотвращает его.
Heads-up Реплики не меняют функцию маршрутизации; крах — от mod-N, переотображающего каждый ключ при смене N. Структурная починка — consistent hashing, развязывающий маршрутизацию и N.
Heads-up Длинные TTL не помогут, когда каждый ключ теперь хешируется на неправильный узел — записи есть, но их ищут на неправильном узле. Consistent hashing держит ключи на их узле при смене членства.
Викторина
Completed
В leaderless-хранилище N = 5 реплик. Ты хочешь, чтобы чтение гарантированно видело последнюю подтверждённую запись. Какая пара (W, R) даёт это с наибольшей доступностью записи?
Heads-up R + W = 2 не > N = 5, так что множества чтения и записи могут не пересекаться — чтение может вовсе упустить последнюю запись. Гарантия пересечения требует R + W > N.
Heads-up R + W = 10 > 5 гарантирует пересечение, но W = 5 требует каждую реплику на запись — наименьшая доступность записи, обратное цели. W = 3, R = 3 тоже пересекается с большим запасом записи.
Heads-up R + W = 4 не > 5, так что множества могут не пересечься и чтение может упустить последнюю запись. Нужна сумма строго больше N; минимум здесь 6, например W = 3, R = 3.
Викторина
Completed
Коллега говорит «мы на Cassandra, значит мы AP — отдали консистентность». Используя CAP и PACELC точно, какая поправка точнее всего?
Heads-up Cassandra предлагает настраиваемую консистентность (уровни кворума на запрос); это не «нет консистентности». И AP — лишь стойка во время партиции, а повседневный компромисс — задержка против консистентности (else PACELC), что утверждение упускает.
Heads-up Cassandra склоняется к AP при партиции (остаётся доступной, отдавая возможно устаревшие чтения). Поправка не в смене буквы, а в том, что AP описывает лишь случай партиции, а EL PACELC описывает остальное.
Heads-up Нет: CAP покрывает лишь выбор C-против-A во время партиции; PACELC добавляет ветвь «иначе» (задержка против консистентности в норме), что и игнорирует утверждение коллеги.
Викторина
Completed
Ты выбираешь уровень консистентности на тип данных для одного продукта. Какое назначение отражает принцип юнита «выбирай по кейсу»?
Heads-up Требовать линеаризуемость на счётчике лайков или ленте — купить задержку и сниженную доступность CP/EC для данных, которым она не нужна, делая весь продукт медленнее и хрупче при партиции без выгоды.
Heads-up Гонять баланс или склад на eventual-консистентном хранилище приглашает двойные списания и перепродажи при партиции. Деньги и склад нужны линеаризуемость; лишь данные низкой ставки должны быть eventual.
Heads-up Read-your-writes — гарантия на клиента, слишком слабая для баланса (нужна глобальная линеаризуемость) и избыточная для публичного счётчика лайков (eventual достаточно). Один уровень на всё — ошибка.
Вспомните перед уходом
01
Почему async-реплицируемый failover теряет подтверждённые записи и что это предотвращает?
02
Дай минимальный кворум для гарантированно свежего чтения при N = 5 и наибольшей доступности записи.
Итог
Сквозная мысль — распределять данные значит серией решений выбирать, какое расхождение терпеть. Репликация копирует данные ради чтений и выживания, но async-репликация подтверждает до долговечности, так что failover может потерять подтверждённые записи — держи синхронную реплику. Шардинг дробит данные по ключу, и ровное число ключей всё равно даёт горячий шард при перекосе (знаменитость), что чинится разбивкой, кешированием или изоляцией горячего ключа. Consistent hashing маршрутизирует ключи по кольцу, так что добавление узла двигает лишь ~1/N, тогда как hash mod N переотобразил бы почти все и снёс бы кеш. Leaderless-кворум гарантирует свежее чтение, когда R + W > N (множества чтения и записи пересекаются). А CAP — лишь выбор C-против-A во время партиции, тогда как PACELC добавляет повседневный компромисс задержка-против-консистентности — так что выбирай по кейсу: линеаризуемая для денег и склада, eventual для счётчиков лайков и лент, read-your-writes для собственных правок пользователя.
Что-то непонятно?
Задай вопрос по этому уроку. Вопросы анонимны и попадают напрямую автору — урок станет лучше.