---
title: "Thiết kế hệ thống chịu tải cao - rate limiting, load shedding và circuit breaker"
description: "Khóa học thiết kế hệ thống chịu tải cao giúp bạn bảo vệ goodput khi lưu lượng vượt capacity, key cache hết hạn hoặc dependency chậm trễ. Bạn sẽ làm chủ kỹ thuật tính toán concurrency limit, rate limiting, load shedding, chống cache stampede, bulkhead và circuit breaker để giữ dịch vụ luôn ổn định dưới áp lực lớn."
canonical: "https://200lab.io/courses/thiet-ke-he-thong-chiu-tai-cao-rate-limiting-load-shedding-va-circuit-breaker"
type: "course"
course_type: "course"
learning_type: "free_form"
published: "2026-10-04T01:22:14Z"
students: 57
---

## Khóa học này mang lại gì cho bạn

Khi lượng truy cập tăng vọt, một hệ thống không có cơ chế bảo vệ sẽ nhanh chóng tiêu hao tài nguyên cho những tác vụ trễ deadline, khiến lượng request xử lý thành công sụt giảm nghiêm trọng. Khóa học trang bị cho bạn tư duy thiết kế và phương pháp tính toán để giữ vững năng lực phục vụ thực tế của hệ thống, ngay cả khi buộc phải từ chối một phần lưu lượng:

- **Tính toán mức tăng p99** — Ước lượng độ trễ đuôi khi gọi song song nhiều service phía sau, phân tích hiện tượng khuếch đại độ trễ và gộp histogram chính xác thay vì lấy trung bình các phân vị giữa nhiều instance.
- **Thiết lập concurrency limit** — Xác định trần xử lý đồng thời và dung lượng pool an toàn bằng Little’s Law, giúp hệ thống từ chối nhanh bằng mã 503 thay vì để request ứ đọng trong hàng chờ nội bộ.
- **Kiểm soát lưu lượng từng client** — Lựa chọn khóa định danh phù hợp, cấu hình thuật toán token bucket trên bộ nhớ dùng chung và áp dụng cơ chế tạm giữ quota cho các dịch vụ đặc thù như LLM gateway.
- **Điều tiết lưu lượng** — Phối hợp virtual waiting room ở tầng edge để điều tiết nhịp tiếp nhận, phân loại mức độ ưu tiên bằng load shedding và chặn tràn bộ nhớ bằng backpressure.
- **Thiết kế tầng cache** — Chuẩn hóa cache key, phân bổ TTL theo nghiệp vụ, dùng tombstone kết hợp thao tác atomic để chặn dữ liệu cũ ghi đè, loại bỏ cache stampede và cấu hình header CDN chuẩn xác.
- **Cô lập lỗi dependency** — Phân bổ deadline budget qua chuỗi service, phân vùng tài nguyên bằng bulkhead, ngừng gửi lời gọi mới tới dependency đang lỗi bằng circuit breaker và kích hoạt graceful degradation khi dependency gặp sự cố.
- **Chẩn đoán điểm nghẽn độ trễ** — Lần theo dữ liệu trace và trạng thái connection pool để phát hiện chính xác nguyên nhân gây trễ dây chuyền, ngay cả khi CPU server và tỉ lệ lỗi HTTP chưa có dấu hiệu bất thường.

Các giải pháp và công thức trong chương trình minh họa cách tính bằng số liệu giả định; khi áp dụng vào thực tế, bạn cần đo đạc trực tiếp trên hệ thống của mình cùng yêu cầu nghiệp vụ, độc lập với ngôn ngữ lập trình và nền tảng hạ tầng cụ thể.

## Khóa học cung cấp những nền tảng nào

Nền tảng xuyên suốt của khóa học là tối ưu hóa goodput, tức số lượng request thành công và trả về trọn vẹn trong deadline budget mỗi giây, thay vì chỉ theo đuổi chỉ số throughput thuần túy. Để duy trì goodput, hệ thống cần chủ động từ chối nhanh những công việc vượt quá sức chứa và thiết lập ranh giới cô lập để sự cố cục bộ không lan rộng thành thảm họa dây chuyền. Nội dung chương trình đúc kết từ các nghiên cứu thực tế về [The Tail at Scale](https://research.google/pubs/the-tail-at-scale/) của Google, mô hình phòng chống sự cố lan tầng trong [Addressing Cascading Failures](https://sre.google/sre-book/addressing-cascading-failures/) và nguyên lý điều tiết tải từ [Using load shedding to avoid overload](https://builder.aws.com/content/3Eun1EEyX6p2e3VYNyRLSJzLuMV/using-load-shedding-to-avoid-overload) của AWS.

### 1. p99 tăng vọt và cách giới hạn số request được nhận

Nhóm bài mở đầu làm rõ bản chất phi tuyến tính của độ trễ đuôi khi service hoạt động gần mức tải tới hạn hoặc thực hiện fan-out gọi song song nhiều dependency. Bạn sẽ áp dụng Little’s Law để tính toán concurrency limit và kích thước connection pool cho từng instance, giữ thời gian xếp hàng trong RAM ở mức an toàn thay vì dồn áp lực xuống database. Tiếp đó, bạn triển khai rate limiting dùng chung trên Redis với thuật toán token bucket nhằm ngăn chặn các client đơn lẻ chiếm dụng capacity chung của toàn hệ thống. Bài tình huống khép lại nhóm bài hướng dẫn giải pháp tạm giữ trước token đầu vào kèm `max_tokens` trên LLM gateway, bảo vệ hạn mức chung của tài khoản trước các request tốn kém tài nguyên.

### 2. Xử lý khi tổng tải vượt capacity

Khi lưu lượng truy cập thực tế vượt quá khả năng phục vụ của toàn bộ hạ tầng, hệ thống cần những van an toàn để điều tiết và thanh lọc request ngay từ cửa vào. Bạn sẽ thiết lập virtual waiting room ở tầng edge để cấp admission token có chữ ký theo đúng nhịp xử lý của backend trong các sự kiện mở bán đã biết trước thời điểm. Với các đợt tăng tải đột ngột, kỹ thuật load shedding dựa trên deadline và nhãn ưu tiên sẽ loại bỏ các tác vụ phụ trợ như prefetch hay beacon nhằm dành trọn năng lực cho luồng checkout cốt lõi. Bài tình huống cuối nhóm xây dựng pipeline gửi email chiến dịch quy mô lớn, kết hợp bounded queue, suppression list và token bucket phía client để không gửi trùng và không vi phạm chính sách của nhà cung cấp.

### 3. Giữ dữ liệu trong cache đúng khi tải cao

Tầng cache đóng vai trò then chốt trong việc giảm tải cho database, nhưng sự cố cache có thể đánh sập toàn bộ dịch vụ trong vài giây nếu thiết kế thiếu chặt chẽ. Bạn sẽ nắm vững nguyên tắc đặt cache key kèm các tham số làm biến đổi response, chuẩn hóa query string và phân tách dữ liệu chung với thông tin riêng của người dùng. Để tránh race condition khi cập nhật dữ liệu, khóa học hướng dẫn sử dụng tombstone kèm kiểm tra version qua Lua script trên Redis, đồng thời áp dụng single-flight và lock phân tán để triệt tiêu hiện tượng cache stampede. Bài tình huống flash deal trong livestream sẽ kết hợp cơ chế waiting room tự động kích hoạt, kỹ thuật chống stampede cho mọi key sản phẩm và câu lệnh cập nhật số lượng tồn kho có điều kiện.

### 4. Khi dependency chậm hoặc lỗi

Một dependency bên ngoài phản hồi chậm thường gây hậu quả nghiêm trọng hơn cả một service sập hoàn toàn, bởi nó giam giữ connection pool và làm cạn kiệt tài nguyên xử lý chung. Bạn sẽ phân bổ deadline budget qua từng chặng mạng để chặn các lời gọi mới khi đã quá hạn và truyền tín hiệu hủy xuống downstream, phân biệt rõ với việc provider bên thứ ba có thực sự dừng xử lý hay không. Kỹ thuật bulkhead giúp chia tách các connection pool riêng biệt theo từng luồng nghiệp vụ, kết hợp circuit breaker để ngắt mạch kịp thời và chuyển hướng sang kịch bản graceful degradation với mức phí chênh lệch được tính toán trước. Bài tình huống cuối chương trình giải quyết trọn vẹn sự cố một đối tác xác thực địa chỉ thỉnh thoảng phản hồi chậm kéo sập API bán hàng, đưa hệ thống trở lại trạng thái vận hành ổn định.

## Vì sao 200Lab tạo ra khóa học này

Những đợt sóng lưu lượng lớn trong thực tế thường ập đến bất ngờ từ một buổi livestream, một chiến dịch marketing hay một script cào dữ liệu tự động. Khi đó, phản xạ tự nhiên là scale thêm instance server, nhưng tiến trình khởi động và warm up thường mất vài phút trong khi toàn bộ hệ thống có thể tê liệt chỉ trong vài chục giây đầu tiên. Việc bổ sung instance vào thời điểm này thậm chí còn mở thêm kết nối dồn xuống database vốn đang nghẽn CPU, khiến tình trạng sụp đổ diễn ra nhanh hơn.

200Lab nhận thấy một nghịch lý phổ biến trong nhiều hệ thống: server vẫn hoạt động **100%** công suất CPU, nhưng số lượng giao dịch thành công ghi nhận trên dashboard lại rơi về gần bằng không. Nguyên nhân là hầu hết tài nguyên đang bị lãng phí để xử lý những request đã quá hạn timeout của client hoặc bị nghẽn trong các hàng chờ dài vô tận. Thay vì bảo vệ goodput, hệ thống lại cố gắng ôm đồm toàn bộ công việc vượt quá sức chứa để rồi sập toàn phần.

Các cơ chế phòng vệ hiệu quả nhất đôi khi chỉ nằm ở vài dòng code chuẩn xác: một biến đếm concurrency limit chặn đứng hàng chờ trong RAM, một token bucket bảo vệ hạn ngạch đối tác, hay một circuit breaker ngắt nhanh lời gọi tới dependency đang lỗi. Tuy nhiên, việc áp dụng chúng đòi hỏi người kỹ sư phải hiểu rõ các quy luật toán học về hàng chờ và sẵn sàng đưa ra các quyết định đánh đổi kỹ thuật dứt khoát.

200Lab xây dựng khóa học này nhằm giúp bạn thay đổi hoàn toàn vị thế khi đối mặt với tải cao. Thay vì phó mặc hệ thống cho may rủi và đối mặt với sự cố trong hoang mang, bạn sẽ nắm trong tay cơ sở lý thuyết cùng các công thức tính toán tường minh để chủ động thiết lập ranh giới bảo vệ, tự tin giải trình các phương án kỹ thuật và đảm bảo dịch vụ sống sót qua mọi đợt cao điểm.

## Những vấn đề thường gặp khi thiết kế hệ thống chịu tải cao

Khi độ trễ p99 tăng vọt, nhiều đội ngũ thường vội vã tối ưu câu lệnh database hoặc tăng thêm timeout và connection pool, nhưng những can thiệp này thường chỉ dời điểm nghẽn sang vị trí nguy hiểm hơn:

- Lưu lượng tăng khoảng **10,5%** nhưng p99 tăng gấp **15 lần** làm vỡ deadline hàng loạt — Thời gian chờ trong hàng đợi tăng vọt phi tuyến tính khi utilization tiến sát **100%**, khiến hầu hết thời gian phản hồi bị lãng phí vào việc xếp hàng trong RAM.
- Tăng connection pool của app để xóa thời gian chờ nhưng database chạm đỉnh **97%** CPU — Hàng chờ không biến mất mà bị đẩy trực tiếp vào database, khiến các truy vấn chen lấn tranh giành CPU và làm tăng độ trễ tổng thể.
- Load balancer loại bỏ toàn bộ instance khỏe mạnh chỉ trong vòng **25 giây** — Request kiểm tra health check bị xếp chung hàng đợi với lưu lượng thông thường nên timeout, kích hoạt hiệu ứng tuyết lở dồn tải sang các node còn lại.
- Container liên tục bị OOMKilled dù dashboard HTTP vẫn phản hồi nhanh với mã 202 — Service tiếp nhận dữ liệu nhanh hơn tốc độ ghi xuống đĩa nhưng sử dụng hàng chờ không giới hạn trong RAM, dẫn đến tràn bộ nhớ.
- Đã xóa key sau khi cập nhật dữ liệu nhưng người dùng vẫn thấy thông tin cũ — Request đọc dữ liệu cũ từ database bị nghẽn mạng hoặc dừng do bộ dọn rác, vô tình ghi đè lại giá trị cũ vào cache ngay sau khi lệnh xóa hoàn tất.
- CDN đạt hit ratio tổng rất cao nhưng origin server vẫn quá tải sau mỗi đợt chỉnh sửa — Bản sao lưu trên edge bị purge đồng loạt khiến 50 PoP cùng lúc miss và gửi request về origin để nạp lại dữ liệu.
- Gateway đã ngắt kết nối sau timeout nhưng backend vẫn tiếp tục xử lý tốn kém tài nguyên — Các tầng service phía sau không nhận biết deadline chung của request và không lắng nghe tín hiệu hủy kết nối từ client.
- Tỉ lệ lỗi HTTP và CPU vẫn ở mức an toàn nhưng giao dịch quan trọng bị treo cả chục giây — Một dependency bên ngoài phản hồi chậm làm cạn kiệt connection pool dùng chung, kéo theo các endpoint độc lập khác bị đình trệ do thiếu thread xử lý.

Tất cả tình huống kỹ thuật trên đều được mổ xẻ chi tiết trong các bài học, giúp bạn nhận diện chính xác nguyên nhân gốc rễ và áp dụng giải pháp khắc phục triệt để.

## Bạn sẽ học theo cách nào

- **Đặt người học vào tình huống trực vận hành** — Mỗi chủ đề bắt đầu bằng một biểu đồ cảnh báo đang đỏ rực, một đoạn log sự cố hay một dòng trace thực tế, yêu cầu bạn nhập cuộc chẩn đoán như một kỹ sư đang xử lý sự cố production.
- **Minh họa trực quan cơ chế tài nguyên và hàng đợi** — Mọi luồng dữ liệu, ranh giới connection pool và điểm tích tụ hàng chờ đều được sơ đồ hóa rõ ràng, đi kèm các công thức tính toán từng bước có ghi chú đơn vị cụ thể.
- **Lượng hóa mọi tham số cấu hình bằng số liệu** — Các thông số kỹ thuật như concurrency limit, kích thước pool, thời gian TTL hay ngưỡng kích hoạt breaker đều được xác định dựa trên số đo thực tế và yêu cầu đánh đổi của bài toán.
- **Thử thách tư duy qua câu hỏi dự đoán kỹ thuật** — Hệ thống câu hỏi ngắn xuyên suốt bài học yêu cầu bạn tính toán trước điểm gãy của hệ thống và dự đoán thời điểm chuyển đổi trạng thái của các cơ chế an toàn.
- **Kiểm chứng qua các kịch bản thực nghiệm chuyên sâu** — Mỗi bài tình huống lớn đi kèm kịch bản mô phỏng đầy đủ trạng thái trước và sau khi tối ưu, giúp bạn kiểm chứng cụ thể các chỉ số chịu tải dưới cùng một mức áp lực lưu lượng.

## Khóa học dành cho ai

1. **Backend developer trực tiếp vận hành hệ thống production** — Bạn cần nắm vững phương pháp tính toán tham số giới hạn, dung lượng pool và cấu hình timeout chuẩn xác để bảo vệ dịch vụ khi lưu lượng người dùng tăng đột biến.
2. **Kỹ sư phụ trách phát triển public API hoặc gateway** — Bạn cần các giải pháp phân bổ quota công bằng, kiểm soát tốc độ truy cập theo client và bảo vệ tài khoản dùng chung trước các hành vi khai thác quá mức.
3. **Kỹ sư kiến trúc chuẩn bị cho các đợt mở bán hoặc chiến dịch lớn** — Bạn là người chịu trách nhiệm thiết lập các van an toàn, hoạch định kịch bản suy giảm chức năng có kiểm soát và giải trình các quyết định đánh đổi kỹ thuật trước toàn đội ngũ.

## Những điều cần lưu ý

- **Yêu cầu kiến thức nền tảng về hệ thống phân tán** — Bạn cần nắm vững các khái niệm cơ bản về đo lường độ trễ percentile, định luật Little’s Law, cơ chế phân bổ kết nối mạng cũng như các kỹ thuật giao tiếp cơ bản như retry, backoff hay idempotency key; khóa học sẽ không giảng lại lý thuyết nhập môn mà tập trung đi thẳng vào cơ chế giải quyết quá tải.
- **Không bao gồm cấu hình công cụ hạ tầng chuyên biệt** — Chương trình không đi sâu vào việc hướng dẫn click chuột trên giao diện cloud provider, thiết lập autoscaling trên Kubernetes hay tinh chỉnh file cấu hình cụ thể của proxy phần cứng; trọng tâm là tư duy thiết kế và thuật toán bảo vệ để bạn tự tin làm chủ mọi công nghệ.
- **Số liệu trong bài học mang tính chất minh họa phương pháp** — Các thông số về capacity, hạn mức token hay thời gian xử lý trong giáo trình được xây dựng để làm sáng tỏ mối quan hệ toán học giữa các biến số; khi áp dụng vào thực tế, bạn cần chạy load test để thu thập số liệu đặc thù của hệ thống mình trước khi đưa vào công thức tính toán.

## Bắt đầu từ đâu

Khóa học bắt đầu ngay từ những diễn biến dồn dập trong bảy phút đầu tiên của một đợt sale lớn: lưu lượng đổ về tăng gấp ba lần nhưng lượng request hoàn thành kịp thời hạn lại rơi tự do từ **2.000** xuống đáy **700 request/giây**. Bài toán đầu tiên đặt ra một nghịch lý kỹ thuật: Nếu hệ thống kiên quyết từ chối bớt các request vượt quá sức chứa để tập trung phục vụ đúng capacity **3.000 request/giây**, số lượng giao dịch thành công thực tế sẽ tăng lên hay giảm đi? Kết quả tính toán cho thấy goodput có thể tăng tối đa khoảng **4,3 lần**, và để chạm tới ngưỡng trần này, bạn cần phối hợp nhịp nhàng các tầng bảo vệ từ độ trễ, lưu lượng cho đến phân lập lỗi dependency.

## Chương trình

- Khi quá tải, hệ thống nên bỏ bớt việc thay vì sập toàn bộ (miễn phí)
- Vì sao API gọi song song nhiều service có p99 cao hơn hẳn p99 của từng service (miễn phí) · quiz
- Vì sao p99 tăng vọt khi service chạy gần hết capacity (miễn phí) · quiz
- Connection pool nên lớn bao nhiêu và request nên chờ ở app hay trong database · quiz
- Dùng rate limiting để một client không làm chậm mọi người dùng khác · quiz
- Giới hạn token cho từng đối tác trên LLM gateway · kit cho agent
- Waiting room: cho người dùng vào theo lượt khi biết trước giờ cao điểm
- Khi service quá tải, nên từ chối request nào trước và từ chối ở tầng nào · quiz
- Hàng chờ trong RAM phình to khi service nhận việc nhanh hơn tốc độ xử lý
- Thiết kế pipeline email chăm sóc khách hàng không gửi trùng, không vượt hạn mức · kit cho agent
- Đặt cache key và chọn TTL để cache có hit ratio cao mà không trả nhầm dữ liệu
- Đã xóa key cache sau khi đổi giá mà khách vẫn thấy giá cũ · quiz
- Cache stampede: một key hết hạn và hàng nghìn request cùng đổ xuống database · quiz
- Cập nhật nội dung trên CDN mà không làm origin quá tải
- Flash deal trong livestream khi không biết trước lúc nào tải tăng vọt · kit cho agent
- Chia deadline của một request cho các service mà nó đi qua · quiz
- Không để một loại request nặng chiếm hết connection của cả service · quiz
- Circuit breaker: ngừng gọi dependency đang lỗi thay vì lần nào cũng chờ timeout · quiz
- Giữ cho luồng quan trọng vẫn chạy khi một dependency bị hỏng
- Service bên ngoài chỉ thỉnh thoảng chậm mà cả API chậm theo · kit cho agent