キャッシュ更新戦略

4戦略の早見

戦略	読み取り	書き込み	最大の弱点
Cache-aside	アプリがmiss時にDBから読む	アプリがDBに書く	miss時に3往復で遅い
Write-through	キャッシュから読む	同期でDBへ書く	書き込みが遅い
Write-behind	キャッシュから読む	非同期でDBへ書く	障害でデータ損失
Refresh-ahead	先読みで温めておく	(読み取り最適化)	予測外れで無駄

① Cache-aside(遅延読み込み)— 最も一般的

アプリが司令塔。キャッシュはDBと直接やり取りしません。

図を描画中...

読みに行ってなければDBから取り、キャッシュに入れて返す。実際に要求されたデータだけキャッシュされるので無駄がない。Memcachedでよく使われます。

• 短所『3往復』: ミス時は『キャッシュ探索 → DBロード → キャッシュ追加』の3ステップで遅い。
• 短所: DBを直接更新するとキャッシュが古くなる(TTLやwrite-throughで緩和)。

② Write-through(書き込み貫通)

アプリはキャッシュを主データストアとして扱い、書き込み時にキャッシュが同期的にDBへ書きます。

図を描画中...

キャッシュとDBが常に一致するので古くならない。ただし毎回DBへの書き込み完了を待つので書き込みが遅い。また、書いたデータの多くは読まれないこともある(TTLで緩和)。

③ Write-behind(書き戻し)

キャッシュに書いたら即座に完了を返し、DBへは後から非同期で書きます。

図を描画中...

書き込みが爆速になります。ただしDBに届く前にキャッシュが落ちるとデータが消える(重大リスク)。実装もcache-aside/write-throughより複雑。

④ Refresh-ahead(先読み)

期限が切れる前に、よくアクセスされるエントリを先回りで自動更新しておきます。

図を描画中...

予測が当たれば、ユーザーがアクセスしたときには既に新鮮なデータがある(待ち時間ゼロ)。ただし予測が外れると、使われないデータを無駄に更新して逆に性能が落ちます。

つまずきポイント

• どれが正解かは『読み取り重視 or 書き込み重視』『古さやデータ損失をどこまで許せるか』で決まる。万能はない。
• 迷ったらまずCache-aside(最も一般的で素直)。書き込み整合性が重要ならWrite-through、書き込み速度が命でデータ損失を許せるならWrite-behind。
• Write-behindの『データ損失リスク』は見落としがち。お金など失ってはいけないデータには使わない。