Bagaimana anda mengendalikan hot key atau hot row di bawah pertikaian berat?

Question

IT Interview Practice · Accepted Answer

**Berhenti menyalurkan semua trafik ke satu key: pecahkan hot key menjadi N sub-key (sharded counters), gabungkan (coalesce) bacaan pendua, sajikan dari cache setempat, dan batch penulisan supaya satu baris tidak dikemas kini pada setiap permintaan.** Satu kaunter "suka" tunggal pada pos viral boleh mengambil 50k penulisan/saat — satu baris menjadi kesesakan serialisasi apabila setiap transaction bergaduh untuk lock yang sama.

## Fan-out dan bukan satu baris yang dipertikai

```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)
```

## Teknik

- **Sharded counter / pemecahan key.** Tulis ke `likes:123:{0..N}` yang dipilih secara rawak; kiraan sebenar ialah `SUM`. Ini menukar satu hot row menjadi N baris lebih sejuk, memotong pertikaian lock sebanyak ~N. Bacaan membayar kos fan-in kecil.
- **Request coalescing (single-flight).** Jika 10k permintaan mahukan key yang sama serentak, biarkan **satu** mengenai DB dan biarkan selebihnya menunggu hasil dalam-terbang (in-flight) itu. Menghalang cache-miss stampede daripada meremukkan baris.
- **Cache setempat (in-process).** Cache nilai panas dalam setiap node app untuk TTL pendek (cth. 1s). Untuk key read-hot, itu meruntuhkan beribu bacaan/saat menjadi satu refresh — menerima sedikit kebasian.
- **Batching penulisan.** Tampan penambahan dalam memori dan flush `+= 500` sekali sesaat dan bukannya 500 kemas kini tunggal. Satu kemas kini baris sesaat dan bukannya 500 menghapuskan pertikaian sepenuhnya.

## Perspektif temu duga

Penemu duga mahu melihat anda mendiagnosis **di mana pertikaian itu berada** dan memadankan penyelesaian dengan read-hot vs write-hot. Read-hot → cache + coalescing; write-hot → sharded counter + batching. Jawapan yang baik menyenaraikan teknik; jawapan yang hebat mencatat bahawa sharding menukar **kos bacaan dengan kebolehskalaan penulisan**, dan bahawa batching/caching menukar **kesegaran dengan throughput**.

**Pertukaran & perangkap:** sharded counter menjadikan jumlah masa-nyata yang tepat lebih sukar (anda menjumlah shard) dan merumitkan logik "kurang di bawah sifar". Cache setempat menyimpang merentas node — baik untuk kiraan suka, salah untuk baki bank. Batching berisiko kehilangan penulisan yang ditampan jika node crash sebelum flush, jadi ia sesuai untuk kaunter idempotent/anggaran, bukan wang. Pilih mitigasi yang keperluan konsistensi data benarkan.

Fan-out dan bukan satu baris yang dipertikai

Teknik

Perspektif temu duga

Soalan berkaitan