როგორ ამუშავებთ hot key-ს ან hot row-ს მძიმე contention-ის ქვეშ?

Question

IT Interview Practice · Accepted Answer

**შეწყვიტეთ მთელი ტრაფიკის ერთ გასაღებზე მიმართვა: დაყავით hot key N sub-key-ად (sharded counter-ები), გააერთიანეთ დუბლიკატი read-ები, ემსახურეთ ლოკალური cache-იდან და batch გააკეთეთ write-ებს, რომ ერთი მწკრივი ყოველ request-ზე არ განახლდეს.** ერთი "likes" counter ვირუსულ პოსტზე შეიძლება 50k write/წამს იღებდეს — ერთი მწკრივი serialization bottleneck-ად იქცევა, რადგან ყოველი transaction ერთ lock-ს ეცილება.

## Fan-out ერთი contended მწკრივის ნაცვლად

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

## ტექნიკები

- **Sharded counter / key splitting.** ჩაწერეთ `likes:123:{0..N}`-ში, შემთხვევით არჩეულში; ნამდვილი count არის `SUM`. ეს ერთ hot მწკრივს N ცივ მწკრივად აქცევს, lock contention-ს ~N-ჯერ ამცირებს. read-ები პატარა fan-in ღირებულებას იხდიან.
- **Request coalescing (single-flight).** თუ 10k request ერთ გასაღებს ერთდროულად ითხოვს, მიეცით **ერთს** DB-ს მოხვედრა და დანარჩენს ამ in-flight შედეგზე ლოდინი. ხელს უშლის cache-miss stampede-ს მწკრივის დაშლა.
- **ლოკალური (in-process) cache.** დააქეშეთ hot მნიშვნელობა თითო app node-ში მოკლე TTL-ით (მაგ. 1s). read-hot გასაღებისთვის ეს ათასობით read/წამს ერთ refresh-ად ამცირებს — ოდნავი სიძველის მიღებით.
- **Write batching.** ბუფერი გაუკეთეთ increment-ებს მეხსიერებაში და ჩააფლაშეთ `+= 500` წამში ერთხელ 500 ცალკე update-ის ნაცვლად. ერთი მწკრივის update წამში 500-ის ნაცვლად contention-ს მთლიანად აშორებს.

## ინტერვიუს პერსპექტივა

ინტერვიუერს სურს დაინახოს, რომ დიაგნოზირებთ **სად არის contention** და გამოსავალს read-hot vs write-hot-ს უსადაგებთ. read-hot → cache + coalescing; write-hot → sharded counter-ები + batching. კარგი პასუხი ჩამოთვლის ტექნიკებს; შესანიშნავი პასუხი აღნიშნავს, რომ sharding **read ღირებულებას write scalability-ს ცვლის**, და რომ batching/caching **სიახლეს throughput-ს ცვლის**.

**ტრეიდ-ოფები და ხაფანგები:** sharded counter-ები ზუსტ real-time ჯამებს ართულებს (shard-ებს აჯამებთ) და "ნულს ქვემოთ decrement" ლოგიკას ართულებს. ლოკალური cache-ები node-ებზე განსხვავდება — like count-ისთვის კარგია, ბანკის ბალანსისთვის — არასწორი. batching-ს buffered write-ების დაკარგვის რისკი აქვს, თუ node flush-ამდე ჩავარდა, ამიტომ ის idempotent/მიახლოებით counter-ებს უხდება, არა ფულს. აირჩიეთ ის შემსუბუქება, რასაც მონაცემის consistency საჭიროებები უშვებს.

Fan-out ერთი contended მწკრივის ნაცვლად

ტექნიკები

ინტერვიუს პერსპექტივა

დაკავშირებული კითხვები