Hvis din bot støder på hastighedsbegrænsningsfejl, så skal du ikke bekymre dig - det er en almindelig udfordring, der kan løses med den rigtige tilgang. Denne artikel vil hjælpe dig med at forstå Discords hastighedsbegrænsende system og give praktiske løsninger.
Indhold
Forståelse af Discords hastighedsbegrænsningstyper
Globale hastighedsbegrænsninger
Ressourcespecifikke hastighedsbegrænsninger
Ugyldige anmodningsbegrænsninger
Sådan identificerer du dit hastighedsbegrænsningsproblem
Bedste praksis for håndtering af hastighedsbegrænsninger
Globale hastighedsbegrænsninger
Gateway-overvejeleser og sharding
Forståelse af Discords hastighedsbegrænsningstyper
Discord bruger flere typer af hastighedsbegrænsning for at beskytte API'en. At identificere hvilken type du støder på, er afgørende for at finde den rette løsning:
Globale hastighedsbegrænsninger
Begrænsning: 50 anmodninger pr. sekund på tværs af de fleste slutpunkter
Omfang: Gælder for din hele applikation
Identifikation: Se efter X-RateLimit-Scope: global i svaroverskrifterne
Per-route-hastighedsbegrænsninger
Begrænsning: Varierer afhængigt af slutpunkt
Omfang: Specifik for individuelle API-ruter
Identifikation: Se efter X-RateLimit-Scope: user
Ressourcespecifikke hastighedsbegrænsninger
Bemærk: Ressourcespecifikke hastighedsbegrænsninger kan nås af flere kilder (andre brugere, bots, webhooks osv.) og indikerer muligvis ikke, at din app er alene ansvarlig.
Begrænsning: Uafhængige begrænsninger for specifikke guilds, kanaler eller webhooks
Omfang: Gælder for handlinger på specifikke ressourcer.
Identifikation: Se efter X-RateLimit-Scope: shared i overskrifterne
Ugyldige anmodningsbegrænsninger
Begrænsning: 10.000 ugyldige anmodninger hvert 10. minut
Almindelig årsag: Ubehandlede fejl (401, 403 eller 429) der forårsager anmodningsstigninger. Vær opmærksom på, at 429 fejl, der returneres med X-RateLimit-Scope: shared, ikke tælles med i din grænse for ugyldige anmodninger.
Resultat: Midlertidig Cloudflare-forbud
Sådan identificerer du dit hastighedsbegrænsningsproblem
Den mest pålidelige måde at afgøre, hvilken grænse du rammer, er ved at undersøge HTTP-responsoverskrifterne, når du modtager en 429-statuskode. Nøgleoverskrifter, du bør tjekke:
X-RateLimit-Limit: Hastighedsgrænsen for den pågældende slutpunkt
X-RateLimit-Remaining: Antal anmodninger tilbage i det nuværende vindue
X-RateLimit-Reset: Når ratebegrænsningsvinduet nulstilles (Unix-tidsstempel)
X-RateLimit-Reset-After: Sekunder indtil grænsen nulstilles
X-RateLimit-Scope: Angiver typen af hastighedsbegrænsning (global, bruger eller delt)
retry_after: Millisekunder at vente før du laver en ny anmodning
Bedste praksis for håndtering af hastighedsbegrænsninger
Implementer ordentlige tilbageholdelsesstrategier
Respekter altid værdien af retry_after i svar på hastighedsbegrænsninger. Dette fortæller dig præcis, hvor længe du skal vente, før du prøver igen.
Overvej at bruge interaktioner hvor det er muligt
App-kommandoer og beskedkomponenter er et fremragende alternativ til præfiks kommandoer, som kan forhindre overdreven API-anmodninger og beskeder i kanaler.
Bonus-tip: Gør interaktionssvar og opfølgningsbeskeder midlertidige, da de ikke tæller med i hastighedsbegrænsningerne.
Cache-data-effektivt
Reducer API-opkald ved at cache ofte tilgåede data, som:
- Guild-oplysninger
- Kanaloplysninger
- Brugerprofiler
- Rolle-data
Brug anmodningsthrottling
Throttling er en proaktiv tilgang til at forhindre hastighedsbegrænsninger ved at kontrollere tempoet af dine anmodninger, før du rammer grænsen.
For eksempel, hvis din bot skal sende velkomstbeskeder til 200 nye medlemmer, i stedet for at sende alle 200 beskeder med det samme, placer dem i en kø, der sender 4 anmodninger hvert 100 millisekund. Dette opretholder en stabil hastighed på 40 anmodninger per sekund, hvilket holder sig sikkert under grænsen på 50 anmodninger, samtidig med at alle beskeder sendes på omkring 5 sekunder.
Globale hastighedsbegrænsninger
Hvis du rammer globale hastighedsgrænser, kan dit program have et underliggende problem, der skal løses.
Her er hvordan du optimerer din kode for at forblive inden for grænserne:
- Implementering af korrekt cachelagring
- Migrere til interaktionsbaserede funktioner
Hvis disse løsninger ikke løser dine globale hastighedsbegrænsningsproblemer, opfordrer vi dig til at række ud i Discord Developer Server #api-help-kanalen eller kontakte Udvikler-support.
Gateway-overvejeleser og sharding
For bots, der håndterer realtidsbegivenheder gennem Discords Gateway (websocket-forbindelse), er sharding essentielt, når din bot vokser.
Hvad er Sharding?
Sharding opdeler din bot i flere instanser, der hver håndterer en delmængde af guilds. Dette fordeler belastningen over flere websocket-forbindelser, hvilket hjælper dig med at holde dig inden for hastighedsgrænserne.
Det anbefales at begynde at planlægge for implementering af sharding, når man nærmer sig 2.000 guilds, da sharding skal aktiveres ved 2.500+ guilds. For optimal ydeevne, følg bedste praksis ved at opretholde cirka 1 shard pr. 1.000 guilds.
Husk at hastighedsbegrænsninger eksisterer for at sikre en stabil oplevelse for alle Discord-brugere. Ved at følge disse bedste praksisser kan du bygge en bot, der skalerer effektivt, samtidig med at den respekterer disse grænser.