Độ trễ và Thông lượng trong Hệ thống Phân tán

Trong thiết kế hệ thống phân tán, Latency và Throughput là hai đại lượng cốt lõi phản ánh hiệu năng của hệ thống. Chúng mô tả hai góc nhìn khác nhau nhưng không độc lập — chúng được ràng buộc chặt chẽ qua lý thuyết hàng đợi (Little's Law).

📌 Các khái niệm cơ bản

• Latency (Độ trễ) — Thời gian từ lúc gửi request đến khi nhận được response. Công thức tại mỗi node: R = Wq + S, trong đó Wq là thời gian chờ trong hàng đợi và S là thời gian xử lý (Service Time). Đây là đại lượng micro-level — đo trên từng request.
• Throughput (Thông lượng) — Số lượng request hệ thống xử lý thành công trong một đơn vị thời gian (ví dụ: requests/second). Đây là đại lượng macro-level — phản ánh khả năng tổng thể của hệ thống.
• Bandwidth (Băng thông) — Throughput lý thuyết tối đa mà hệ thống có thể đạt được trong điều kiện lý tưởng. Bandwidth là giới hạn trên của Throughput.
• Goodput — Throughput thực tế hữu ích, sau khi loại bỏ overhead (retransmissions, protocol headers, retries). Goodput ≤ Throughput ≤ Bandwidth.

Latency và Throughput không phải nghịch đảo đơn giản của nhau. Khi hệ thống tiến gần tới bão hòa, mối quan hệ này trở nên phi tuyến — Latency tăng theo đường hyperbol trong khi Throughput bị giới hạn bởi tài nguyên vật lý.

Để hiểu sâu hơn, hãy tham khảo Hardware Latency Hierarchy và Tail Latency at Scale.

Latency end-to-end không phải một con số đơn lẻ — nó là tổng hợp của nhiều tầng xử lý. Tại mỗi tầng, request phải chịu cả thời gian chờ đợi (Queuing) lẫn thời gian xử lý thực tế (Service Time). Sơ đồ dưới đây mô tả hành trình của một request qua các tầng:

🔍 Phân tích từng thành phần

• Propagation Delay — Phụ thuộc vào khoảng cách vật lý và tốc độ ánh sáng. Ví dụ: US → EU ≈ 70-80ms RTT.
• Transmission Delay — Phụ thuộc vào kích thước payload và bandwidth của đường truyền.
• Queuing Delay — Biến thiên mạnh nhất, phụ thuộc vào mức tải hiện tại. Đây là nguyên nhân chính gây ra tail latency.
• Processing (R = Wq + S) — Tại mỗi server, request chờ trong hàng đợi (Wq) rồi mới được xử lý (S). Nhiều node xếp nối tiếp sẽ nhân lên tổng latency.

Tham khảo chi tiết về thời gian truy cập phần cứng tại Hardware Latency Hierarchy.

Mối quan hệ giữa Latency và Throughput tuân theo đường cong hyperbol từ lý thuyết hàng đợi M/M/1. Khi hệ thống tiến gần tới bão hòa (utilization ρ → 1), latency tăng phi tuyến tính:

R = S / (1 - ρ)

Trong đó:
  R  = Response Time (Latency trung bình)
  S  = Service Time (thời gian xử lý khi không có hàng đợi)
  ρ  = Utilization (tỷ lệ sử dụng tài nguyên, 0 ≤ ρ < 1)

Bảng dưới đây minh họa với Service Time S = 10ms. Khi utilization tăng từ 50% lên 99%, Latency tăng từ 2× lên 100× so với service time gốc:

⚠️ Quy tắc thực hành: Hầu hết các hệ thống production nên duy trì utilization dưới 70-80% để tránh vùng latency tăng vọt. Vượt qua 90%, hệ thống trở nên cực kỳ nhạy cảm — chỉ cần thêm một lượng nhỏ traffic cũng có thể gây ra cascading latency spikes.

Tìm hiểu thêm về mô hình toán học tại Little's Law và Queueing Theory.

Average (trung bình) là chỉ số gây hiểu lầm. Trong hệ thống phân tán, phân bố latency thường lệch phải (right-skewed) — đa số request nhanh, nhưng một số ít request chậm bất thường. Average che giấu những request chậm này.

📊 Ví dụ thực tế

So sánh hai service với ~1000 requests:

                Service A       Service B
  Average:      51ms            50ms          ← Gần như giống nhau!
  P50:          48ms            45ms
  P95:          63ms            450ms         ← Chênh lệch 7× !
  P99:          78ms            2,300ms       ← Chênh lệch 29× !

Nếu chỉ nhìn average, ta kết luận hai service tương đương. Nhưng P95 và P99 cho thấy Service B có vấn đề nghiêm trọng với tail latency — cứ 20 request lại có 1 request chậm gấp 9× trung bình.

✅ Nguyên tắc đo lường

• Luôn sử dụng Percentiles (P50, P95, P99, P99.9) thay vì average.
• P50 cho biết trải nghiệm "điển hình" của user.
• P99 cho biết trải nghiệm tệ nhất mà 1% user phải chịu — quan trọng hơn nhiều trong hệ thống phân tán vì fan-out effect.
• Cẩn thận với Coordinated Omission — lỗi đo lường phổ biến khiến kết quả benchmark sai lệch nghiêm trọng.

Xem chi tiết tại Latency Percentile Metrics.

Hiệu năng hệ thống bị chi phối bởi nhiều yếu tố, từ phần cứng đến kiến trúc phần mềm:

• Hardware Latency Hierarchy — Thời gian truy cập khác nhau hàng triệu lần giữa L1 cache (~1ns) và disk I/O (~10ms). Lựa chọn storage layer ảnh hưởng trực tiếp đến service time. → Chi tiết
• Thread Contention & Context Switching — Khi nhiều thread tranh chấp cùng một lock hoặc tài nguyên, overhead từ context switching và wait time tăng đáng kể, đặc biệt trên hệ thống high-concurrency.
• Garbage Collection (GC) Pauses — Trong JVM, Go, .NET: GC pause có thể gây ra latency spike hàng chục đến hàng trăm ms, tạo ra tail latency không dự đoán được.
• Network Latency & Topology — Khoảng cách vật lý, số hop, congestion trên đường truyền. Cross-region calls có thể thêm 50-200ms RTT.
• Queueing Delays — Tại mỗi điểm xử lý (load balancer, thread pool, database connection pool), request phải chờ. Nhiều hàng đợi xếp chồng tạo hiệu ứng cộng dồn. → Adaptive Concurrency Control
• Fan-out Effect — Trong kiến trúc microservices, một request gốc có thể fan-out thành hàng chục sub-requests. Latency tổng bị chi phối bởi request chậm nhất (slowest-of-N). → Tail Latency at Scale

🔗 Chủ đề cốt lõi

• Hardware Latency Hierarchy — Bảng thời gian truy cập từ CPU register đến network call.
• Little's Law & Queueing Theory — Mô hình toán học giải thích mối quan hệ L = λW.
• Tail Latency at Scale — Tại sao P99 quan trọng hơn average trong hệ thống phân tán.
• Latency Percentile Metrics — Hướng dẫn đo lường và giám sát latency bằng percentiles.

📚 Chủ đề mở rộng

• Adaptive Concurrency Control — Kỹ thuật tự động điều chỉnh concurrency limit dựa trên latency feedback.
• Coordinated Omission — Lỗi đo lường benchmark phổ biến và cách phòng tránh.
• PACELC Theorem — Mở rộng CAP theorem, bao gồm trade-off Latency vs Consistency.
• System Design Trade-offs — Tổng quan về các trade-off trong thiết kế hệ thống.
• CAP Theorem, ACID & BASE — Nền tảng lý thuyết về consistency và availability.