Hot keys, hotspots и skew¶

Тип материала: архитектурный разбор. Схемы и примеры иллюстративные, если не указано иное.

Версии в источниках: PostgreSQL 17, MySQL 8.4, Oracle 19c, Cassandra 5.0, Redis 7.4 и ClickHouse 25.8 либо явно названный сервис.

Механизм¶

Skew — неравномерная нагрузка или объём, hotspot — перегруженный resource, hot key — частный случай. Средний load по cluster скрывает перегруженный shard/core/partition. Token hashing распределяет key space, но не делит одну горячую логическую сущность.

flowchart LR
  Events --> Key[Stable key and layout version]
  Key --> S1[Bucket shard 1]
  Key --> S2[Bucket shard 2]
  Key --> S3[Bucket shard 3]
  S1 --> Merge[Bounded fan-out read]
  S2 --> Merge
  S3 --> Merge

Операция чтения или записи по шагам¶

Крупный bookmaker/tenant генерирует большую долю events. PK=(tenant,day) отправляет активные writes в одну partition, даже при равномерных hashes других tenants. Добавление shard=stable_hash(event_id)%N распределяет writes; range read теперь делает N queries и merge.

Консистентность, отказ и восстановление¶

Изменение N без versioned routing теряет адрес старых событий; migration должна хранить layout version или читать обе generations. Salting balance key не делает денежный инвариант независимым: global limit требует aggregation/coordination. Redis ZSET одного player остаётся на одном primary.

Выбор, эксплуатация и ограничения¶

Снижать contention можно batching, hierarchical counters, cache или splitting по независимому business key; точность и latency меняются. Сначала измерять max/percentile per-key/per-partition load, bytes, queue и cache residency, а не только общий requests/sec.

Типичные ошибки проектирования¶

Случайный shard на каждом retry создаёт дубли/непредсказуемый lookup. Вопрос: hash key решает celebrity problem? Нет, один key получает один hash; нужен новый model с fan-out или координацией.

Вопросы на собеседовании¶

Как доказать применимость механизма? Назвать invariant, scope, isolation/acknowledgement boundary, версию, допустимые interleavings и процедуру восстановления. Один успешный запрос или статическая диаграмма этого не доказывают.

Практические упражнения¶

Возьмите произвольное, явно учебное распределение tenant traffic, вычислите max partition load для двух layouts. Опишите stable hashing algorithm, versioning и migration reads.

Дополнительные источники¶

Политика версий и проверки. Статическая проверка статьи не является runtime/fault verification механизма.