როგორ დააპროექტებდით scheduler-ს 10M დროიანი task-ისთვის?

Question

IT Interview Practice · Accepted Answer

შეინახეთ task-ები **time-bucketed / priority queue**-ში, დაინდექსებული due დროით, გამოკითხეთ მხოლოდ ის task-ები, რომლებიც *ახლა* არის due, და მიაწოდეთ ისინი idempotent worker-ებს **at-least-once** მიწოდებით. არასდროს დაასკანიროთ 10M მწკრივი ყოველ tick-ზე — დაინდექსეთ fire დროით, რომ ყოველი გამოკითხვა მხოლოდ due-ს ეხებოდეს.

## არქიტექტურა

```text
API ─▶ Task store (DB/Redis ZSET, score = due_ts)  ── 10M tasks, sharded
             │
     Poller (leader per partition) ── ZPOPMIN due<=now ──▶ Ready queue (Kafka)
             │ leader election (etcd/ZK)                       │
             ▼                                                 ▼
     other pollers idle/standby                       Worker pool (idempotent)
                                                        └─ ack ✔ / retry ✖ ─▶ DLQ
```

## კომპონენტები და ნაკადი

- **Task store დაინდექსებული fire დროით**: Redis sorted set (`ZADD tasks score=due_ts`) ან DB ცხრილი, დაინდექსებული `(run_at)`-ზე. `ZPOPMIN`/`ZRANGEBYSCORE now` იღებს მხოლოდ ამ წამში due task-ებს — O(log n), არა table scan. **Sharding/partitioning** task-id-ით ანაწილებს 10M task-ს node-ებზე, რომ არცერთი store არ იყოს ცხელი.
- **Poller leader election-ით**: თითო partition-ს ჰყავს ერთი აქტიური poller, არჩეული etcd/ZooKeeper-ით; standby-ები ჩავარდნისას იღებენ სამართებელს. ერთი leader თითო partition-ზე თავიდან აცილებს ორი poller-ის მიერ ერთი task-ის dispatch-ს, ხოლო partitioning throughput-ს მაღლა ინახავს.
- **Ready queue (Kafka)**: due task-ები queue-ში ხვდება, რაც *scheduling*-ს *execution*-ისგან მიჯნავს. worker-ები poller-ისგან დამოუკიდებლად მასშტაბირდებიან.
- **Idempotent worker-ები** ასრულებენ და **ack**-ს აკეთებენ. რადგან მიწოდება at-least-once-ია, task შეიძლება ორჯერ გაეშვას (poller ჩავარდა dispatch-ის შემდეგ, done-ის მონიშვნამდე) — ამიტომ თავად სამუშაო უნდა იყოს idempotent, `task_id`-ზე დაფუძნებული, თორემ კლიენტს ორმაგად ჩამოეჭრება თანხა. ჩავარდნები ხელახლა ცდილობს backoff-ით, შემდეგ DLQ-ში ხვდება.

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

ინტერვიუერი ორ რამეს ამოწმებს: **დროის ეფექტურ ძებნას** და **exactly-once vs at-least-once**-ს. "კარგი" არის cron ციკლი ცხრილზე; "შესანიშნავი" არის sorted-set ინდექსი პლუს გულახდილი აღიარება, რომ განაწილებული exactly-once არაპრაქტიკულია, ამიტომ ირჩევთ **at-least-once + idempotent worker-ებს**. კლასიკური ხაფანგი: ერთ scheduler node-ზე დაყრდნობა — ის SPOF-ია და throughput-ის ჭერი. კიდევ ერთი: ზედმეტად უხეშად გამოკითხვა (ყოველ წუთს), როცა task-ებს წამის სიზუსტე სჭირდება, ან ზედმეტად ხშირად და store-ის დაბომბვა.

## ტრეიდ-ოფები და ჩავარდნები

- **Precision vs load**: 1s tick წამის დონის სიზუსტეს იძლევა, მაგრამ მეტ გამოკითხვას; დააჯგუფეთ task-ები per-minute შემდეგ per-second sub-queue-ებში, რომ scan ღირებულება შემცირდეს ("timing wheel" / hashed-wheel მიდგომა, რომელსაც Kafka და Quartz იყენებს).
- **At-least-once vs exactly-once**: ვერ მიიღებთ ნამდვილ exactly-once-ს crash საზღვარზე; idempotency key-ები ორმაგ შესრულებას უვნებელს ხდის — სწორი ტრეიდ-ოფი.
- **ჩავარდნა**: თუ poller მოკვდა dispatch-ის შუაში, leader election standby-ს დააწინაურებს და un-acked task-ები ხელახლა მიეწოდება — არაფერი იკარგება, ზოგი შეიძლება გამეორდეს. აკვირდით **clock skew**-ს node-ებს შორის (NTP), თორემ task-ები ადრე/გვიან გაეშვება; და შემოსაზღვრეთ retry-ები, რომ მუდმივად ჩავარდნილი task სამუდამოდ არ ტრიალებდეს — გაგზავნეთ DLQ-ში შესამოწმებლად.

არქიტექტურა

კომპონენტები და ნაკადი

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

ტრეიდ-ოფები და ჩავარდნები

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