高い競合下でのホットキーやホット行をどう扱いますか？

Question

IT Interview Practice · Accepted Answer

**すべてのトラフィックを1つのキーに集めるのをやめます：ホットキーをNサブキー（シャード化カウンター）に分割し、重複した読み取りを束ね、ローカルキャッシュから提供し、書き込みをバッチ化して1行がリクエストごとに更新されないようにします。** バズった投稿の単一の「いいね」カウンターは5万書き込み/秒を受けえます。すべてのトランザクションが同じロックを奪い合うので、1行が直列化のボトルネックになります。

## 1つの競合行の代わりにファンアウト

```text
                 50k inc/sec on post:123
                          │
             hash(request) % N   (split the key)
        ┌────────┬────────┬────────┬────────┐
        ▼        ▼        ▼        ▼        ▼
   likes:123:0  :123:1  :123:2  :123:3  :123:4   ← sharded counters
        └────────┴───┬────┴────────┴────────┘
                     ▼
             SUM on read = total     (read fans in)
```

## 手法

- **シャード化カウンター / キー分割。** ランダムに選んだ `likes:123:{0..N}` に書き込みます。真のカウントは `SUM` です。これで1つのホット行をNつの冷たい行に変え、ロック競合を約N分の1に削減します。読み取りは小さなfan-inコストを支払います。
- **リクエストの束ね（single-flight）。** 1万リクエストが同時に同じキーを欲しがる場合、**1つ**だけDBに当て、残りはその進行中の結果を待たせます。キャッシュミスのスタンピードが行を潰すのを防ぎます。
- **ローカル（インプロセス）キャッシュ。** 各アプリノードで短いTTL（例：1秒）ホットな値をキャッシュします。読み取りホットなキーでは、数千の読み取り/秒を1回のリフレッシュに畳み込み、わずかな陳腐化を受け入れます。
- **書き込みバッチ化。** インクリメントをメモリにバッファリングし、500回の単一更新の代わりに1秒に1回 `+= 500` をフラッシュします。1秒に1行の更新が競合を完全に取り除きます。

## 面接での観点

面接官は、あなたが**競合がどこにあるか**を診断し、読み取りホット対書き込みホットに修正を合わせるのを見たいのです。読み取りホット → キャッシュ + 束ね。書き込みホット → シャード化カウンター + バッチ化。良い回答は手法を列挙します。優れた回答は、シャーディングが**読み取りコストと書き込みスケーラビリティ**をトレードすること、バッチ化/キャッシュが**鮮度とスループット**をトレードすることに言及します。

**トレードオフと罠：** シャード化カウンターは正確なリアルタイム合計を難しくし（シャードを合計する）、「ゼロ以下へのデクリメント」ロジックを複雑にします。ローカルキャッシュはノード間でドリフトします。いいね数には問題ないが銀行残高には誤りです。バッチ化はフラッシュ前にノードがクラッシュするとバッファリングした書き込みを失うリスクがあるので、金銭ではなく冪等/近似カウンターに適します。データの一貫性ニーズが許す緩和策を選びます。

1つの競合行の代わりにファンアウト

手法

面接での観点

関連する質問