• Оглавление
  • Зачем бизнесу кэш и когда он вредит
  • Что кэшировать: отбор кандидатов и анти-примеры
  • Паттерны кэширования и когда их применять
  • Согласованность и инвалидация: TTL, версии и события
  • Защита от «набега» (cache stampede)
  • Горячие ключи, шардирование и отрицательное кэширование
  • Практика: кэш карточки товара на Redis c мягким TTL, блокировкой и инвалидацией
  • Событийная инвалидация через outbox в PostgreSQL
  • Метрики и алерты, которые экономят деньги
  • Безопасность: PII, доступы и разделение сред
  • Экономический эффект и чек‑лист внедрения

Зачем бизнесу кэш и когда он вредит

Кэш дает два прямых эффекта: быстрее ответ пользователю и меньше нагрузка на базу и внешние интеграции. Это превращается в рост конверсии, экономию на инфраструктуре и запас производительности для пиков.

Но кэш легко превращается в мину: устаревшие цены, неактуальные остатки, неверные статусы заказов. Ошибочная инвалидация в итоге бьет по SLA и деньгам. Цель статьи — показать, как строить кэш «без сюрпризов»: с предсказуемой согласованностью, контролируемой свежестью и измеримой пользой.

Что кэшировать: отбор кандидатов и анти-примеры

Кандидаты на кэш:

• Часто читаются и редко меняются: карточки товаров, справочники, настройки тарифов, публичные профили, агрегированные витрины.
• Дорого получать: тяжелые запросы к БД, данные из медленных интеграций, вычисления.
• Нужны многим пользователям и повторяются.

Лучше не кэшировать бездумно:

• Персональные и чувствительные данные (PII): нужно шифрование и строгие TTL.
• Данные, что меняются «по щелчку» и критичны к актуальности (баланс, остатки в момент покупки) — кэш допустим только с четкой инвалидацией или как подсказка интерфейсу.
• Жестко транзакционные вещи (движение денег). Кэш — лишь слой для чтения, не источник истины.

Правило отбора: ценность кэша = (частота чтений × стоимость запроса) − (риск устаревших данных × стоимость ошибки). Если ценность положительна — кэшируем, но спроектировав инвалидацию.

Паттерны кэширования и когда их применять

• Cache-aside (ленивый): приложение сначала читает кэш, при промахе — источник, затем кладет в кэш. Плюсы: простой, гибкий. Минусы: возможен «набег» на промахах.
• Write-through: запись идет в источник и кэш одновременно. Плюсы: меньше промахов после записи. Минусы: больше задержки на запись.
• Write-behind (отложенная запись): приложение пишет в кэш, а фон обновляет источник. Рисковый вариант: потеря данных при сбое, нужен журнал.
• Read-through: библиотека/прокси сама ходит в источник при промахе. Удобно, но снижает контроль.
• Локальный кэш процесса (LRU) + распределенный кэш (Redis): сначала быстрый локальный, затем общий. Экономит сеть, но требует инвалидации в нескольких слоях.

Выбор: для большинства B2C-витрин — cache-aside + write-through на критичных апдейтах (удаление/обновление ключа) и событийнaя инвалидация.

Согласованность и инвалидация: TTL, версии и события

Способы держать кэш в актуальном состоянии:

• Время жизни (TTL): просто и дешево. Подходит для данных с допустимым устареванием (например, 30–60 секунд). Минус — нет мгновенного обновления.
• Явная инвалидация по ключу: после изменения — удалить или обновить соответствующий ключ. Важно: делать это атомарно с записью в базу через outbox/транзакцию.
• Версионирование ключей: добавляем «версию» в ключ (например, product:42
  ). Меняем версию — старые ключи естественно протухают. Можно хранить версию в самой записи или в отдельном «пространстве имен» (namespace).
• Инвалидация по событиям: после апдейта пишем событие (outbox), воркер удаляет/обновляет ключи в кэше. Это надежнее, чем надеяться на «успел удалить».

Комбинируйте: явная инвалидация + короткий TTL как страховка.

Защита от «набега» (cache stampede)

Когда популярный ключ протухает, сотни запросов одновременно идут в базу. Что помогает:

• Мягкий TTL (soft TTL): храним в значении «свежо до» и «жесткий срок». По мягкому истечению возвращаем устаревшее, а обновление запускаем в фоне.
• Схлопывание запросов (single flight): только один поток грузит данные, остальные ждут его результат.
• Блокировка per-key: получаем короткую блокировку на ключ (например, Redis SET NX с истечением), чтобы единственный воркер делал обновление.

Горячие ключи, шардирование и отрицательное кэширование

• Горячие ключи (очень частые чтения): используйте реплики Redis для чтения, настройте шардирование (Redis Cluster) или клиентские хэш-слоты. Убедитесь, что ключи равномерно распределяются.
• Сжатие больших объектов: экономит память и сеть, но повышает задержку сериализации. Балансируйте.
• Отрицательное кэширование (отсутствие данных): на короткий TTL кэшируйте «пусто», чтобы не бить базу повторно.

Практика: кэш карточки товара на Redis c мягким TTL, блокировкой и инвалидацией

Ниже — минимальный рабочий пример на Go: cache-aside + мягкий TTL + схлопывание запросов и блокировка, плюс явная инвалидация при изменении товара.

package main

import (
	"context"
	"encoding/json"
	"errors"
	"fmt"
	"log"
	"time"

	"github.com/redis/go-redis/v9"
	"golang.org/x/sync/singleflight"
)

type Product struct {
	ID        int64     `json:"id"`
	Name      string    `json:"name"`
	PriceCents int64    `json:"price_cents"`
	UpdatedAt time.Time `json:"updated_at"`
}

type cachedProduct struct {
	Data      Product   `json:"data"`
	SoftUntil time.Time `json:"soft_until"` // после этого можно отдать устаревшее и обновить в фоне
}

var (
	rdb = redis.NewClient(&redis.Options{Addr: "127.0.0.1:6379"})
	sf  singleflight.Group
)

const (
	softTTL = 30 * time.Second
	hardTTL = 5 * time.Minute
	lockTTL = 10 * time.Second
)

func cacheKey(id int64) string { return fmt.Sprintf("product:%d", id) }
func lockKey(id int64) string  { return fmt.Sprintf("lock:product:%d", id) }

// Заглушка: вместо этого используйте реальную БД
func loadFromDB(ctx context.Context, id int64) (Product, error) {
	// Имитируем чтение из источника
	return Product{ID: id, Name: fmt.Sprintf("Товар #%d", id), PriceCents: 12345, UpdatedAt: time.Now()}, nil
}

func saveToCache(ctx context.Context, key string, p Product) error {
	val, _ := json.Marshal(cachedProduct{Data: p, SoftUntil: time.Now().Add(softTTL)})
	return rdb.Set(ctx, key, val, hardTTL).Err()
}

func tryLock(ctx context.Context, key string) (bool, error) {
	return rdb.SetNX(ctx, key, "1", lockTTL).Result()
}

func getProduct(ctx context.Context, id int64) (Product, error) {
	key := cacheKey(id)
	// Сначала пробуем из кэша
	bs, err := rdb.Get(ctx, key).Bytes()
	if err == nil {
		var c cachedProduct
		if jsonErr := json.Unmarshal(bs, &c); jsonErr == nil {
			// Свежо
			if time.Now().Before(c.SoftUntil) {
				return c.Data, nil
			}
			// Мягко протухло: отдаем устаревшее, обновляем в фоне
			go refreshProduct(context.Background(), id)
			return c.Data, nil
		}
	}

	// Промах: схлопываем запросы, чтобы только один ходил в источник
	v, err, _ := sf.Do(key, func() (interface{}, error) {
		p, e := loadFromDB(ctx, id)
		if e != nil {
			return nil, e
		}
		_ = saveToCache(ctx, key, p)
		return p, nil
	})
	if err != nil {
		return Product{}, err
	}
	return v.(Product), nil
}

func refreshProduct(ctx context.Context, id int64) {
	lk := lockKey(id)
	ok, err := tryLock(ctx, lk)
	if err != nil || !ok {
		return // кто-то уже обновляет
	}
	defer func() { _ = rdb.Del(ctx, lk).Err() }()

	p, err := loadFromDB(ctx, id)
	if err == nil {
		_ = saveToCache(ctx, cacheKey(id), p)
	}
}

// Явная инвалидация при изменении товара
func invalidateProduct(ctx context.Context, id int64) error {
	return rdb.Del(ctx, cacheKey(id)).Err()
}

func main() {
	ctx := context.Background()
	p, err := getProduct(ctx, 42)
	if err != nil {
		log.Fatal(err)
	}
	log.Printf("Первый ответ: %+v", p)

	// Обновление товара в источнике -> инвалидация кэша
	if err := invalidateProduct(ctx, 42); err != nil {
		log.Println("не смогли удалить ключ:", err)
	}

	p2, _ := getProduct(ctx, 42)
	log.Printf("После инвалидации: %+v", p2)
}

Пояснения к примеру:

• Мягкий TTL дает стабильные ответы на пиках и защищает базу.
• Блокировка на ключ не дает десяткам воркеров одновременно перезаписывать кэш.
• Явная инвалидация вызывается после успешного апдейта в источнике (в бою лучше через outbox, см. ниже).

Событийная инвалидация через outbox в PostgreSQL

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

SQL-схема и триггер:

-- Таблица товаров (упрощенная)
CREATE TABLE IF NOT EXISTS products (
  id BIGSERIAL PRIMARY KEY,
  name TEXT NOT NULL,
  price_cents BIGINT NOT NULL,
  updated_at TIMESTAMPTZ NOT NULL DEFAULT now()
);

-- Outbox для инвалидации кэша
CREATE TABLE IF NOT EXISTS cache_outbox (
  id BIGSERIAL PRIMARY KEY,
  key TEXT NOT NULL,
  created_at TIMESTAMPTZ NOT NULL DEFAULT now(),
  processed_at TIMESTAMPTZ
);

-- Функция создает запись в outbox после апдейта товара
CREATE OR REPLACE FUNCTION notify_cache_invalidation() RETURNS trigger AS $$
BEGIN
  INSERT INTO cache_outbox(key) VALUES (concat('product:', NEW.id));
  RETURN NEW;
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER products_cache_invalidate
AFTER UPDATE ON products
FOR EACH ROW EXECUTE FUNCTION notify_cache_invalidation();

Простой воркер на Go, который обрабатывает outbox и удаляет ключи в Redis. Используем «выборку с блокировкой» (SKIP LOCKED), чтобы можно было запустить несколько воркеров параллельно.

package main

import (
	"context"
	"database/sql"
	"log"
	"time"

	_ "github.com/jackc/pgx/v5/stdlib"
	"github.com/redis/go-redis/v9"
)

type OutboxEvent struct {
	ID  int64
	Key string
}

func runOutboxWorker(ctx context.Context, db *sql.DB, rdb *redis.Client) {
	for {
		select {
		case <-ctx.Done():
			return
		default:
		}

		tx, err := db.BeginTx(ctx, &sql.TxOptions{})
		if err != nil { time.Sleep(time.Second); continue }

		rows, err := tx.QueryContext(ctx, `
			SELECT id, key FROM cache_outbox
			WHERE processed_at IS NULL
			ORDER BY id
			FOR UPDATE SKIP LOCKED LIMIT 100`)
		if err != nil { _ = tx.Rollback(); time.Sleep(time.Second); continue }

		var events []OutboxEvent
		for rows.Next() {
			var e OutboxEvent
			if err := rows.Scan(&e.ID, &e.Key); err == nil {
				events = append(events, e)
			}
		}
		_ = rows.Close()

		if len(events) == 0 {
			_ = tx.Commit()
			time.Sleep(500 * time.Millisecond)
			continue
		}

		for _, e := range events {
			if err := rdb.Del(ctx, e.Key).Err(); err != nil {
				log.Println("DEL failed:", e.Key, err)
				continue
			}
			_, _ = tx.ExecContext(ctx, `UPDATE cache_outbox SET processed_at = now() WHERE id = $1`, e.ID)
		}
		_ = tx.Commit()
	}
}

Такой подход избавляет от гонок «сначала изменили базу — забыли удалить ключ», а также переживет кратковременные падения Redis или приложения.

Метрики и алерты, которые экономят деньги

Отслеживайте ежедневно:

• Доля попаданий (hit ratio) по ключевым пространствам: общее и по эндпоинтам. Нормально видеть 70–95% на витринах.
• Запросы к источнику на промахах: тренды и пики — сигнал о «набеге» или неверном TTL.
• Доля устаревших ответов (отдано после soft TTL): если растет — увеличьте запас обновляющих воркеров или оптимизируйте источник.
• Ошибки сериализации/размера: «значение слишком велико», «таймаут Redis» — важные алерты.
• Время сетевого запроса до кэша и до БД — сравнивайте с TTFB у пользователя.
• Память кэша: заполнение, количество выселений, фрагментация. При превышении порога — пересчет TTL/размеров/шардирование.

Безопасность: PII, доступы и разделение сред

• Не кладите в кэш «сырые» персональные данные без шифрования и коротких TTL. Предпочтительнее кэшировать обезличенные агрегаты.
• Разделяйте кластеры для прод/стейдж, ограничивайте сетевой доступ по спискам разрешений.
• Не используйте шаблонные префиксы, включающие токены/секреты.
• Для мультисервисных систем — отдельные пространства имен (namespace) на сервис/тип данных.

Экономический эффект и чек‑лист внедрения

Эффект: снижение нагрузки на базу в 2–10 раз на горячих эндпоинтах, ускорение ответа в 3–20 раз, рост конверсии за счет скорости, меньше аварий на распродажах за счет защиты от «набегов».

Чек‑лист:

1. Выберите кандидатов (часто читаемые, редко меняемые, дорогие операции). Посчитайте экономику.
2. Решите модель: cache-aside + мягкий TTL по умолчанию. Для критичных апдейтов — явная инвалидация.
3. Введите версионирование ключей или outbox-инвалидацию на изменениях.
4. Защитите от «набега»: схлопывание запросов, короткая блокировка per-key.
5. Настройте метрики: hit ratio, промахи, доля устаревших ответов, задержки, память.
6. Прогоните нагрузочное тестирование и пик отложенной инвалидации.
7. Документируйте правила: «кто» и «когда» инвалидацию вызывает, форматы ключей, TTL, безопасность.

Итог: кэш — это не просто «положили в Redis», а инженерная система со своими гарантиями. Если продумать инвалидацию, согласованность и метрики, вы получите быстрый, предсказуемый и дешевый в эксплуатации слой, который работает в плюс бизнесу, а не создает скрытые риски.