System Design - Проектируем свой Redis

Redis кажется простой системой: положить значение по ключу и быстро его вернуть. Но когда нужно хранить 1 ТБ данных и обрабатывать 100 000 RPS,, обычная хэш-таблица превращается в сложную распределённую систему. Разбираем, как спроектировать собственный Redis: от Get, Set и TTL до шардирования, репликации и продакшн-оптимизаций. В этом видео: — Три функциональных требования: Get/Set/Delete, TTL и вытеснение по LRU — Как реализовать точный LRU через HashMap и двусвязный список — Почему настоящий Redis использует приближённый LRU вместо классического алгоритма — Почему шардироваться заставляет память, а не 100 000 RPS — Где хранить топологию кластера: умный клиент, прокси, редиректы или Gossip — Consistent Hashing против Hash Slots — Репликация, выбор нового мастера и компромисс между скоростью и консистентностью — Горячие ключи на чтение и запись: локальный кэш, реплики, батчинг и Write-Behind — Откуда берётся скорость Redis: Event Loop, атомарность, Pipelining и RESP — Что убивает latency: тяжёлые команды, большие ключи, синхронное удаление и фрагментация памяти ━━━ Таймкоды ━━━ 00:00 Введение 04:19 Реализуем Get, Set, Delete 05:42 Реализуем TTL 08:11 Реализуем LRU 12:07 Как LRU устроен в Redis 14:22 Масштабирование и шардирование 22:41 Распределение ключей по нодам 28:18 Отказоустойчивость и репликация 34:05 Горячие ключи 40:31 Оптимизация производительности 50:00 Заключение ━━━━━━━━━━━━ #systemdesign #highload #redis #backend #архитектура