DBの前段にcache-aside層（Redis/Memcached）を置いて読み取りをメモリに当て、エントリにTTLを与え書き込み時に無効化し、コールドキーがDBにthundering herdを解き放てないようスタンピード保護を追加し、1つの人気キーが単一ノードを溶かさないようホットキーをレプリカに分散します。
┌── hit ──▶ return value
request ──▶ cache│
└── miss ─▶ lock ─▶ DB read ─▶ set(TTL) ─▶ return
│
(only ONE miss populates; others wait)
DB writes ──▶ invalidate/update key
cache-asideではアプリがキャッシュを確認し、ミス時にDBを読んで自分でキャッシュを投入します。read-throughではキャッシュライブラリがそれをやってくれます。いずれにせよ目標は同じで、5msのDBクエリを0.2msのメモリルックアップに変えます。ヒット率95%のキャッシュはDBの読み取りトラフィックを20倍削ります。毎分数百万リクエストでは、DBは単純にすべての読み取りを捌けません。キャッシュこそが数字を成立させます。
キャッシュを新鮮に保つ2つの方法で、通常は両方が必要です。TTLは陳腐化を制限します。エントリはN秒後に失効するので誤ったデータが自己修復します。明示的無効化は書き込み時にキーを削除/更新し、TTLを待てない正しさを担保します。典型的なバグはキャッシュを無効化せずに陳腐なデータを数分間提供すること。より微妙なバグは同じ書き込みで無効化とセットを行い、レースすることです。
面接官は、あなたが「Redisを追加」の先を考えるのを見たいのです。良い：TTL付きcache-aside。優れた：スタンピード保護、無効化戦略、ホットキー対応、そしてキャッシュ障害時に何が起きるかを挙げること。罠はキャッシュが常に稼働していると仮定すること。Redisが死んですべてのミスがDBに流れ落ちると、DBも道連れにする**キャッシュアバランチ（雪崩）**が起きます。
ジュニアからシニアまで、詳細な回答付きのIT面接質問ライブラリ。
寄付する