50.000 gange om måneden? API 's overdrevne opkald er endelig blevet løst.
For nylig kom en ven til mig og sagde, at han fandt et alvorligt problem i backstage af den flyvende bog udvikler: / open- apis / bot / v3 / info, denne grænseflade kaldes hundredvis af gange i minuttet, og 50.000 gange om måneden det kommer til at løbe ud!
Hvordan fandt du ud af det?
Venner i "API Call Statistics" backstage af Flying Book Developer oplevede et usædvanligt højt antal opkald til denne grænseflade:
| Indikatorer | Værdi |
| Antal daglige opkald | 43200 + gange |
| Ring hvert minut | ~ 300 gange |
| Anslået månedligt forbrug | Tæt på 50.000 gange. |
Jeg er en robot. Hvordan kan jeg ringe så tit?
De grundlæggende årsager til problemet
Jeg tjekkede OpenClaws kode og fandt den to steder:
1. Status check trigger API opkald
Funktionen probeFeishu () kalder botinfo interface til flyvende bøger, hver gang du spørger om robot status. Denne funktion kaldes i følgende scenarier:
- Få OpenID ved opstart
- Når ekstern systemforespørgselsstatus
- Når WebSocket er afbrudt
2. Mangel på en cache mekanisme
Den oprindelige kode var "Spørg hvert opkald", og der var ingen cache. Selv hvis du beder om en tilstand på 10 gange, vil du have 10 API opkald.
Løsninger: 5 minutters cache mekanisme
Jeg tilføjede en simpel cache til probe.ts:
// 缓存配置：5分钟内不重复调用 API
const CACHE_TTL_MS = 5 * 60 * 1000;
const botInfoCache = new Map();Den centrale logik er enkel:
- Første kald Anmodning om flyvende bøger API Cache resultater
- Ring igen om fem minutter. Direct back cache (ingen ny anmodning indledt)
- Fejlen stoppede også. → Undgå gentagne anmodninger, når fejl
Ændrede virkninger
| Kontrast | Før ændring | ændret |
|---|---|---|
| Hver statusforespørgsel | Ring til API | Direkte cache |
| Kunne ikke prøve igen | Ubegrænset forsøg igen | Cache 5 Minutter |
| Anslået månedligt forbrug | 50000 + gange | ~ 300 gange |
Det er enkelt.: Højst 1 opkald pr. 5 minutter, 24 timer pr. dag = 288 gange / måned, ca. 3.500 gange om året. Den oprindelige grænse på 50.000 om måneden, vil ikke løbe ud!
Anvend scene
Dette program er specielt velegnet til:
- Brugere udvidet med OpenClaw
- Udvikle din egen flyvende bog robot og kalde botinfo interface ofte
- API skala er presserende og ønsker at optimere antallet af opkald
Oversigt
Flying Book API "s overallokering problem er hovedsagelig forårsaget af manglen på en cache mekanisme. Løsningen er enkel: Ring til grænsefladen med en cache.
Sommetider den enkleste optimering er den mest effektive.