Кэширование при масштабе: чтение кода и конфига

Практикуй цикл, что прогоняешь на ревью дизайна кэширования или инцидента: найди стратегию в коде, предскажи её поведение под конкурентностью и нагрузкой и выбери изменение, что механика реально поддерживает.

Сниппет 1 — порядок инвалидации

# чтение cache-aside + инвалидация «удаляй на записи»
def get_user(uid):
    u = cache.get(f"user:{uid}")
    if u is None:                       # промах
        u = db.read_user(uid)           # медленная загрузка ТЕКУЩЕГО значения
        cache.set(f"user:{uid}", u)     # заполнить (без TTL)
    return u

def update_user(uid, patch):
    db.write_user(uid, patch)           # новое значение в БД
    cache.delete(f"user:{uid}")         # инвалидировать

Сниппет 2 — математика hit ratio

def db_reads_per_sec(total_rps: float, hit_ratio: float) -> float:
    miss_rate = 1.0 - hit_ratio
    return total_rps * miss_rate

before = db_reads_per_sec(80_000, 0.99)   # ?
after  = db_reads_per_sec(80_000, 0.90)   # ?

Сниппет 3 — конфиг кэша Redis

# инстанс redis, используемый чисто как кэш
maxmemory 16gb
maxmemory-policy noeviction        # оставлен дефолт
# приложение делает SET ... EX 600 для каждого ключа

Сниппет 4 — путь чтения горячего ключа

# страница товара вирусного айтема, пересчёт ~300мс
def get_page(pid):
    html = cache.get(f"page:{pid}")
    if html is None:                    # промах
        html = render_page(pid)         # дорого: 6 запросов + рендер
        cache.set(f"page:{pid}", html, ex=30)
    return html
# на пике ~40 000 параллельных запросов на ОДИН pid