Thời lượng: 20 phút
Level: Advanced
Yêu cầu: Đã hiểu về API Key và Caching.
Mục tiêu bài học
Sau bài học này, bạn sẽ:
- Hiểu tầm quan trọng của Rate Limiting trong việc ổn định hệ thống.
- Nắm vững 3 thuật toán phổ biến: Fixed Window, Sliding Window và Token Bucket.
- Thiết kế được Header trả về khi người dùng bị giới hạn tốc độ.
Nội dung chính
1. Tại sao cần Rate Limiting?
Nếu không có giới hạn, một user (hoặc robot) vô tình hay cố ý có thể gửi hàng nghìn request mỗi giây, làm nghẽn băng thông và chiếm dụng toàn bộ tài nguyên CPU của server.
Rate Limiting giúp:
- Chống tấn công Brute-force (dò mật khẩu).
- Chống Spam (gửi bình luận, tin nhắn liên tục).
- Đảm bảo công bằng cho mọi người dùng (Fair use policy).
- Tiết kiệm chi phí (Nếu bạn dùng các API trả phí theo lượt gọi).
2. Các thuật toán phổ biến
A. Fixed Window (Cửa sổ cố định)
Giới hạn 100 req mỗi phút bắt đầu từ giây thứ 0 đến giây thứ 60.
- Vấn đề: Có thể bị lọt gấp đôi số request vào thời điểm giao thoa giữa 2 phút (giây thứ 59 và giây thứ 1 của phút sau).
B. Token Bucket (Xô chứa Token) - Khuyên dùng
Server có một cái xô dung tích N tokens. Mỗi request tiêu tốn 1 token. Tokens được nạp lại vào xô sau mỗi khoảng thời gian đều đặn.
- Ưu điểm: Cho phép xử lý các đợt bùng nổ request (Bursting) ngắn hạn.
C. Sliding Window Log (Cửa sổ trượt)
Ghi lại timestamp của mọi request. Chính xác nhất nhưng tốn bộ nhớ nhất.
3. HTTP Header & Status Code
Khi user vượt ngưỡng, API PHẢI trả về mã trạng thái 429 Too Many Requests.
Ngoài ra, nên trả về các Header để hướng dẫn Client:
X-RateLimit-Limit: Tổng giới hạn (100).X-RateLimit-Remaining: Số lượt còn lại (5).Retry-After: Số giây phải đợi trước khi thử lại (30).
Nguyên tắc then chốt
"Áp dụng Rate Limiting ở nhiều tầng khác nhau."
- Lớp Infrastructure (Cloudflare/WAF): Chặn các đợt tấn công DDOS quy mô lớn dựa trên địa chỉ IP.
- Lớp API Gateway: Giới hạn dựa trên API Key/User ID cho các nghiệp vụ cụ thể.
Thực hành
Bài tập 1: Thiết kế giới hạn cho API "Gửi mã OTP"
Bối cảnh: Gửi OTP tốn tiền SMS và dễ bị hacker lợi dụng để spam người dùng.
Yêu cầu:
- Bạn sẽ thiết lập giới hạn như thế nào (số lượng/thời gian)?
- Bạn dùng định danh gì để limit (IP hay Số điện thoại)?
Xem đáp án mẫu
- Giới hạn: Tối đa 1 mã/phút và 5 mã/ngày cho một đối tượng.
- Định danh: Phải kết hợp cả Số điện thoại (tránh spam 1 người) và IP (tránh 1 máy hack nhiều người).
- Thuật toán: Token Bucket là phù hợp nhất để cho phép user "thử lại" nhanh 1-2 lần nếu gõ sai, nhưng không được vượt quá 5 lần.
Tình huống thực tế
Scenario 1: Người dùng VIP
Bối cảnh: Bạn có gói Free (10 req/s) và gói Pro (100 req/s). Làm sao hệ thống Rate Limit biết ai là ai để áp dụng luật?
Giải quyết: Hệ thống Rate Limit (thường là Middleware) sẽ:
- Xác thực User từ JWT/API Key.
- Tra cứu Level của user từ Cache (Redis).
- Lấy con số limit tương ứng từ cấu trúc cấu hình (
CONFIG['PRO_LIMIT']). - Thực hiện đếm trong Redis dựa trên ID của user.
Câu hỏi phỏng vấn
Senior Level
- Q: "Distributed Rate Limiting" là gì? Tại sao không nên dùng bộ nhớ local của server để làm Rate Limit? A: Nếu bạn có 5 server chạy đằng sau Load Balancer, nếu dùng bộ nhớ local, user có thể gửi 100 request vào server 1, rồi lại 100 request vào server 2... Tổng cộng user vượt ngưỡng nhưng không bị chặn. Chúng ta phải dùng một bộ lưu trữ tập trung như Redis để mọi server cùng nhìn thấy một con số đếm duy nhất.
Tóm tắt
Những điều cần nhớ
- Dùng mã lỗi 429 cho việc vượt ngưỡng.
- Cung cấp thông tin Retry-After cho client.
- Dùng Redis để triển khai Rate Limit trong môi trường phân tán.
Bước tiếp theo
Trong bài tiếp theo, bạn sẽ học về Lesson 7.3: Circuit Breakers - Cách bảo vệ hệ thống khi các service con bị lỗi kéo theo.