Als je bot tegen foutmeldingen over rate limits (toegangslimieten) aanloopt, maak je dan geen zorgen. Dit is een veelvoorkomend probleem dat met de juiste aanpak kan worden opgelost. Dit artikel zal je helpen om Discords systeem met rate limits te begrijpen en biedt hiervoor praktische oplossingen.
Inhoud
De soorten rate limits van Discord begrijpen
Limits voor ongeldige verzoeken
Beste werkwijzen om met rate limits om te gaan
Belangrijke punten rond gateways en sharding
De soorten rate limits van Discord begrijpen
Discord gebruikt meerdere soorten rate limits om de API te beschermen. Om de juiste oplossing te vinden, is het cruciaal om te bepalen met welk type je te maken hebt:
Algemene rate limits
Limiet: 50 verzoeken per seconde voor de meeste eindpunten.
Bereik: geldt voor je gehele applicatie.
Identificatie: zoek naar X-RateLimit-Scope: global in de responseheaders (antwoordkoppen).
Per-route rate limits
Limiet: varieert per eindpunt.
Bereik: specifiek voor individuele API-routes.
Identificatie: Zoek naar X-RateLimit-Scope: user.
Bronspecifieke rate limits
Opmerking: bronspecifieke rate limits kunnen worden bereikt door meerdere bronnen (andere gebruikers, bots, webhooks, etc.) en geven mogelijk niet aan dat alleen jouw applicatie verantwoordelijk is.
Limiet: onafhankelijke limieten voor specifieke guilds, kanalen of webhooks.
Bereik: geldt voor acties op specifieke bronnen.
Identificatie: zoek naar X-RateLimit-Scope: shared in de headers.
Limits voor ongeldige verzoeken
Limiet: 10.000 ongeldige verzoeken per 10 minuten.
Veelvoorkomende oorzaak: onverwerkte foutmeldingen (401, 403 of 429) die pieken in verzoeken veroorzaken. Let op: 429-foutmeldingen die zijn teruggestuurd met X-RateLimit-Scope: shared worden niet meegeteld voor je limiet voor ongeldige verzoeken.
Resultaat: tijdelijke Cloudflare-ban.
Je rate limit identificeren
De meest betrouwbare manier om te bepalen welke limit je bereikt, is door de HTTP-responseheaders te bekijken wanneer je een 429-statuscode ontvangt. Belangrijkste headers om te controleren:
X-RateLimit-Limit: de bovengrens van de rate limit voor dat eindpunt.
X-RateLimit-Remaining: aantal resterende verzoeken in het huidige venster.
X-RateLimit-Reset: Wanneer het rate limit-venster wordt gereset (Unix-tijdstempel).
X-RateLimit-Reset-After: aantal seconden tot de limiet wordt gereset.
X-RateLimit-Scope: geeft het type rate limit aan (algemeen, gelinkt aan de gebruiker of gedeeld).
retry_after: milliseconden die je moet wachten voordat je een ander verzoek indient.
Beste werkwijzen om met rate limits om te gaan
Gebruik de juiste backoff-strategieën
Respecteer altijd de waarde retry_after in reacties van rate limits. Deze vertelt je precies hoe lang je moet wachten voordat je het opnieuw kunt proberen.
Gebruik interacties waar mogelijk
Applicatie-opdrachten en berichtcomponenten zijn een uitstekend alternatief voor prefix-opdrachten, die overmatige API-verzoeken en berichten in kanalen kunnen voorkomen.
Bonustip: maak interactie-antwoorden en vervolgberichten tijdelijk, aangezien ze niet meetellen voor de rate limits.
Gegevens effectief cachen
Beperk API-opdrachten door vaak gebruikte gegevens te cachen, bijvoorbeeld:
- Guild-informatie
- Kanaaldetails
- Gebruikersprofielen
- Rolgegevens
Gebruik verzoekbeperking (throttling)
Throttling is een proactieve methode om rate limits te voorkomen door het tempo van je verzoeken te beheersen voordat de limiet wordt bereikt.
Als je bot bijvoorbeeld welkomstberichten moet sturen naar 200 nieuwe leden, plaats ze dan in een wachtrij die elke 100 milliseconden 4 verzoeken vrijgeeft, in plaats van alle 200 berichten onmiddellijk te versturen. Zo kun je een constante snelheid van 40 verzoeken per seconde behouden, waardoor je veilig onder de limiet van 50 verzoeken blijft, en er tegelijkertijd voor zorgen dat alle berichten in ongeveer 5 seconden worden verzonden.
Algemene rate limits
Als je algemene rate limits krijgt, kan je programma mogelijk een onderliggend probleem hebben dat moet worden aangepakt.
Je kunt op deze manieren je code optimaliseren om binnen de limieten te blijven:
- Gebruik de juiste caching.
- Stap over naar op interactie gebaseerde functies.
Als deze oplossingen je problemen met de algemene rate limits niet verhelpen, raden we je aan contact op te nemen met het #api-help-kanaal op de server voor ontwikkelaars op Discord of met het ondersteuningsteam voor ontwikkelaars.
Belangrijke punten rond gateways en sharding
Voor bots die realtime gebeurtenissen verwerken via de gateway van Discord (websocketverbinding), wordt sharding essentieel naarmate je bot groter wordt.
Wat is sharding?
Sharding (dataverdeling) splitst je bot op in meerdere instanties die elk een subset van guilds behandelen. Dit verdeelt de druk over meerdere websocketverbindingen, waardoor je binnen de rate limits blijft.
We raden je aan om het gebruik van sharding te beginnen plannen wanneer je de 2.000 guilds nadert, aangezien sharding moet worden ingeschakeld als je meer dan 2.500 guilds hebt. Voor optimale prestaties wordt aanbevolen om ongeveer 1 shard per 1.000 guilds te gebruiken.
Onthoud dat de rate limits er zijn om een stabiele ervaring voor alle Discord-gebruikers te garanderen. Door deze aanbevolen werkwijzen te volgen, kun je een bot ontwikkelen die efficiënt groeit en de limieten respecteert.