Rate Limiting Là Gì? Hướng Dẫn Đơn Giản Cho Người Xây Dựng Ứng Dụng
Rate limiting là quy tắc giới hạn số yêu cầu một người có thể gửi đến một hệ thống trong một khoảng thời gian nhất định — ví dụ 5 lần đăng nhập mỗi phút, hoặc 100 lời gọi API mỗi giờ. Khi đạt đến giới hạn, các yêu cầu tiếp theo sẽ bị từ chối (thường với mã lỗi 429 Too Many Requests) cho đến khi khoảng thời gian làm mới. Nó bảo vệ ứng dụng khỏi lạm dụng, ngăn một người dùng “nặng ký” làm chậm mọi người khác, và chặn chi phí tăng ngoài tầm kiểm soát.
Bạn gặp rate limiting từ hai phía: các dịch vụ bạn gọi giới hạn bạn, và chính ứng dụng của bạn nên giới hạn người dùng của nó.
Vì sao rate limiting quan trọng khi bạn xây dựng với AI
Các ứng dụng xây bằng AI thường kết nối với những dịch vụ trả phí — mô hình AI, email, SMS, bản đồ — và mỗi lời gọi đều tốn tiền. Điều đó khiến rate limiting vừa là tính năng bảo mật, vừa là công cụ kiểm soát ngân sách.
- Kiểm soát chi phí. Nếu ứng dụng của bạn có ô “hỏi AI” mà không có giới hạn, một bot có thể gửi hàng nghìn yêu cầu qua đêm. Bạn trả tiền cho từng yêu cầu đó.
- Bảo mật. Nếu form đăng nhập không có giới hạn, kẻ tấn công có thể thử hàng nghìn mật khẩu với một tài khoản. Giới hạn vài lần thử mỗi phút khiến việc này trở nên bất khả thi.
- Giữ cho ứng dụng hoạt động. Một đoạn script chạy sai — đôi khi chính là mã của bạn bị kẹt trong vòng lặp — có thể làm quá tải cơ sở dữ liệu và khiến ứng dụng ngừng hoạt động.
- Tôn trọng giới hạn của dịch vụ khác. Khi ứng dụng gọi một API bên ngoài quá thường xuyên, bạn sẽ nhận lỗi 429, và các tính năng bị lỗi với người dùng của bạn.
Công cụ tạo ứng dụng AI sẽ xây dựng đúng những gì bạn yêu cầu. Nếu bạn không đề cập đến giới hạn, chúng thường bị bỏ qua.
Một ví dụ đời thường
Hãy nghĩ đến chính sách rót thêm cà phê miễn phí của một quán: “Mỗi khách được rót thêm một lần miễn phí mỗi lượt ghé.”
- Chính sách này không ngăn ai thưởng thức cà phê.
- Nó ngăn một người đứng ở quầy rót liên tục cả buổi để lấy cà phê cho cả văn phòng.
- Khi có người xin lần rót thứ tư, nhân viên lịch sự nói “hiện tại chưa được” — đó chính là
429.
Một giới hạn tốt thì khách bình thường không hề nhận ra, chỉ người làm điều bất thường mới thấy.
Rate limiting hoạt động thế nào
Một bộ giới hạn cần ba thứ:
| Thành phần | Trả lời câu hỏi | Ví dụ |
|---|---|---|
| Ai | Yêu cầu của ai được đếm? | Theo tài khoản người dùng, theo địa chỉ IP, theo API key |
| Bao nhiêu | Giới hạn là bao nhiêu? | 5, 60, 1.000 yêu cầu |
| Trong bao lâu | Trong khoảng thời gian nào? | Mỗi giây, phút, giờ, ngày |
Khi một yêu cầu đến, ứng dụng kiểm tra số đếm cho “ai” đó. Nếu dưới giới hạn: yêu cầu được xử lý và số đếm tăng lên. Nếu vượt giới hạn: yêu cầu bị từ chối.
Có một số cách đếm phổ biến:
| Phương pháp | Cách hoạt động | Đánh đổi |
|---|---|---|
| Cửa sổ cố định (fixed window) | Bộ đếm reset theo đồng hồ — ví dụ mỗi phút đúng giờ | Đơn giản, nhưng cho phép bùng phát ở ranh giới giữa hai cửa sổ |
| Cửa sổ trượt (sliding window) | Nhìn vào 60 giây gần nhất tính từ bây giờ | Mượt hơn, tính toán phức tạp hơn một chút |
| Token bucket | Mỗi người dùng có một “xô” được nạp đều đặn; mỗi yêu cầu lấy đi một token | Cho phép bùng phát ngắn nhưng giữ mức trung bình ổn định |
Số đếm cần được lưu ở nơi nhanh và dùng chung. Trên một máy chủ nhỏ, bộ nhớ là đủ. Khi ứng dụng chạy trên nhiều máy, bộ đếm thường nằm trong một kho dùng chung như Redis hoặc cơ sở dữ liệu; nếu không, mỗi máy đếm riêng và giới hạn thực tế sẽ lớn hơn nhiều lần.
Phản hồi khi bị giới hạn trông như thế nào
Khi một yêu cầu vượt giới hạn, một API được thiết kế tốt sẽ trả về:
- Mã trạng thái
429 Too Many Requests. - Thường có header
Retry-After, cho biết cần chờ bao nhiêu giây. - Đôi khi có các header cho biết giới hạn của bạn và số yêu cầu còn lại trong khoảng thời gian này (tên khác nhau tùy nhà cung cấp).
Ứng dụng của bạn nên xử lý lỗi 429 bằng cách chờ rồi thử lại sau — lý tưởng nhất là dùng exponential backoff, nghĩa là chờ lâu hơn sau mỗi lần thất bại (1 giây, rồi 2, rồi 4) thay vì dồn dập gọi lại dịch vụ.
Ví dụ minh họa: một trợ lý viết AI
Giả sử bạn xây một ứng dụng nơi người dùng dán văn bản vào và nhận lại bản viết lại do AI tạo.
Không có giới hạn: ai đó viết một script gửi 20.000 yêu cầu qua đêm. Hóa đơn nhà cung cấp AI tăng vọt, tài khoản của bạn chạm giới hạn của chính nhà cung cấp, và người dùng thật thấy lỗi suốt buổi sáng.
Với giới hạn hợp lý:
- Theo từng người dùng đã đăng nhập: 30 lần viết lại mỗi giờ với gói miễn phí, 300 lần với gói trả phí. Khi vượt giới hạn, người dùng thấy: “Bạn đã dùng hết giới hạn của giờ này. Hãy thử lại sau 12 phút, hoặc nâng cấp.”
- Theo địa chỉ IP ở form đăng ký: 5 lần đăng ký mỗi giờ, để ngăn bot tạo hàng nghìn tài khoản miễn phí nhằm vượt qua giới hạn theo người dùng.
- Giới hạn chi tiêu đặt trong bảng điều khiển của nhà cung cấp AI, như lớp phòng thủ cuối cùng nếu mọi thứ khác thất bại.
- Xử lý giới hạn của nhà cung cấp: nếu nhà cung cấp AI trả về 429, máy chủ của bạn chờ rồi thử lại một hoặc hai lần, sau đó hiển thị thông báo thân thiện “hệ thống đang bận, vui lòng thử lại”.
Giới hạn phải được kiểm tra trên máy chủ. Một giới hạn chỉ tồn tại trong trình duyệt — chẳng hạn vô hiệu hóa nút sau 30 lần nhấp — có thể bị vượt qua bởi bất kỳ ai gọi trực tiếp API của bạn.
Thuật ngữ chính
| Thuật ngữ | Ý nghĩa |
|---|---|
| Rate limit | Số yêu cầu tối đa được phép trong một khoảng thời gian. |
| Quota (hạn ngạch) | Mức cho phép lớn hơn, thường theo ngày hoặc tháng, đôi khi gắn với gói trả phí. |
| 429 | Mã trạng thái HTTP cho “quá nhiều yêu cầu”. |
| Retry-After | Header phản hồi cho biết cần chờ bao lâu trước khi thử lại. |
| Throttling | Làm chậm hoặc từ chối yêu cầu vượt giới hạn. Thường được dùng như từ đồng nghĩa. |
| Exponential backoff | Chờ lâu hơn dần giữa các lần thử lại. |
| Burst (bùng phát) | Một đợt tăng đột ngột nhiều yêu cầu cùng lúc. |
| Brute-force | Thử hàng loạt mật khẩu hoặc mã cho đến khi tìm đúng. |
Những hiểu lầm thường gặp
- “Rate limiting chỉ dành cho ứng dụng lớn.” Ứng dụng nhỏ cũng là mục tiêu, vì bot quét khắp internet tìm form và endpoint AI không được bảo vệ. Chi phí của việc lạm dụng không phụ thuộc vào quy mô của bạn.
- “Ẩn nút là đủ rồi.” Giới hạn phía trình duyệt chỉ là sự lịch sự, không phải bảo vệ. Giới hạn thực sự phải được thực thi trên máy chủ.
- “Giới hạn theo IP luôn công bằng.” Nhiều người có thể dùng chung một địa chỉ IP — một văn phòng, một trường học, một mạng di động. Khi mọi người đã đăng nhập, giới hạn theo người dùng sẽ công bằng hơn.
- “Lỗi 429 nghĩa là dịch vụ bị hỏng.” Nó nghĩa là bạn đang gọi quá thường xuyên. Hãy kiểm tra mã có vòng lặp không, và lưu cache các kết quả ít thay đổi — xem caching là gì.
- “Rate limiting thay thế được giới hạn chi tiêu.” Hãy dùng cả hai. Giới hạn trong ứng dụng có thể có lỗi; giới hạn chi tiêu của nhà cung cấp là lớp bảo vệ cuối cùng.
Nên hỏi công cụ tạo ứng dụng AI điều gì
- “Thêm rate limiting phía máy chủ cho đăng nhập, đăng ký, đặt lại mật khẩu và endpoint AI. Gợi ý các giới hạn hợp lý.”
- “Giới hạn mỗi người dùng đã đăng nhập ở [N] yêu cầu AI mỗi giờ, và hiển thị thông báo rõ ràng kèm thời gian chờ khi họ chạm giới hạn.”
- “Khi một API bên ngoài trả về 429, thử lại với exponential backoff tối đa 3 lần, sau đó hiển thị lỗi thân thiện.”
- “Các bộ đếm rate limit được lưu ở đâu? Chúng có còn hoạt động khi ứng dụng chạy trên nhiều máy không?”
- “Ghi lại mỗi khi người dùng hoặc IP chạm giới hạn, để tôi phát hiện lạm dụng.”
- “Ứng dụng này gọi những dịch vụ bên ngoài nào, và giới hạn của chúng là bao nhiêu?”
Rate limiting trong Mythex
Tài liệu của Mythex nói rõ về điều này đối với các tính năng AI: giới hạn tốc độ, an toàn và kiểm soát chi phí trong các ứng dụng bạn xây dựng là việc của bạn để thiết kế — xem Xây dựng ứng dụng AI. Hãy yêu cầu agent thêm giới hạn ngay trong cùng tin nhắn khi bạn yêu cầu tính năng. Trên gói Pro, một dịch vụ đã xuất bản có thể chạy trên tối đa ba máy khi lưu lượng lớn (xem Giới hạn lưu trữ), vì vậy hãy yêu cầu các bộ đếm được lưu trong cơ sở dữ liệu thay vì bộ nhớ của một máy chủ.
Đọc thêm: API là gì, cách dùng LLM API và danh sách kiểm tra bảo mật cho ứng dụng xây bằng AI.
Câu hỏi thường gặp
Rate limiting là gì, nói đơn giản?
Rate limiting là quy tắc giới hạn số yêu cầu một người dùng, thiết bị hoặc ứng dụng có thể gửi trong một khoảng thời gian — ví dụ 5 lần đăng nhập mỗi phút hoặc 100 lời gọi API mỗi giờ. Các yêu cầu vượt giới hạn sẽ bị từ chối cho đến khi khoảng thời gian làm mới.
Lỗi 429 Too Many Requests nghĩa là gì?
Mã trạng thái HTTP 429 nghĩa là bạn đã gửi quá nhiều yêu cầu trong thời gian quá ngắn và chạm giới hạn. Phản hồi thường kèm header Retry-After cho biết cần chờ bao lâu. Cách khắc phục là gửi chậm lại, thử lại sau một khoảng nghỉ, hoặc giảm tần suất ứng dụng gọi dịch vụ.
Vì sao ứng dụng dùng AI của tôi cần rate limiting?
Mỗi yêu cầu AI đều tốn tiền theo token. Nếu không có giới hạn, một người dùng hoặc một bot có thể gửi hàng nghìn yêu cầu, làm hóa đơn tăng vọt hoặc cạn hạn ngạch của nhà cung cấp, khiến tính năng ngừng hoạt động với tất cả mọi người. Giới hạn theo từng người dùng giúp chi phí dễ dự đoán.
Rate limiting có giống throttling không?
Hai khái niệm này rất gần nhau và thường được dùng thay thế cho nhau. Rate limiting thường nghĩa là từ chối các yêu cầu vượt giới hạn, còn throttling cũng có thể nghĩa là làm chậm chúng lại hoặc xếp hàng thay vì từ chối ngay.
Rate limiting có ngăn được tấn công DDoS không?
Nó giúp chống các đợt tràn yêu cầu nhỏ và hành vi lạm dụng từ từng người dùng hoặc địa chỉ IP, nhưng một cuộc tấn công phân tán quy mô lớn đến từ rất nhiều địa chỉ cùng lúc. Việc bảo vệ trước những cuộc tấn công đó thường diễn ra ở tầng mạng hoặc CDN, trước khi lưu lượng đến ứng dụng của bạn.