[{"data":1,"prerenderedAt":89},["ShallowReactive",2],{"content:\u002F09-redis\u002F00-intro":3},{"title":4,"description":5,"path":6,"body":7},"Введение в Redis","Этот модуль нужен, чтобы использовать Redis как инженерный инструмент, а не как универсальную кнопку \"сделать быстро\". Redis отлично подходит для горячих данных, TTL, счётчиков, rate limiting, простых очередей, pub\u002Fsub и некоторых координационных задач.","\u002F09-redis\u002F00-intro",{"type":8,"value":9,"toc":82},"minimark",[10,14,17,20,25,28,31,42,46,49,53,75,79],[11,12,4],"h1",{"id":13},"введение-в-redis",[15,16,5],"p",{},[15,18,19],{},"Но Redis не заменяет основную базу данных по умолчанию. Его сила в скорости и простых структурах в памяти, а слабые места появляются там, где нужны сложные запросы, строгая долговечность, большие объёмы данных или неаккуратная работа с ключами.",[21,22,24],"h2",{"id":23},"что-будет-внутри","Что будет внутри",[15,26,27],{},"Разберём модель in-memory хранилища, базовые структуры данных, команды, Go-клиент, кеширование, TTL, eviction, persistence, replication, cluster, locks, rate limits, streams и pub\u002Fsub.",[15,29,30],{},"В рабочей системе Redis чаще всего стоит рядом с основным хранилищем:",[32,33,39],"pre",{"className":34,"code":36,"language":37,"meta":38},[35],"language-text","Application -> Redis for hot\u002Ftemporary data\nApplication -> PostgreSQL for source of truth\n","text","",[40,41,36],"code",{"__ignoreMap":38},[21,43,45],{"id":44},"как-понять-что-освоил","Как понять, что освоил",[15,47,48],{},"Вы освоили модуль, если можете выбрать подходящую структуру данных, задать ключи и TTL, объяснить cache-aside, не сломать систему big keys, отличить Redis lock от транзакционной гарантии и понимать, что произойдёт при рестарте или вытеснении данных.",[21,50,52],{"id":51},"рабочие-ориентиры","Рабочие ориентиры",[54,55,56,60,63,66,69,72],"ul",{},[57,58,59],"li",{},"Redis ускоряет частые простые операции, но не отменяет проектирование основного хранилища.",[57,61,62],{},"TTL и invalidation важнее, чем сам факт кеширования. Устаревшие данные тоже баг.",[57,64,65],{},"Ключи, размеры значений и cardinality надо проектировать заранее. Иначе Redis быстро становится скрытой production-проблемой.",[57,67,68],{},"Для каждого сценария заранее выбирайте fail-open\u002Ffail-closed policy: кеш уроков может деградировать в PostgreSQL, а rate limit для login обычно безопаснее закрывать строже.",[57,70,71],{},"Observability нужна с первого дня: hit\u002Fmiss ratio, ошибки Redis, latency, eviction, memory и slowlog должны быть видны до инцидента.",[57,73,74],{},"Security не \"потом\": Redis не должен быть публичным, токены и сессии в нём требуют ACL\u002FTLS\u002Fbackup hygiene так же, как обычная база.",[21,76,78],{"id":77},"связь-с-ratedesk","Связь с RateDesk",[15,80,81],{},"В проекте RateDesk Redis появляется как адаптер к use case: кеш популярных курсов\u002Fконверсий, TTL, invalidation на обновлении курса и возможный rate limit для API. Теория в этом модуле объясняет, какие решения надо зафиксировать в cache contract, но сами issue, acceptance criteria и тесты живут в проектном треке.",{"title":38,"searchDepth":83,"depth":83,"links":84},2,[85,86,87,88],{"id":23,"depth":83,"text":24},{"id":44,"depth":83,"text":45},{"id":51,"depth":83,"text":52},{"id":77,"depth":83,"text":78},1781022064347]