Vì API REST của Google Meet là một dịch vụ dùng chung, nên chúng tôi áp dụng các hạn mức và giới hạn để đảm bảo mọi người dùng đều sử dụng API này một cách công bằng, cũng như để bảo vệ hiệu suất chung của hệ thống Google Workspace.
Nếu vượt quá hạn mức, bạn thường sẽ nhận được phản hồi của mã trạng thái HTTP 429: Too many requests. Nếu điều này xảy ra, bạn nên sử dụng thuật toán thời gian đợi luỹ thừa và thử lại sau. Miễn là bạn duy trì trong hạn mức mỗi phút, sẽ không có giới hạn về số lượng yêu cầu bạn có thể thực hiện mỗi ngày.
Bảng sau đây trình bày chi tiết các giới hạn truy vấn:
| Hạn mức | |||||
|---|---|---|---|---|---|
| Đọc yêu cầu |
|
||||
| Ghi yêu cầu |
|
||||
|
Giảm yêu cầu ghi
(Được sử dụng cho |
|
||||
Giải quyết lỗi hạn mức dựa trên thời gian
Đối với mọi lỗi theo thời gian (tối đa N yêu cầu trong mỗi X phút), mã của bạn nên phát hiện ra ngoại lệ và sử dụng tính năng thời gian đợi luỹ thừa bị cắt ngắn để đảm bảo thiết bị không tạo ra quá tải.
Thuật toán thời gian đợi luỹ thừa là một chiến lược xử lý lỗi chuẩn cho các ứng dụng mạng. Thuật toán thời gian đợi luỹ thừa thử lại các yêu cầu bằng cách sử dụng thời gian chờ tăng theo cấp số nhân giữa các yêu cầu, lên đến thời gian đợi tối đa. Nếu yêu cầu vẫn không thành công, điều quan trọng là độ trễ giữa các yêu cầu sẽ tăng lên theo thời gian cho đến khi yêu cầu được thực hiện thành công.
Thuật toán mẫu
Thuật toán thời gian đợi luỹ thừa sẽ thử lại các yêu cầu theo cấp số nhân, tăng thời gian chờ giữa các lần thử lại cho đến thời gian đợi tối đa. Ví dụ:
- Gửi yêu cầu đến API Google Meet.
- Nếu yêu cầu không thành công, hãy đợi 1 +
random_number_millisecondsrồi thử lại yêu cầu. - Nếu yêu cầu không thành công, hãy đợi 2 +
random_number_millisecondsrồi thử lại yêu cầu. - Nếu yêu cầu không thành công, hãy đợi 4 +
random_number_millisecondsrồi thử lại yêu cầu. - Và cứ thế, tối đa
maximum_backofflần. - Tiếp tục chờ và thử lại với số lần thử lại tối đa, nhưng không được tăng thời gian chờ giữa các lần thử lại.
trong đó:
- Thời gian chờ là
min(((2^n)+random_number_milliseconds), maximum_backoff), trong đóntăng thêm 1 cho mỗi lần lặp lại (yêu cầu). random_number_millisecondslà một số mili giây ngẫu nhiên nhỏ hơn hoặc bằng 1.000. Điều này giúp tránh trường hợp nhiều ứng dụng được đồng bộ hoá trong một số tình huống và tất cả đều thử lại cùng một lúc, gửi yêu cầu dưới dạng các giai đoạn được đồng bộ hoá. Giá trị củarandom_number_millisecondssẽ được tính toán lại sau mỗi yêu cầu thử lại.maximum_backoffthường là 32 hoặc 64 giây. Giá trị thích hợp tuỳ thuộc vào trường hợp sử dụng.
Ứng dụng có thể tiếp tục thử lại sau khi đã đạt đến thời gian maximum_backoff.
Các lần thử lại sau thời điểm này không cần phải tiếp tục tăng thời gian đợi. Ví dụ: nếu sử dụng thời gian maximum_backoff là 64 giây, thì sau khi đạt đến giá trị này, ứng dụng có thể thử lại sau mỗi 64 giây. Tại một thời điểm nào đó, bạn nên ngăn ứng dụng thử lại vô thời hạn.
Thời gian chờ giữa các lần thử lại và số lần thử lại phụ thuộc vào trường hợp sử dụng và điều kiện mạng của bạn.
Giá
Mọi người đều có thể sử dụng API Google Meet mà không mất thêm phí. Khi vượt quá hạn mức yêu cầu, bạn sẽ không bị tính thêm phí và tài khoản của bạn sẽ không bị tính phí.
Yêu cầu tăng hạn mức
Tuỳ thuộc vào mức sử dụng tài nguyên của dự án, bạn nên yêu cầu tăng hạn mức. Các lệnh gọi API của một tài khoản dịch vụ được coi là sử dụng một tài khoản duy nhất. Việc tăng hạn mức không đảm bảo rằng ứng dụng của bạn sẽ được phê duyệt. Việc tăng hạn mức lớn có thể mất nhiều thời gian để được phê duyệt hơn.
Không phải dự án nào cũng có cùng hạn mức. Khi bạn sử dụng Google Cloud ngày càng nhiều theo thời gian, hạn mức của bạn có thể cần tăng lên. Nếu dự kiến mức sử dụng sắp tới sẽ tăng lên đáng kể, bạn có thể chủ động yêu cầu điều chỉnh hạn mức trên trang Hạn mức trong bảng điều khiển Google Cloud.
Để tìm hiểu thêm, hãy xem các tài nguyên sau:
- Giới thiệu về yêu cầu tăng hạn mức
- Xem hạn mức và mức sử dụng hiện tại của bạn
- Yêu cầu hạn mức cao hơn