> Какие стратегии масштабирования кэша существуют (Go)

В Go масштабирование кэша обычно решается через несколько стратегий, каждая со своими компромиссами.

1. Горизонтальное масштабирование (шардирование)
Кэш разбивается на несколько независимых узлов (например, Redis кластер). Ключи распределяются по шардам через консистентное хеширование (consistent hashing). В Go популярна библиотека hashicorp/memberlist для динамического управления узлами. Плюс: линейное увеличение ёмкости. Минус: сложность ребалансировки при добавлении/удалении узлов.

2. Репликация (read replicas)
Один мастер для записи, несколько реплик для чтения. В Go можно использовать go-redis/redis с настройкой ReadOnly и RouteByLatency. Подходит для read-heavy нагрузок, но требует решения проблемы согласованности (например, eventual consistency).

3. Многоуровневый кэш (L1/L2)
L1 - in-memory кэш (например, hashicorp/golang-lru), L2 - Redis/Memcached. В Go часто реализуют через паттерн "cache-aside": сначала проверка L1, при промахе - L2, затем запись в L1. Снижает задержки, но увеличивает сложность инвалидации.

4. Кэш с истечением (TTL-based)
Простая стратегия: каждый ключ имеет время жизни. В Go удобно использовать sync.Map с фоновым горутиной для очистки (через time.Ticker). Не требует координации, но возможны "горячие" ключи.

5. Write-through / Write-behind
При записи в БД синхронно (write-through) или асинхронно (write-behind) обновляется кэш. В Go для write-behind часто применяют буферизированные каналы и паттерн worker pool.

Выбор стратегии зависит от профиля нагрузки: для read-heavy - репликация + L1, для write-heavy - шардирование с write-through. В Go важно избегать блокировок (использовать sync.RWMutex или lock-free структуры) и учитывать GC давление при больших объёмах in-memory кэша.