Bạn thiết kế scheduler cho 10 triệu tác vụ hẹn giờ thế nào?

Question

IT Interview Practice · Accepted Answer

Lưu task trong một **hàng đợi time-bucket / ưu tiên** đánh khoá theo thời điểm đến hạn, chỉ poll các task đến hạn *ngay bây giờ*, rồi giao cho worker idempotent với giao nhận **at-least-once**. Đừng bao giờ quét 10 triệu hàng mỗi nhịp — index theo thời điểm bắn để mỗi lần poll chỉ chạm những gì đến hạn.

## Kiến trúc

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

## Thành phần và luồng

- **Task store index theo thời điểm bắn**: một sorted set của Redis (`ZADD tasks score=due_ts`) hoặc một bảng DB index trên `(run_at)`. `ZPOPMIN`/`ZRANGEBYSCORE now` chỉ kéo các task đến hạn trong giây này — O(log n), không phải quét bảng. **Sharding/partition** theo task-id trải 10 triệu task ra nhiều node để không store nào bị nóng.
- **Poller với leader election**: mỗi partition có một poller đang hoạt động được bầu qua etcd/ZooKeeper; các standby tiếp quản khi có sự cố. Một leader cho mỗi partition tránh hai poller cùng dispatch một task, trong khi partition giữ throughput cao.
- **Ready queue (Kafka)**: task đến hạn được enqueue, tách *lập lịch* khỏi *thực thi*. Worker scale độc lập với poller.
- **Worker idempotent** thực thi và **ack**. Vì giao nhận là at-least-once, một task có thể chạy hai lần (poller chết sau khi dispatch, trước khi đánh dấu xong) — nên bản thân công việc phải idempotent, khoá theo `task_id`, nếu không bạn tính tiền khách hàng hai lần. Thất bại thì retry với backoff, rồi rơi vào DLQ.

## Góc nhìn phỏng vấn

Người phỏng vấn dò hai thứ: **tra cứu thời gian hiệu quả** và **exactly-once vs at-least-once**. "Khá" là một vòng lặp cron quét bảng; "xuất sắc" là index bằng sorted set cộng với thừa nhận thẳng thắn rằng exactly-once trong hệ phân tán là bất khả thi thực tế, nên bạn chọn **at-least-once + worker idempotent**. Bẫy kinh điển: dựa vào một node scheduler duy nhất — nó là SPOF và là trần throughput. Bẫy khác: poll quá thô (mỗi phút) khi task cần độ chính xác giây, hoặc quá mịn và nện liên tục vào store.

## Đánh đổi và kịch bản hỏng

- **Độ chính xác vs tải**: nhịp 1s cho độ chính xác cấp giây nhưng nhiều lượt poll hơn; gom task vào sub-queue theo phút rồi theo giây để giảm chi phí quét (cách "timing wheel" / hashed-wheel mà Kafka và Quartz dùng).
- **At-least-once vs exactly-once**: bạn không thể đạt exactly-once thật khi vắt qua ranh giới một cú crash; idempotency key khiến chạy hai lần trở nên vô hại — đó là cái đánh đổi đúng.
- **Kịch bản hỏng**: nếu một poller chết giữa lúc dispatch, leader election đề bạt một standby và các task chưa ack được giao lại — không mất gì, một số có thể lặp. Coi chừng **clock skew** giữa các node (NTP) kẻo task bắn sớm/muộn; và giới hạn số retry để một task hỏng vĩnh viễn không lặp mãi — đẩy nó vào DLQ để kiểm tra.

Kiến trúc

Thành phần và luồng

Góc nhìn phỏng vấn

Đánh đổi và kịch bản hỏng

Câu hỏi liên quan