Du behöver inte vara orolig om din bot har hastighetsbegränsats, det här är ett vanligt problem som kan lösas med rätt tillvägagångssätt. Denna artikel kommer att hjälpa dig att förstå Discords hastighetsbegränsningssystem och ge praktiska lösningar.
Innehåll
Förstå Discords typer av hastighetsbegränsningar
Globala hastighetsbegränsningar
Hastighetsbegränsning per route
Resursspecifika hastighetsbegränsningar
Gränser för ogiltiga förfrågningar
Hur du identifierar din hastighetsbegränsning
Bästa metoder för att hantera hastighetsbegränsningar
Globala hastighetsbegränsningar
Att tänka på gällande gateways och sharding
Förstå Discords typer av hastighetsbegränsningar
Discord använder flera olika slags hastighetsbegränsningar för att skydda vår API. Att förstå vilken slags hastighetsbegränsning du stött på är första steget för att lösa problemet:
Globala hastighetsbegränsningar
Gräns: 50 förfrågningar per sekund över de flesta endpoints
Omfattning: Gäller för hela din applikation
Identifiering: Leta efter X-RateLimit-Scope: global i response headers
Hastighetsbegränsning per route
Gräns: Varierar mellan endpoints
Omfattning: Specifikt för enskilda API-routes
Identifiering: Kolla efter X-RateLimit-Scope: user
Resursspecifika hastighetsbegränsningar
Observera: Resursspecifika hastighetsbegränsningar kan nås av flera källor (andra användare, botar, webhooks, etc.) och behöver inte indikera att din applikation är ensamt ansvarig.
Gräns: Enskilda gränser för specifika guilds, kanaler eller webbhooks
Omfattning: Gäller åtgärder på specifika resurser.
Identifiering: Leta efter X-RateLimit-Scope: shared i headers
Gränser för ogiltiga förfrågningar
Gräns: 10 000 ogiltiga förfrågningar per 10 minuter
Vanliga orsaker: Ohanterade fel (401,403, eller 429) som skapar en ökning av förfrågningar spikar. Observera, 429-fel med X-RateLimit-Scope: shared räknas inte mot denna gräns.
Resultat: Tillfällig blockering via Cloudflare
Hur du identifierar din hastighetsbegränsning
Det mest tillförlitliga sättet är att undersöka HTTP-headers när du får en 429-statuskod. Viktiga headers att kolla efter:
X-RateLimit-Limit: Max antal tillåtna förfrågningar för den endpointen
X-RateLimit-Remaining: Antal förfrågningar som återstår inom nuvarande tidsfönster
X-RateLimit-Reset: När begränsningsfönstret återställs (Unix timestamp)
X-RateLimit-Reset-After: Sekunder tills gränsen återställs
X-RateLimit-Scope: Anger vilken typ av hastighetsbegränsning (global, användare eller delad)
retry_after: Millisekunder du behöver vänta innan du kan göra en ny förfrågan
Bästa metoder för att hantera hastighetsbegränsningar
Implementera korrekt backoff-strategi
Respektera alltid värdet retry_after i hastighetsbegränsningssvar. Det visar exakt hur länge du måste vänta innan nästa försök.
Överväg att använda interactions där det är möjligt
Appkommandon och meddelandekomponenter är utmärkta alternativ till prefix-kommandon, vilket kan förhindra överdrivna API-förfrågningar och meddelanden i kanaler.
Bonustips: Gör interaktionssvar och uppföljningsmeddelanden tillfälliga eftersom de inte räknas mot hastighetsbegränsningarna.
Cacha data effektivt
Minska API-anrop genom att cachelagra data som används ofta, såsom:
- Guildinformation
- Kanaldetaljer
- Användarprofiler
- Rolldata
Använd throttling för förfrågningar
Throttling är en proaktiv strategi för att förhindra hastighetsbegränsningar genom att kontrollera takten av dina förfrågningar innan du når gränsen.
Om din bot till exempel ska skicka välkomstmeddelanden till 200 nya medlemmar, lägg dem i en kö som skickar 4 meddelanden var 100:e millisekund istället för att skicka 200 meddelanden samtidigt. Detta håller en jämn takt på 40 förfrågningar per sekund, vilket håller dig stabilt under gränsen på 50 samtidigt som du ser till att alla meddelanden skickas inom ungefär 5 sekunder.
Globala hastighetsbegränsningar
Om du når globala hastighetsbegränsningar kan ditt program ha ett underliggande problem som måste åtgärdas.
Så här optimerar du din kod för att hålla dig inom gränserna:
- Implementera caching korrekt
- Gå över till funktioner baserade på interactions
Om dessa tips inte löser dina globala problem med hastighetsgränserna uppmuntrar vi dig att be om hjälp i kanalen #api-help i Discords utvecklarserver, eller kontakta vår utvecklarsupport.
Att tänka på gällande gateways och sharding
För botar som hanterar händelser i realtid via Discords Gateway (websocket-anslutning) så är sharding viktigt när din bot växer.
Vad är sharding?
Sharding delar upp din bot i flera instanser där varje instans hanterar en delmängd av guilder. Detta distribuerar lasten över flera websocket-anslutningar, vilket hjälper dig att hålla dig inom hastighetsbegränsningar.
Det rekommenderas att börja planera att implementera sharding när ni närmar er 2000 guild, eftersom sharding måste vara aktiverat vid över 2500 guilds. För optimal prestanda, följ bästa praxis att upprätthålla cirka 1 shard per 1000 guilds.
Kom ihåg att hastighetsgränser finns till för att säkerställa en stabil upplevelse för alla Discord-användare. Genom att följa dessa bästa metoder kan du skapa en bot som skalar effektivt samtidigt som dessa gränser respekteras.