News feed — tổng quan case trả giá lúc ghi hay lúc đọc

TL;DR: Case này đặt một bài toán cụ thể: 10 triệu người dùng mỗi ngày, đỉnh khoảng 3.500 lượt mở feed và 70 bài đăng mỗi giây, mỗi trang 50 bài với p99 dưới 200 ms, và vài tài khoản có tới 5 triệu người theo dõi. Bạn sẽ tự đo trên Postgres của mình cái giá của phương án ngây thơ, rồi tự chọn ba quyết định trên ba trục khác nhau: chỗ trả giá fan-out, cách xử lý tài khoản nhiều người theo dõi, và điều xảy ra khi fan-out chạy trễ. Mỗi lựa chọn đi kèm một cái giá, và cái giá đó bạn tự đo được trên Postgres của mình.

Bạn mở ứng dụng, kéo xuống, và 50 bài mới nhất của những người bạn theo dõi hiện ra trong chưa đầy một phần năm giây. Nghe như một câu truy vấn, cho đến khi 10 triệu người làm việc đó mỗi ngày, và một người trong số họ đăng bài cho 5 triệu người theo dõi. Module này đi từ chỗ "nghe như một câu truy vấn" tới chỗ biết chính xác nó vỡ ở đâu, vì sao, và sửa bằng cách đổi lấy cái gì.

Bài toán và bảng ràng buộc

Bảng dưới là bản rút gọn của bảng ở bài 01. Năm bài sau trích lại đúng bộ số này, không đặt số mới. Đây là ràng buộc tự đặt, không phải số của một công ty thật nào.

Hai dòng kéo ngược chiều nhau: p99 dưới 200 ms nói feed phải đọc rẻ, còn "5 giây" cùng "lớn nhất 5 triệu người theo dõi" nói mỗi bài đăng có thể kéo theo một khối công việc rất lớn. Cả module xoay quanh việc giữ cả hai.

Sau module này bạn sẽ

• Ước lượng được tải đọc, tải ghi và số ghi timeline mỗi giây của một news feed từ bảng ràng buộc tự đặt và phân bố người theo dõi đo trên máy mình.
• Chẩn đoán được vì sao dựng feed bằng JOIN lúc đọc vỡ p99 khi số tài khoản đang theo dõi và tải đọc tăng.
• Chọn được giữa fan-out lúc ghi và fan-out lúc đọc theo tỉ lệ đọc/ghi và chi phí ở tải đỉnh.
• Thiết kế được ngưỡng tách tài khoản nhiều người theo dõi khỏi fan-out lúc ghi theo phân bố người theo dõi.
• Thiết kế được luồng fan-out bất đồng bộ giữ read-your-writes cho người đăng và gỡ được bài đã xoá khỏi feed.
• Biện luận được vì sao một mạng xã hội thật chọn khác thiết kế của bạn dựa trên ràng buộc của họ.

Lộ trình sáu bài, mỗi bài trả lời một câu hỏi

1. Bài 01, ràng buộc và ước lượng: một bài đăng nở thành bao nhiêu lần ghi? Chốt bảng số, tự tính tải, tự đo phân bố người theo dõi. Chưa có thiết kế nào, chỉ có số.
2. Bài 02, phương án ngây thơ: phương án đơn giản nhất vỡ ở đâu? Bạn tự chạy nó với ba loại người đọc và tự chỉ ra điểm vỡ.
3. Bài 03, chỗ trả giá: làm việc gom feed lúc ghi hay lúc đọc? Quyết định thứ nhất, trục "chỗ trả giá".
4. Bài 04, tài khoản triệu người theo dõi: đuôi dài của phân bố xử lý thế nào? Quyết định thứ hai, trục "ai thuộc nhóm nào".
5. Bài 05, fan-out chạy trễ: trong khoảng trễ, ai thấy gì? Quyết định thứ ba, trục "thời gian".
6. Bài 06, đối chiếu thực tế: hệ thật chọn gì, và ràng buộc nào của họ khác bảng của bạn?

Bài 07 ráp ba quyết định thành một thiết kế hoàn chỉnh và gom các cái giá vào một bảng.

Cần chuẩn bị gì

Bạn cần đã học khoá data-phan-tan, nhất là phần tail latency, scalability và replication lag, vì case này <Recall> lại chúng thay vì dạy lại. Case flash sale là cầu mềm, không bắt buộc: nó dạy phương pháp bạn sẽ dùng lại ở đây (nêu ràng buộc bằng số, ước lượng bằng giấy, mỗi lựa chọn kèm một cái giá đo được), nên đã làm rồi thì bài 01 sẽ nhẹ hơn. Về công cụ: Postgres chạy bằng Docker và pgbench (đi kèm bản cài Postgres, hoặc dùng trong container). Số đo khác máy, nên bài dạy theo tỉ lệ, và máy bạn cho số khác là bình thường.

Cách học ở tuyến này

Ba thói quen, lặp lại ở mọi bài:

• Tự quyết trước khi đọc lời giải. Gặp <DesignChoice> thì chọn một phương án rồi mới đọc phần phân tích.
• Mọi lựa chọn có cái giá. Câu cần luyện là "cái giá nào ràng buộc của tôi gánh được", không phải "đâu là đáp án đúng".
• Tự đo. Mỗi bài có một script nhỏ chạy trên Postgres của bạn. Con số của chính bạn thuyết phục hơn con số trong bài.

Bắt đầu với bài 01.