Redisのキャッシング戦略とパターンにはどのようなものがあるか?

Question

Accepted Answer

基本的なキャッシュアサイドを超えて、複数の**キャッシング戦略**――キャッシュアサイド、ライトスルー、ライトビハインド、リードスルー――が存在し、それぞれ異なる一貫性とパフォーマンスのトレードオフを持ちます。これらを理解すること(および削除ポリシー)は、効果的なキャッシングを設計するのに役立ちます。

## キャッシュアサイド(遅延ロード――最も一般的)

```text
App checks cache → miss → load from DB → populate cache → return.
  ✓ Only requested data is cached (efficient); resilient (works if cache is down)
  ✗ First request is a miss (slower); cache can be stale until TTL/invalidation
→ The default, most common strategy.
```

## ライトスルーおよびライトビハインド

```text
WRITE-THROUGH → write to cache AND DB together (synchronously) on every write
  ✓ Cache always fresh/consistent  ✗ Writes are slower (two writes); caches unread data

WRITE-BEHIND (write-back) → write to cache immediately, write to DB ASYNC later
  ✓ Fast writes  ✗ Risk of data loss if cache fails before the DB write; more complex
```

## リードスルー

```text
READ-THROUGH → the cache layer itself loads from the DB on a miss (abstracted)
  → app just reads from the cache; the cache handles DB loading transparently
  (similar to cache-aside but the loading logic lives in the cache layer/library)
```

## 削除ポリシー(メモリが満杯の場合)

```text
When Redis hits its memory limit (maxmemory), it EVICTS keys per a policy:
  LRU (Least Recently Used)  → evict least-recently-accessed (good general default)
  LFU (Least Frequently Used)→ evict least-frequently-accessed
  TTL-based (volatile-ttl)   → evict keys closest to expiry
  random / noeviction        → random, or reject writes when full
→ allkeys-lru is a common choice for a pure cache. Set maxmemory + a policy.
```

## キャッシュの問題を回避する

```text
✓ Cache STAMPEDE (many misses at once hammering the DB) → locking, staggered TTLs
✓ Stale data → appropriate TTLs + invalidation on writes
✓ Cache PENETRATION (querying non-existent keys) → cache negative results briefly
```

## なぜ重要なのか

キャッシング戦略を理解することは、**効果的なキャッシングシステムの設計**、基本的なキャッシュアサイドの上に構築する際に価値があり、パフォーマンス重視の作業に役立つ知識です。

キャッシュアサイド(遅延ロード――キャッシュを確認し、ミスの場合はDBからロードし、キャッシュに値を入力する)が一般的なデフォルトですが、**戦略の範囲**を理解することで、その状況に最適なものを選択できます: **ライトスルー**(キャッシュとDBに同時に書き込み、常に新しいキャッシュを保証するが遅い書き込みのコスト)、**ライトビハインド**(キャッシュに即座に書き込み、DBは非同期で書き込み、高速な書き込みだがデータ喪失のリスク)、および**リードスルー**(キャッシュレイヤーが透過的にDBからロード)――それぞれが異なる一貫性とパフォーマンスのトレードオフを持ち、異なる一貫性と書き込みパターン要件に重要です。

**削除ポリシー**(LRU、LFU、TTLベースなど――メモリが満杯の場合にRedisがどのキーを削除するかを決定する)を理解することは、Redisをキャッシュとして正しく構成する(maxmemoryを設定し、pure cacheの場合は`allkeys-lru`のような適切なポリシーを設定する)ために重要であり、メモリプレッシャー下で適切に動作します。

一般的なキャッシュの問題を回避する方法を知ること――キャッシュ**スタンピード**(多くの同時ミスがデータベースに負荷をかける、ロックまたは段階的なTTLで緩和)、**古いデータ**(TTLと無効化で管理)、およびキャッシュ**貫通**(存在しないキーの繰り返しクエリ、負の結果をキャッシュすることで緩和)――は、本番環境の実際の問題を回避する成熟したキャッシング設計を反映しています。

効果的なキャッシングはパフォーマンスに大きく影響し、正しい戦略と設定はユースケースに依存し、戦略、削除ポリシー、および一般的な落とし穴を理解することは堅牢なキャッシングの設計を可能にするため、キャッシング戦略とパターンを理解することは、Redisでのパフォーマンスエンジニアリングにおいて価値のある実践的で関連性の高い知識であり、キャッシングを基本的なパターンから一貫性、メモリ、および障害モードを正しく処理する設計されたシステムへと昇格させます。