Langsung ke konten
Guide

Pembatasan kecepatan API: 4 algoritma yang harus diketahui setiap pengembang

| 9 min read

Memperbaiki jendela, jendela geser, keranjang token, dan keranjang bocor dijelaskan dengan diagram, header X-RateLimit, dan logika percobaan ulang Node.js yang dapat Anda salin-tempel.

Data visualization with streaming lines and analytics
Photo by Joshua Sortino on Unsplash

Tugas batch Anda memicu 200 permintaan dalam 3 detik dan setiap respons muncul kembali 429 Too Many Requests. Prosesor webhook Anda menyerang API pihak ketiga dan diblokir selama 15 menit. Integrasi pelanggan menjadi senyap karena putaran percobaan ulangnya menghabiskan kuota harian dalam satu jam pertama. Kegagalan ini berbagi satu penyebab utama: kode tidak mematuhi batas kecepatan.

Panduan ini mencakup empat algoritma pembatas kecepatan inti, menunjukkan cara membaca X-RateLimit header dari API apa pun, dan memberi Anda salin-tempel kode Node.js untuk logika percobaan ulang dengan backoff eksponensial.

Empat algoritma pembatas laju

Setiap pembatas tarif menjawab pertanyaan yang sama: "haruskah permintaan ini dipenuhi, atau haruskah saya menolaknya?" Keempat algoritma tersebut berbeda dalam cara mereka melacak waktu dan menangani ledakan.

1. Memperbaiki jendela

Pendekatan paling sederhana. Bagilah waktu menjadi interval tetap (misalnya 1 menit). Hitung permintaan per interval. Saat hitungan mencapai batas, tolak semuanya hingga interval berikutnya dimulai.

Jendela tetap mudah dibuat: satu penghitung dan satu stempel waktu per klien. Kekurangannya adalah masalah batas. Klien dapat mengirimkan batas penuh di akhir satu jendela dan batas penuh di awal berikutnya, mendapatkan 2x kecepatan yang diharapkan dalam ledakan singkat. API lama GitHub pembatas kecepatan menggunakan jendela tetap; mereka telah beralih ke pendekatan yang lebih canggih.

2. Jendela geser

Alih-alih menyetel ulang pada batas yang tetap, jendela akan bergeser seiring dengan setiap permintaan. Pada saat tertentu, pembatas melihat kembali selama N detik terakhir dan menghitung permintaan dalam rentang tersebut.

Jendela geser menghilangkan masalah batas pecah. Biaya memori lebih tinggi: Anda menyimpan stempel waktu untuk setiap permintaan, tidak ada satu penghitung pun. ulang ZRANGEBYSCORE menjadikannya praktis dalam skala besar. Cloudflare dan banyak gateway API menggunakan jendela geser untuk batas kecepatan per pengguna.

3. Ember token

Bayangkan sebuah ember yang menyimpan token. Setiap permintaan dikenakan biaya satu token. Token diisi ulang dengan tarif tetap. Jika keranjang kosong, permintaan akan ditolak. Jika ember penuh, kelebihan token tidak terakumulasi.

Token bucket adalah algoritma paling populer dalam produksi. Stripe, AWS API Gateway, dan sebagian besar cloud penyedia menggunakan variannya. Kapasitas bucket mengontrol ukuran semburan, dan kecepatan isi ulang mengontrol throughput yang berkelanjutan. Dua parameter memberi Anda kontrol menyeluruh atas bentuk lalu lintas.

4. Ember bocor

Kebalikan dari ember token. Permintaan memenuhi ember. Ember mengalir dengan kecepatan konstan. Jika ember meluap, permintaan berlebih ditolak. Tingkat keluaran tetap konstan berapa pun masukannya meledak.

Leaky bucket bekerja dengan baik untuk pembentukan lalu lintas ketika Anda memerlukan tingkat keluaran yang stabil: pekerja antrian, pengiriman webhook, dan saluran pengkodean video. Imbalannya adalah semburan lebih banyak diantri daripada dilayani; latensi meningkat di bawah beban.

Membandingkan keempat algoritma

Algoritma Meledak diperbolehkan? Ingatan Kasus penggunaan umum
Memperbaiki jendela Semburan tepi (2x pada batas) Rendah (1 penghitung) Penghitung sederhana, analitik
Jendela geser Halus, tidak ada paku batas Sedang (stempel waktu per permintaan) Batas API per pengguna
ember token Semburan terkendali hingga mencapai kapasitasnya Rendah (2 nilai) Sebagian besar API produksi (Stripe, AWS)
Ember bocor Antrian, tingkat keluaran konstan Sedang (antrian) Pembentukan lalu lintas, pekerja antrian

Membaca header X-RateLimit

Sebagian besar API menyertakan informasi batas kecepatan di header respons. Tiga header memberi tahu Anda segalanya Anda harus tetap berada di bawah batas:

  • X-RateLimit-Limit: permintaan maksimum yang diperbolehkan per jendela
  • X-RateLimit-Remaining: permintaan yang tersisa di jendela saat ini
  • X-RateLimit-Reset: Stempel waktu Unix (detik) saat jendela direset

Ketika Anda melampaui batas, status responsnya adalah 429 Too Many Requests dan itu Retry-After header memberi tahu Anda berapa detik untuk menunggu.

Cobalah melawan API botoi. Perintah curl ini meng-hash sebuah string dan mencetak header batas kecepatan:

Header respons:

Ini memberitahu Anda batasnya adalah 5 permintaan per jendela, Anda memiliki 4 tersisa setelah permintaan ini, dan jendela diatur ulang pada stempel waktu Unix yang diberikan. Lacak nilai-nilai ini di klien HTTP Anda untuk menghindari kesalahan 429 di tempat pertama.

Tip: Mengubah X-RateLimit-Reset untuk menunggu waktu: waitMs = (resetTimestamp - Math.floor(Date.now() / 1000)) * 1000

Coba lagi logika dengan backoff eksponensial di Node.js

Saat 429 muncul, jangan langsung mencoba lagi. Perulangan percobaan ulang yang ketat membuat masalah menjadi lebih buruk: Anda tetap tinggal dibatasi tarifnya lebih lama dan server menandai Anda sebagai pelaku kekerasan. Gunakan backoff eksponensial dengan jitter sebagai gantinya.

Gunakan dengan titik akhir apa pun:

Fungsi ini memeriksa a Retry-After tajuk terlebih dahulu. Jika server memberi tahu Anda berapa lama untuk menunggu, hormati itu. Jika tidak ada header, maka header akan kembali ke backoff eksponensial: 1 detik, 2 detik, 4 detik, 8 detik. Jitter acak (0-500ms) mencegah masalah kawanan yang bergemuruh di mana ratusan klien mencoba lagi pada saat yang sama.

Pelambatan proaktif: hindari 429 sebelum terjadi

Percobaan ulang reaktif menangani kegagalan setelah terjadi. Pelambatan proaktif mencegahnya. Jika Anda tahu batas kapasitas (dari dokumen atau header), atur kecepatan permintaan Anda di sisi klien.

Pembatas tarif sisi klien ini melacak stempel waktu permintaan di jendela geser. Sebelum setiap permintaan, ia memeriksa apakah jendela sudah penuh dan menunggu jika diperlukan. Anda mengirim permintaan dengan keamanan maksimum tingkat tanpa satu pun 429.

Model pembatasan tarif Botoi

Botoi menggunakan sistem pembatasan tarif dua tingkat:

Rencana Meledak (per menit) Kuota Penulis
Gratis ($0) 5 permintaan/menit 100/hari Tidak ada (berbasis IP)
Pemula ($9/bln) 30 permintaan/menit 300.000/bulan Kunci API
Pro ($49/bln) 300 permintaan/menit 3.000.000/bulan Kunci API
Bisnis ($199/bln) 1.000 permintaan/menit 30.000.000/bulan Kunci API

Akses anonim melacak permintaan berdasarkan alamat IP. Hitungan harian direset pada tengah malam UTC melalui a Penghitung Cloudflare KV. Permintaan yang diautentikasi menggunakan kunci API untuk identifikasi dan batasan diberlakukan melalui Buka kuncinya pembatas tingkat token bucket di tepinya.

Setiap tanggapan dari api.botoi.com termasuk ketiganya X-RateLimit header dijelaskan di atas, sehingga logika percobaan ulang Anda bekerja dengan cara yang sama apa pun rencananya.

Pendekatan yang terbukti bagi konsumen API

  • Baca header pada setiap respons. Jangan membatasi kecepatan hard-code dari dokumentasi. API mengubah batasan tanpa pemberitahuan. Header adalah sumber kebenaran.
  • Gunakan backoff eksponensial dengan jitter. Interval percobaan ulang yang tetap menyebabkan sinkronisasi percobaan ulang di seluruh klien. Jitter menyebarkan beban.
  • Batch dimana API mendukungnya. Satu permintaan dengan 10 item dikenakan 1 batas tarif tanda. Sepuluh permintaan individu berharga 10.
  • Tanggapan cache. Jika data tidak berubah antar permintaan, simpan hasilnya dan lewati panggilan API. Catatan DNS, sertifikat SSL, dan data WHOIS jarang berubah dalam hitungan menit.
  • Gunakan antrian untuk pekerjaan latar belakang. Jangan aktifkan panggilan API dari hot loop. Dorong bekerja dalam antrian (BullMQ, SQS, Cloudflare Queues) dan memproses item dengan kecepatan terkendali.
  • Pantau sisa kuota Anda. Catatan X-RateLimit-Remaining untuk Anda dasbor metrik. Atur peringatan ketika turun di bawah 20% dari batas.

Poin-poin penting

  • Empat algoritma mendominasi. Memperbaiki jendela adalah yang paling sederhana. Ember token adalah yang paling populer. Jendela geser menghilangkan semburan batas. Ember yang bocor memperlancar keluaran.
  • Header X-RateLimit adalah API Anda. Membaca Limit, Remaining, Dan Reset pada setiap respons agar tetap terkendali.
  • Backoff eksponensial dengan pegangan jitter 429s. Salin fetchWithRetry fungsi di atas ke dalam basis kode Anda dan bungkus setiap panggilan API eksternal.
  • Pelambatan proaktif mencegah 429 detik. Kecepatankan permintaan Anda di sisi klien daripada menunggu server melakukan push kembali.
  • Tidak diperlukan akun untuk menguji. Tekan titik akhir botoi mana pun di api.botoi.com dengan 5 permintaan gratis per menit untuk melihat aksi header batas tarif.

FAQ

Apa yang dimaksud dengan pembatasan laju API dan mengapa API menggunakannya?
Pembatasan tarif membatasi jumlah permintaan yang dapat dibuat klien dalam jangka waktu tertentu. API menggunakannya untuk melindungi server dari kelebihan beban, mencegah penyalahgunaan, memastikan pembagian sumber daya yang adil di seluruh klien, dan menjaga biaya infrastruktur tetap dapat diprediksi. Tanpanya, satu klien bisa membuat semua klien lainnya kelaparan.
Apa yang dimaksud dengan header X-RateLimit?
X-RateLimit-Limit adalah permintaan maksimal yang diperbolehkan per jendela. X-RateLimit-Sisa adalah jumlah yang tersisa. X-RateLimit-Reset adalah stempel waktu Unix ketika jendela direset. Coba Lagi-Setelah (pada 429 tanggapan) memberi tahu Anda berapa detik untuk menunggu sebelum mencoba lagi.
Bagaimana cara menangani respons 429 Permintaan Terlalu Banyak?
Baca header Retry-After dan tunggu beberapa detik. Jika tidak ada header Retry-After, gunakan backoff eksponensial: tunggu 1 detik setelah 429 pertama, 2 detik setelah 429 kedua, 4 detik setelah 429 ketiga, dan seterusnya. Tambahkan jitter acak (0-500 md) untuk mencegah masalah kawanan yang menggelegar ketika banyak klien mencoba ulang secara bersamaan.
Algoritme pembatasan kecepatan manakah yang paling umum?
Token bucket adalah yang paling umum di API produksi. Stripe, AWS, dan sebagian besar penyedia cloud menggunakan variannya. Token bucket memungkinkan semburan terkontrol sambil menerapkan laju berkelanjutan, yang lebih cocok dengan pola lalu lintas nyata daripada jendela tetap.
Apakah tingkat botoi membatasi permintaan anonim?
Ya. Permintaan anonim (tanpa kunci API) mendapatkan 5 permintaan per menit burst dan 100 permintaan per hari, dilacak berdasarkan alamat IP. Permintaan yang diautentikasi pada paket berbayar mendapatkan batas yang lebih tinggi: Pemula mengizinkan 30/menit, Pro mengizinkan 300/menit, dan Bisnis mengizinkan 1.000/menit.

Mulai membangun dengan botoi

150+ endpoint API untuk pencarian, pemrosesan teks, pembuatan gambar, dan utilitas developer. Paket gratis, tanpa kartu kredit.

Lihat dokumentasi API Lihat semua alat