Кратко и по делу — принципы, сравнение стратегий и влияние на согласованность.
1) Принципы кэширования — общие положения
- Цель: уменьшить задержку чтения/записи и нагрузку на медленные хранилища за счёт хранения часто используемых данных ближе к клиенту/процессу.
- Метрики: коэффициент попаданий (hit rate) $h=\frac{\text{hits}}{\text{accesses}}$, пропускная способность и средняя задержка доступа (эффективное время доступа)
$$EAT=h\cdot T_c+(1-h)\cdot T_m,$$ где $T_c$ — время обращения к кэшу, $T_m$ — время обращения к основному хранилищу.
- Политики вытеснения: LRU, LFU, FIFO и др.
- Стратегии наполнения/обновления: cache-aside, read-through, write-through, write-back (write-behind).
2) Кэширование в базе данных vs на уровне приложений — отличия
- В базе данных (встроенный буфер-кэш, buffer pool):
- Управляет страницами/страктурами хранения; интегрирован с транзакциями и журналированием (WAL), часто поддерживает атомарность/изолированность.
- Сильнее согласованность внутри одного экземпляра СУБД (благодаря блокировкам, MVCC, журналу).
- Эффективен для произвольных запросов и последовательного доступа к страницам.
- На уровне приложения (external cache: Redis, Memcached, CDN, локальный in-process cache):
- Гибче, ближе к клиенту, уменьшает сетевую задержку; обычно кеширует результат запросов, объектов или представлений.
- Отдельно от транзакционной логики СУБД — риск рассинхронизации выше.
- Часто используется шаблон cache-aside (приложение сначала обращается в кэш, при промахе — в БД и записывает в кэш).
3) Write-through vs write-back — сравнение
- Write-through:
- При записи данные записываются одновременно в кэш и в основное хранилище.
- Плюсы: высокая устойчивость (меньший риск потери данных), простая согласованность (кэш и хранилище синхронны).
- Минусы: более высокая задержка записи (запись ждёт основной БД), меньшая пропускная способность при интенсивных записях.
- Write-back (write-behind):
- Запись обновляет только кэш; основной диск/БД обновляется позднее (по эвикции или периодической синхронизации).
- Плюсы: низкая латентность записи, высокая пропускная способность.
- Минусы: риск потери данных при сбое до записи в основное хранилище; сложная логика согласования и конфликтов при распределённых кэшах.
- Формализуя задержку записи (упрощённо): средняя задержка записи
$$T_{wt}\approx T_m\text{(write-through)},T_{wb}\approx T_c\text{(write-back)},$$ где $T_c\ll T_m$. Но у write-back есть дополнительный амортизированный фоновый трафик и риск потерь.
4) Как кэширование ухудшает согласованность в распределённой системе
- Источник проблем: кэш и основное хранилище — разные копии данных; между ними есть задержки и несинхронность.
- Основные механизмы нарушения согласованности:
- Окно устаревания (staleness window): после обновления в одной копии другие кэши могут видеть старое значение в течение времени распространения/TTL. Оценка вероятности устаревания при интенсивности обновлений $\lambda$ и TTL:
$$P_{\text{stale}}=1-e^{-\lambda \cdot TTL}.$$ - Расхождение из-за асинхронной записи (write-back): данные в кэше изменены, но ещё не записаны в основной хранилище → другие читатели получают устаревшие данные.
- Гонки (race conditions): два клиента одновременно читают/пишут, кэш обновляется/инвалидация происходит в разное время → потерянные обновления или некогерентные последовательности.
- Неправильная инвалидация: потеря/запаздывание сообщений об инвалидации в распределённом кэше (например, при использовании pub/sub), что создаёт "разрозненные" кэш-копии.
- Cache stampede и thundering herd: при истечении TTL одновременно многие клиенты обращаются к БД, возможно приводя к временной недоступности или конкурирующим записям.
- Примеры последствий: читатель видит старую цену товара; счётчик инвентаря уходит в отрицательное значение из-за несогласованных проверок/обновлений.
5) Смягчение проблем согласованности (практики)
- Выбирать стратегию в зависимости от требований: если нужна сильная согласованность — использовать write-through или непосредственные чтения из БД; для высокой производительности и допускаемой слабой согласованности — cache-aside или write-back с контрольными механизмами.
- Инвалидация и уведомления: надежный pub/sub или CDC (change data capture) для распространения инвалидаций.
- TTL/lease: ограничить время жизни кэша, уменьшив окно устаревания; использовать лизы для гарантии эксклюзивности.
- Версионирование и условные обновления: хранить версии/etags, использовать CAS/conditional writes, проверять версию перед применением.
- Координация через распределённые примитивы: распределённые блокировки, quorum-писания/чтения (для сильной согласованности).
- Read repair, write quorums, и согласование через consensus (Paxos/Raft) при необходимости сильной согласованности.
- Обработка ошибок: атомарные операции, журнал изменения в кэше (write-ahead log для write-back) и мониторинг задержек репликации.
Короткая выжимка:
- Кэш улучшает латентность и пропускную способность, но вводит риск рассинхронизации; write-through безопаснее (меньше рассинхронов), write-back быстрее (лучше для производительности) но рискованнее. В распределённых системах нужно явное управление инвалидацией/распространением обновлений, TTL/версии или согласующие протоколы, чтобы сохранять требуемый уровень согласованности.