TTL

TTL (time to live) задаёт срок жизни ключей — Redis удаляет их лениво при доступе и активно через периодическую выборку. TTL обеспечивает исчезновение кэшей, сессий, OTP, bucket rate limit и privacy-sensitive данных.

					SET cache:item:9 "..." EX 300        # истекает через 300 секунд
SETEX session:tok 3600 "..."
TTL cache:item:9                     # остаток; -1 без expire; -2 нет ключа
EXPIRE dedup:evt:991 86400
PERSIST cache:item:9                 # снять TTL — осознанно
				

| Выбор политики | Почему важно | |----------------|--------------| | Фиксированный TTL | Предсказуемая граница staleness | | Jitter TTL | Размазывает expire — меньше stampede | | Per-key vs global | Сессии vs правила namespace кэша | | Без TTL | Только для durable сценариев Redis |

Истечение не миллисекундно точное — закладывайте слегка устаревшие reads и задержку cleanup. Sliding expiration (`EXPIRE` при каждом доступе) для активности сессии; фиксированный TTL — для неизменяемых cache entries.

На интервью: свяжите TTL со SLA свежести, безопасностью и риском thundering herd.

Типовые ошибки: одинаковый TTL у миллионов ключей с одновременным expire; TTL как строгий deadline; нет TTL на PII; забытые правила обновления TTL при частичных updates.

Компромисс — автоматический cleanup и ограниченная staleness vs предсказуемость miss: TTL упрощает эксплуатацию, но для correctness-sensitive кэшей нужны jitter и стратегия invalidation.

Чеклист:

• Сформулируйте SLA свежести по классу ключей.
• Добавьте jitter к популярным TTL.
• Зафиксируйте refresh vs fixed expiration.
• Обрабатывайте cache miss после expiry в коде приложения.