Apa Itu Rate Limiting? Panduan Mudah untuk Pembina App

Rate limiting ialah peraturan yang menghadkan bilangan permintaan yang boleh dibuat seseorang kepada sistem dalam jumlah masa tertentu — contohnya, 5 cubaan log masuk seminit, atau 100 panggilan API sejam. Apabila had dicapai, permintaan seterusnya ditolak (biasanya dengan kod ralat 429 Too Many Requests) sehingga tetingkap masa ditetapkan semula. Ia melindungi app daripada penyalahgunaan, memastikan seorang pengguna berat tidak melambatkan perkara untuk semua orang, dan menghalang kos yang tidak terkawal.

Anda akan berdepan rate limiting dari dua sisi: perkhidmatan yang anda panggil menghadkan anda, dan app anda sendiri sepatutnya menghadkan penggunanya.

Mengapa rate limiting penting apabila membina dengan AI

App yang dibina dengan AI selalunya berhubung dengan perkhidmatan berbayar — model AI, e-mel, SMS, peta — dan setiap panggilan menelan kos. Ini menjadikan rate limiting sebagai ciri keselamatan dan juga ciri bajet.

• Kawalan kos. Jika app anda mempunyai kotak “tanya AI” tanpa had, bot boleh menghantar beribu-ribu permintaan semalaman. Anda membayar untuk setiap satu.
• Keselamatan. Tanpa had pada borang log masuk, penyerang boleh mencuba beribu-ribu kata laluan pada satu akaun. Had beberapa cubaan seminit menjadikannya tidak praktikal.
• Kekal dalam talian. Satu skrip yang bermasalah — kadangkala kod anda sendiri yang tersekat dalam gelung — boleh membebankan pangkalan data anda dan melumpuhkan app.
• Menghormati had perkhidmatan lain. Apabila app anda memanggil API luar terlalu kerap, andalah yang menerima ralat 429, dan ciri akan rosak untuk pengguna anda.

Pembina AI akan membina apa yang anda minta. Jika anda tidak menyebut had, ia selalunya ditinggalkan.

Analogi harian

Bayangkan dasar isi semula air percuma di sebuah kedai kopi: “Satu isi semula percuma bagi setiap pelanggan setiap lawatan.”

• Ia tidak menghalang sesiapa daripada menikmati kopi.
• Ia menghalang seseorang berdiri di kaunter sepanjang hari mengisi semula termos untuk seluruh pejabat.
• Apabila seseorang meminta isi semula keempat, barista dengan sopan berkata “bukan sekarang” — itulah 429.

Had kadar yang baik tidak kelihatan kepada pelanggan biasa dan hanya dikesan oleh seseorang yang melakukan sesuatu yang luar biasa.

Cara rate limiting berfungsi

Penghad kadar memerlukan tiga perkara:

Apabila permintaan tiba, app menyemak bilangan untuk “siapa” itu. Di bawah had: permintaan diluluskan dan kiraan meningkat. Melebihi had: permintaan ditolak.

Terdapat beberapa cara biasa untuk mengira:

Kiraan perlu disimpan di tempat yang pantas dan dikongsi. Pada satu pelayan kecil, memori sudah mencukupi. Apabila app berjalan pada beberapa mesin, pembilang biasanya berada dalam storan kongsi seperti Redis atau pangkalan data, jika tidak setiap mesin akan mengira secara berasingan dan had sebenar menjadi berganda-ganda ganda lebih tinggi.

Rupa respons yang dihadkan kadarnya

Apabila permintaan melebihi had, API yang baik memberi respons dengan:

• Kod status 429 Too Many Requests.
• Selalunya header Retry-After, yang menyatakan berapa saat perlu menunggu.
• Kadangkala header yang menunjukkan had anda dan berapa banyak permintaan yang tinggal dalam tetingkap ini (nama berbeza mengikut pembekal).

App anda sepatutnya bertindak balas kepada 429 dengan menunggu dan mencuba semula kemudian — sebaik-baiknya dengan exponential backoff, iaitu menunggu sedikit lebih lama selepas setiap percubaan yang gagal (1 saat, kemudian 2, kemudian 4) dan bukannya menghentam perkhidmatan itu berulang kali.

Contoh kerja: pembantu penulisan AI

Katakan anda telah membina app di mana pengguna menampal teks dan mendapat semula tulisan oleh AI.

Tanpa had: seseorang menulis skrip yang menghantar 20,000 permintaan semalaman. Bil pembekal AI anda melonjak, dan akaun anda mencapai had kadar pembekal itu sendiri, jadi pengguna sebenar nampak ralat sepanjang pagi.

Dengan had yang munasabah:

1. Setiap pengguna yang log masuk: 30 penulisan semula sejam pada pelan percuma, 300 pada pelan berbayar. Melebihi had, pengguna nampak: “Anda telah mencapai had untuk jam ini. Cuba semula dalam 12 minit, atau naik taraf.”
2. Setiap alamat IP pada borang pendaftaran: 5 pendaftaran sejam, untuk menghalang bot mencipta beribu-ribu akaun percuma bagi mengelak had setiap pengguna.
3. Had perbelanjaan yang ditetapkan dalam papan pemuka pembekal AI anda, sebagai barisan pertahanan terakhir jika semua yang lain gagal.
4. Mengendalikan had pembekal: jika pembekal AI memulangkan 429, pelayan anda menunggu dan mencuba semula sekali atau dua kali, kemudian memaparkan mesej mesra “sibuk, sila cuba lagi”.

Had diperiksa di pelayan. Had yang hanya wujud dalam pelayar — contohnya, melumpuhkan butang selepas 30 klik — boleh dipintas oleh sesiapa sahaja yang memanggil API anda secara langsung.

Istilah utama

Salah faham yang biasa

• “Rate limiting hanya untuk app besar.” App kecil juga menjadi sasaran, kerana bot mengimbas seluruh internet untuk mencari borang dan endpoint AI yang terbuka. Kos penyalahgunaan tidak bergantung pada saiz anda.
• “Menyembunyikan butang sudah memadai.” Had di sebelah pelayar hanyalah budi bahasa, bukan perlindungan. Had sebenar mesti dikuatkuasakan di pelayan.
• “Had setiap IP sentiasa adil.” Ramai orang boleh berkongsi satu alamat IP — pejabat, sekolah, rangkaian mudah alih. Had setiap pengguna lebih adil apabila orang sudah log masuk.
• “429 bermakna perkhidmatan itu rosak.” Ia bermakna anda memanggilnya terlalu kerap. Semak kod anda untuk gelung, dan simpan (cache) hasil yang jarang berubah — lihat apa itu caching.
• “Rate limiting menggantikan had perbelanjaan.” Gunakan kedua-duanya. Had dalam app anda boleh mempunyai pepijat; had perbelanjaan pembekal ialah sokongan terakhir anda.

Apa yang perlu diminta daripada pembina AI anda

• “Tambah rate limiting di pelayan untuk log masuk, daftar masuk, tetapan semula kata laluan dan endpoint AI. Cadangkan had yang munasabah.”
• “Hadkan setiap pengguna yang log masuk kepada [N] permintaan AI sejam, dan tunjukkan mesej yang jelas dengan masa menunggu apabila mereka mencapainya.”
• “Apabila API luar memulangkan 429, cuba semula dengan exponential backoff sehingga 3 kali, kemudian papar ralat mesra.”
• “Di mana pembilang had kadar disimpan? Adakah ia masih berfungsi jika app berjalan pada lebih daripada satu mesin?”
• “Log setiap kali pengguna atau IP mencapai had, supaya saya boleh mengesan penyalahgunaan.”
• “Perkhidmatan luar mana yang dipanggil oleh app ini, dan apakah had kadar mereka?”

Rate limiting dalam Mythex

Dokumentasi Mythex jelas tentang perkara ini untuk ciri AI: had kadar, keselamatan dan kawalan kos dalam app yang anda bina adalah tanggungjawab anda untuk reka — lihat Bina app AI. Minta ejen menambah had dalam mesej yang sama apabila anda meminta ciri tersebut. Pada Pro, perkhidmatan yang diterbitkan boleh berjalan pada sehingga tiga mesin apabila trafik tinggi (lihat Had hosting), jadi mintalah pembilang yang disimpan dalam pangkalan data dan bukannya dalam memori satu pelayan.

Bacaan berkaitan: apa itu API, cara menggunakan API LLM dan senarai semak keselamatan untuk app yang dibina dengan AI.

Soalan lazim