API Rate Limit Là Gì? Cách Xử Lý Giới Hạn API Trong Vnstock

Bạn đang chạy chương trình phân tích dữ liệu chứng khoán Việt Nam thì bỗng dưng gặp báo lỗi "RateLimitExceed: Bạn đã gửi quá nhiều request đến VCI¹. Vui lòng thử lại sau 15 giây." sau đó chương trình tự thoát thì đây là bài viết dành cho bạn.

I. API² Rate Limit là gì?

Các loại API Rate Limit phổ biến

1. Rate limit theo thời gian:
   • Request/giây (RPS)
   • Request/phút (RPM)
   • Request/giờ (RPH)
   • Request/ngày (RPD)
2. Rate limit theo nguồn:
   • Theo IP
   • Theo tài khoản/API key
   • Theo ứng dụng
3. Rate limit theo endpoint:
   • Giới hạn khác nhau cho từng endpoint cụ thể
   • Giới hạn chung cho toàn bộ API

Cách nhận biết khi đạt giới hạn request của API

Khi đạt đến giới hạn request hay Rate Limit, API thường trả về mã lỗi HTTP 429³ cùng với thông báo lỗi cụ thể. Nhiều API còn cung cấp thông tin trong header response⁴ về số request còn lại, thời gian đợi trước khi có thể gọi lại API, v.v.

II. API Rate Limit của thư viện vnstock

vnstock là thư viện Python mã nguồn mở, cung cấp các công cụ truy xuất và phân tích dữ liệu chứng khoán Việt Nam. Thư viện này được nhiều nhà đầu tư, nhà phân tích tài chính và lập trình viên tin dùng để phân tích thị trường chứng khoán Việt Nam.

Khi vnstock phát hiện chương trình bạn đang thực thi sử dụng cấu trúc vòng lặp để tải dữ liệu với tần suất cao, một cảnh báo sẽ xuất hiện, chương trình vẫn tiếp tục thực thi cho đến khi dừng lại do vượt quá giới hạn cho phép.

Thông báo về giới hạn API (rate limit) trong Vnstock

Trong môi trường dòng lệnh (Terminal/Command Prompt), bạn sẽ nhận được thông báo dưới đây.

╔═════════════════════════════════════════════════════════════════╗
║                                                                 ║
║   🚫 BẠN ĐANG GẶP LỖI GIỚI HẠN TẦN SUẤT GỌI API?                ║
║                                                                 ║
║   ✓ Tăng giới hạn Rate Limit dành cho thành viên tài trợ        ║
║   ✓ Tối ưu hóa thời gian chờ giữa các request                   ║
║                                                                 ║
║   ➤ THAM KHẢO VÀ NÂNG CẤP GÓI TÀI TRỢ VNSTOCK:                  ║
║     https://vnstocks.com/insiders-program                       ║
║                                                                 ║
╚═════════════════════════════════════════════════════════════════╝

Giới hạn hiện tại của vnstock

Hiện tại, vnstock áp dụng các giới hạn khi gửi yêu cầu dữ liệu từ API như sau:

• 60 requests/phút
• 3000 requests/giờ

Khi số lượt yêu cầu API trong thư viện Vnstock vượt quá giới hạn, chương trình tự động dừng thực thi và hiển thị thông báo lỗi. Đây là dấu hiệu cho thấy chương trình của bạn đã gửi quá nhiều request trong khoảng thời gian quy định mà chưa thực sự tối ưu.

Thông báo lỗi API Rate Limit

III. Vì sao vnstock áp dụng API Rate Limit?

Có nhiều lý do khiến việc áp dụng cơ chế Rate Limit là cần thiết cho một dự án và nhất là với dự án cộng đồng như vnstock:

1. Duy trì sự ổn định hệ thống cho cộng đồng

API Rate Limit giúp phân bổ tài nguyên máy chủ cân bằng giữa người dùng, tránh tình trạng quá tải cục bộ ảnh hưởng đến hiệu năng chung. Với người dùng cá nhân, việc tuân thủ giới hạn giúp hạn chế rủi ro địa chỉ IP cá nhân bị chặn truy cập từ phía nhà cung cấp dữ liệu.

2. Sử dụng public API có trách nhiệm

Cơ chế Rate Limit giúp bảo vệ hệ thống khỏi việc quá tải do các yêu cầu gửi liên tục. Việc này đảm bảo tính ổn định và duy trì kết nối thông suốt giữa các công cụ phân tích và nguồn cung cấp dữ liệu.

3. Phân bổ nguồn lực hiệu quả

Vnstock là dự án mã nguồn mở được thiết kế để hỗ trợ cộng đồng làm quen với Python và phân tích dữ liệu tài chính cho nhu cầu cá nhân. Nếu cần khai thác dữ liệu chuyên sâu với tần suất cao phục vụ công việc, việc nâng cấp lên gói tài trợ sẽ cung cấp tài nguyên lớn hơn và giúp duy trì dự án.

4. Bảo vệ hệ thống

API Rate Limit cũng là cách bảo vệ hệ thống trước các nguy cơ tấn công từ chối dịch vụ (DDoS)⁵ hoặc các truy cập bất thường từ bot tự động.

IV. Năm phương án xử lý API Rate Limit

Khi làm việc với vnstock API, bạn có thể áp dụng một số chiến lược sau để xử lý vấn đề Rate Limit:

1. Bổ sung thời gian nghỉ giữa các requests

Đây là phương pháp đơn giản nhất, thêm thời gian nghỉ (delay) giữa các lần gọi API để đảm bảo không vượt quá giới hạn khi bạn sử dụng cơ chế vòng lặp để tải dữ liệu.

import time
from tqdm import tqdm
from vnstock import Vnstock

stock = Vnstock().stock(symbol='ACB', source='VCI')
# Truy xuất danh sách mã trong VN100
vn100 = stock.listing.symbols_by_group('VN100')
# Tạo vòng lặp tải dữ liệu, sử dụng tqdm[^7] hiển thị tiến độ
for symbol in tqdm(vn100, desc='Processing VN100 symbols'):
	df = stock.quote.history(symbol=symbol, start='2024-01-01', end='2024-12-31')
	df['symbol'] = symbol
	print(df)
	# nghỉ 1s trước khi chuyển sang mã tiếp theo
	time.sleep(1)

• Ưu điểm: Dễ thực hiện.
• Nhược điểm: Làm tăng đáng kể thời gian chạy chương trình. Việc đặt độ trễ cố định (hard delay) chưa tối ưu được hiệu suất do tốc độ phản hồi của các request thực tế không giống nhau.

2. Tối ưu nguồn dữ liệu

Hiểu đặc tính của từng nguồn dữ liệu trong Vnstock giúp bạn tối ưu các tài nguyên miễn phí. Dưới đây là một số gợi ý giúp bạn sáng tạo giải pháp cho riêng mình.

• Giới hạn Rate Limit được tính độc lập theo từng nguồn (ví dụ: nguồn VCI và nguồn TCBS⁶ có bộ đếm riêng).
• Nguồn TCBS không tối ưu cho việc tải dữ liệu lịch sử OHLCV⁷ liên tục nhiều năm, vì Vnstock sẽ phải thực hiện nhiều request phụ để vá dữ liệu.
• Bạn có thể tối ưu bằng cách kết hợp linh hoạt giữa các nguồn dữ liệu khác nhau tùy theo loại dữ liệu cần truy vấn.

3. Thiết lập bộ đếm và cơ chế tránh Rate Limit

Phương pháp này giúp theo dõi số lượng request đã gửi và tự động điều chỉnh tốc độ gọi API. Bạn có thể tạo một bộ đếm đơn giản để theo dõi số lượng request và tự động tạm dừng khi đạt gần đến giới hạn.

Nguyên tắc hoạt động:

• Theo dõi số lượng request đã thực hiện trong 1 phút

• Nếu sắp đạt giới hạn, tự động đợi trước khi tiếp tục

• Reset bộ đếm sau mỗi phút

• Ưu điểm: Quản lý request chủ động, tối ưu hóa thời gian chờ

• Nhược điểm: Cần thêm logic để quản lý bộ đếm

4. Sử dụng caching để giảm số lượng request

Lưu trữ kết quả API để tránh gọi lại những dữ liệu đã lấy trước đó.

Nguyên tắc hoạt động:

• Lưu kết quả vào file hoặc bộ nhớ sau khi gọi API

• Kiểm tra cache trước khi gọi API

• Chỉ gọi API khi dữ liệu không có trong cache hoặc đã hết hạn

• Ưu điểm: Giảm đáng kể số lượng request, tối ưu hiệu suất trong dài hạn

• Nhược điểm: Dữ liệu có thể không phải là mới nhất khi lấy từ cache

5. Sử dụng thuật toán Exponential Backoff⁸

Phương pháp này tăng dần thời gian chờ sau mỗi lần gặp lỗi Rate Limit.

Nguyên tắc hoạt động:

• Bắt đầu với thời gian chờ ngắn (ví dụ: 1 giây)

• Khi gặp lỗi Rate Limit, tăng thời gian chờ theo cấp số nhân

• Thử lại request sau thời gian chờ

• Thêm yếu tố ngẫu nhiên để tránh đồng bộ hóa giữa các client

• Ưu điểm: Xử lý lỗi tự động, thích ứng với điều kiện mạng và tải hệ thống

• Nhược điểm: Có thể mất nhiều thời gian hơn nếu gặp nhiều lỗi liên tiếp

V. Sử dụng giới hạn lớn hơn với gói tài trợ Vnstock

Lợi ích khi nâng cấp

• Tiết kiệm thời gian: Hạn chế việc phải viết thêm các cơ chế trì hoãn phức tạp trong mã nguồn.
• Tốc độ truy xuất tối ưu: Sử dụng hạ tầng băng thông tốt hơn và cơ chế truy cập song song.
• Mở rộng dữ liệu: Hỗ trợ truy cập thêm các nguồn dữ liệu chuyên sâu và bộ lọc nâng cao.
• Đóng góp cho dự án: Giúp duy trì hạ tầng máy chủ và hỗ trợ phát triển các tính năng mới cho cộng đồng.

VI. Câu hỏi thường gặp

Tôi có thể tự nâng giới hạn API mà không cần gói tài trợ không?

Giới hạn API được quản lý ở cả phía máy chủ để bảo vệ nguồn dữ liệu, do đó bạn không thể tự ý thay đổi trong mã nguồn máy khách. Bạn chỉ có thể tối ưu bằng các chiến lược điều tiết lưu lượng như trì hoãn request, caching hoặc cân nhắc sử dụng gói tài trợ để nâng giới hạn mặc định.

Làm sao để biết tôi đã sử dụng bao nhiêu request?

Hiện tại, Vnstock chưa hỗ trợ tính năng xem trực tiếp số lượng request đã gọi trong phiên. Bạn nên chủ động ghi log hoặc xây dựng bộ đếm thời gian trong ứng dụng của mình để theo dõi và điều chỉnh tần suất cho phù hợp.

Tôi bị rate limit dù chỉ gửi rất ít request?

Có thể do ứng dụng của bạn gọi các hàm khác nhau nhưng chúng đều truy vấn dữ liệu từ cùng một nguồn ẩn dưới nền, dẫn đến tổng số request cộng dồn đạt giới hạn cho phép.