Што е ограничување на барања? Едноставен водич за градители на апликации

Ограничувањето на барања е правило што ограничува колку барања може да испрати некој до еден систем за одредено време — на пример, 5 обиди за најава во минута или 100 повици до API во час. Кога ќе се достигне лимитот, понатамошните барања се одбиваат (обично со код на грешка 429 Too Many Requests) додека временскиот прозорец не се ресетира. Тоа ги штити апликациите од злоупотреба, спречува еден голем корисник да ги забави работите за сите и ги запира неконтролираните трошоци.

Со ограничувањата се среќавате од две страни: сервисите што ги повикувате ве ограничуваат вас, а вашата апликација треба да ги ограничува своите корисници.

Зошто ограничувањето на барања е важно кога градите со AI

Апликациите изградени со AI често се поврзуваат со платени сервиси — AI модели, е-пошта, SMS, мапи — и секој повик чини пари. Затоа ограничувањето на барања е и безбедносна функција и функција за буџетот.

• Контрола на трошоци. Ако вашата апликација има поле „прашај AI“ и нема лимит, бот може да испрати илјадници барања преку ноќ. Вие плаќате за секое.
• Безбедност. Без лимит на формуларот за најава, напаѓач може да пробува илјадници лозинки за една сметка. Лимит од неколку обиди во минута го прави тоа непрактично.
• Останување онлајн. Еден неисправен скрипт — понекогаш и ваш код во јамка — може да ја преоптовари базата и да ја сруши апликацијата.
• Почитување на лимитите на други сервиси. Кога вашата апликација премногу често повикува надворешен API, вие ги добивате грешките 429, а функциите се кршат за вашите корисници.

AI градителите ќе изградат она што го бараете. Ако не спомнете лимити, често тие не се вклучуваат.

Секојдневна аналогија

Замислете политика за бесплатно полнење во една кафеана: „Едно бесплатно полнење по гостин за посета.“

• Не го спречува никого да ужива во кафето.
• Го спречува еден човек цел ден да стои на шалтерот и да полни термос за целата канцеларија.
• Кога некој ќе побара четврто полнење, шефот учтиво вели „не сега“ — тоа е 429.

Добриот лимит е невидлив за обичните гости и забележан само кај некој што прави нешто невообичаено.

Како работи ограничувањето на барања

Ограничувачот на барања има три дела:

Кога ќе пристигне барање, апликацијата го проверува бројот за тоа „кој“. Под лимитот: барањето минува и бројот се зголемува. Над лимитот: барањето се одбива.

Има неколку вообичаени начини на броење:

Бројачите мора да се чуваат на брзо и споделено место. На еден мал сервер, меморијата е доволна. Кога апликацијата работи на неколку машини, бројачот обично живее во споделено складиште како Redis или базата, инаку секоја машина брои посебно и вистинскиот лимит станува неколку пати поголем.

Како изгледа одговор со ограничување

Кога барањето е над лимитот, добро однесуван API одговара со:

• Статус код 429 Too Many Requests.
• Често заглавие Retry-After, кое кажува колку секунди да се чека.
• Понекогаш заглавија кои го покажуваат вашиот лимит и колку барања ви остануваат во овој прозорец (имињата се разликуваат кај провајдерите).

Вашата апликација треба да реагира на 429 со чекање и повторен обид подоцна — по можност со exponential backoff, што значи чекање малку подолго по секој неуспешен обид (1 секунда, потоа 2, потоа 4), наместо да се удира по сервисот.

Практичен пример: AI асистент за пишување

Да речеме дека сте изградиле апликација каде корисниците внесуваат текст и добиваат AI преработка.

Без лимити: некој напишува скрипт што испраќа 20.000 барања преку ноќ. Сметката кај AI провајдерот скока, а вашата сметка го достигнува сопствениот лимит на провајдерот, па вистинските корисници цело утро гледаат грешки.

Со разумни лимити:

1. По најавен корисник: 30 преработки на час на бесплатниот план, 300 на платениот. Над лимитот корисникот гледа: „Го достигнавте лимитот за овој час. Обидете се повторно за 12 минути или надградете.“
2. По IP адреса на формуларот за регистрација: 5 регистрации на час, за да се спречат ботови да создаваат илјадници бесплатни сметки и да го заобиколат лимитот по корисник.
3. Лимит на трошење поставен во таблата на вашиот AI провајдер, како последна линија на одбрана ако сè друго закаже.
4. Справување со лимитите на провајдерот: ако AI провајдерот врати 429, вашиот сервер чека и се обидува еднаш или двапати, па потоа прикажува пријателска порака „зафатени сме, обидете се повторно“.

Лимитите се проверуваат на серверот. Лимит што постои само во прелистувачот — на пример, оневозможување на копчето по 30 кликнувања — може да го заобиколи секој што директно го повикува вашиот API.

Клучни поими

Чести заблуди

• „Ограничувањето на барања е само за големи апликации.“ Малите апликации се мети исто, бидејќи ботовите скенираат цел интернет за отворени формулари и AI крајни точки. Цената на злоупотребата не зависи од вашата големина.
• „Доволно е да се сокрие копчето.“ Лимитите во прелистувачот се љубезност, а не заштита. Вистинските лимити мора да се спроведуваат на серверот.
• „Лимитите по IP се секогаш фер.“ Многу луѓе споделуваат иста IP адреса — канцеларија, училиште, мобилна мрежа. Лимитите по корисник се поправедни кога луѓето се најавени.
• „429 значи дека сервисот е расипан.“ Значи дека го повикувате премногу често. Проверете го кодот за јамки и кеширајте резултати што не се менуваат често — видете што е кеширање.
• „Ограничувањето на барања ја заменува капата на трошење.“ Користете ги двете. Лимитите во апликацијата можат да имаат бубачки; капата на трошење кај провајдерот е вашата резерва.

Што да го прашате вашиот AI градител

• „Додај ограничување на барања на серверот за најава, регистрација, враќање на лозинка и AI крајната точка. Предложи разумни лимити.“
• „Ограничи секој најавен корисник на [N] AI барања на час и покажи јасна порака со времето на чекање кога ќе го достигне лимитот.“
• „Кога надворешен API ќе врати 429, обидувај се со exponential backoff до 3 пати, па прикажи пријателска грешка.“
• „Каде се чуваат бројачите на лимитите? Ќе работат ли ако апликацијата работи на повеќе машини?“
• „Евидентирај секогаш кога корисник или IP ќе го достигне лимитот, за да можам да откривам злоупотреба.“
• „Кои надворешни сервиси ги повикува апликацијата и какви се нивните лимити на барања?“

Ограничување на барања во Mythex

Документацијата на Mythex е директна за AI функциите: лимитите на барања, безбедноста и контролите на трошоците во апликациите што ги градите се ваша одговорност — видете Градење AI апликација. Побарајте од агентот да додаде лимити во истата порака во која ја бараш функцијата. На Pro, објавен сервис може да работи на до три машини кога сообраќајот е голем (видете ограничувања на хостинг), па побарајте бројачите да живеат во базата на податоци, а не во меморијата на еден сервер.

Поврзано штиво: што е API, како да користите LLM API-ја и контролната листа за безбедност за апликации изградени со AI.

Прашања