Lohkoketjurajapinta tarjoaa pääsyn solmuun tai palveluun, jolla on omat rajansa ja riippuvuutensa. Ethereumissa tilan kysely tai simulointi ei ole sama kuin tapahtuman julkaisu. Esimerkit koskevat Ethereumia, eivät kaikkia lohkoketjuja.
Lukemisen ja lähettämisen vaikutukset eroavat
Ethereumissa eth_call suorittaa kutsun luomatta tapahtumaa ketjuun; RPC-palveluntarjoaja voi silti periä maksun palvelusta. eth_sendRawTransaction lähettää jo allekirjoitetun tapahtuman. Palautettu tunniste ei todista tapahtuman sisällyttämistä tai onnistumista. Tarkista kuitti, tila, lohko ja verkkoon sopiva lopullisuus.
Hallitse riippuvuudet ja virheet
Tarkista verkko, sopimuksen osoite, rajapinta ja parametrit ennen allekirjoitusta. Simulointi ei takaa myöhempää tulosta, jos tila muuttuu. Suoritettu mutta epäonnistunut tapahtuma voi kuluttaa gasia. Älysopimus on ohjelma; nimi ei takaa virheettömyyttä tai sopimuksen oikeudellista pätevyyttä.
Määritettävät kontrollit
- Määritä allekirjoitusoikeudet, kulutusrajat ja avainten hallinta.
- Erota RPC-häiriö odottavasta, epäonnistuneesta tai uudelleenjärjestellystä tapahtumasta.
- Jos oraakkeli toimittaa ulkoisia tietoja, arvioi lähteet, hallinta ja mahdolliset virheet.
Lähteet
- Ethereum · JSON-RPC API
- Ethereum · Transactions
- Ethereum · Gas and fees
- Ethereum · Smart contracts
- Ethereum · Oracles
Toimituksellinen tarkistus: 31. lokakuuta 2026.
Erota lähetetyt, sisällytetyt ja tulkitut tapahtumat.
Tapahtumatunniste ei määritä tarkoitettua vaikutusta. Tarkista verkko, kuitti, sisällyttäminen, tila ja asiaankuuluva liiketoimintatapahtuma. Määritä vahvistus- ja palautuskäytäntö käytetylle ketjulle; rajapinnan ei tulisi ilmoittaa onnistumisesta, kun tulokset ovat epävarmoja.
- Tarkista kyselyn kohteena oleva verkko ja tunniste.
- Erota odottavat, epäonnistuneet suoritukset ja vahvistetut vaikutukset.
- Testaa toistetut ilmoitukset toistamatta liiketoimintatoimia.
Tarkoittaako palautettu tiiviste toiminnon valmistumista?
Ei. Se tunnistaa lähetetyn tapahtuman. Tulosten seuranta ja tulkinta edellyttävät ketjuun ja sopimukseen sopivia tarkistuksia. Älä lähetä sokeasti uudelleen epäselvää operaatiota.
Ensisijainen lähde: Ethereum — JSON-RPC and transaction receipts. Aiheeseen liittyvä menetelmä: lue käytännön opas.
API-kiintiöt ja rajoitukset
Rajoitukset vaikuttavat kapasiteettiin, uusintoihin ja asiakkaiden väliseen jakoon.
- Kirjaa koskeeko kiintiö tiliä, avainta vai resurssia ja montako rinnakkaista tointa asiakas sallii. Rajaton jono voi ylikuormittaa palvelun, vaikka keskimääräinen pyyntötiheys on matala.
- Tulkitse 429-vastauksen Retry-After, jos se annetaan, ja odota ennen uutta pyyntöä. Yhdistä kasvava odotus ja asiakkaiden ajallinen hajautus yritysrajaan ja kokonaisaikarajaan.
- Jos kirjoituksen vastaus puuttuu, tarkista tila ennen uusintaa. Yhdistä simuloidussa testissä kiintiöt, myöhäiset vastaukset ja peruutus; jonon on päätyttävä ilman toistuvia vaikutuksia.
Toistettava hyväksyntätapaus
Kuvitteellinen esimerkki: tiedot eivät kuvaa asiakasta tai havaittua tulosta.
Näytä tapauksen tiedot
{
"http_status": 429,
"retry_after_seconds": 30,
"workers": 20,
"retry_budget": 3,
"retry_budget_scope": "per_worker_retries_excluding_initial_request",
"scheduling_example": {
"response_received_at_seconds": 0,
"illustrative_retry_seconds": [
30,
31,
32,
33,
34
],
"workers_per_second": 4,
"alternative_deadline_seconds": 25,
"total_attempts_if_all_retries_used": 80
}
}Odotettu päätös
Odota 30 sekuntia, porrasta 20 työntekijää ja rajaa uudelleenyritykset.
Kaksikymmentä asiakasta: porrasta ja laske yritykset
Kuvitteellinen esimerkki: 20 työntekijää saa hetkellä +0 s vastauksen 429 ja Retry-After: 30. Ajat kuvaavat yhtä mahdollista jakoa, eivät taattua palvelinkapasiteettia. Jokaisella on ensimmäisen pyynnön lisäksi 3 uusintaa.
| Käytäntö | Laskelma tai aikataulu | Vaikutus |
|---|---|---|
| Samanaikainen uusinta | 20 × 1 = 20 @ +30 s | 30 sekunnin odotus noudattaa viivettä, mutta kaikki 20 pyyntöä palaavat yhdessä. Kuormapiikki voi toistua. |
| Porrastettu uusinta | 4 × 5 = 20 @ +30…+34 s | Neljä pyyntöä sekunnissa viiden sekunnin ajan jakaa 20 uusintaa vähentämättä niiden määrää. Esimerkkiaikataulu ei korvaa satunnaisesti hajautettua, kasvavaa odotuskäytäntöä. |
| Määräaika 25 sekuntia | 25 s < 30 s → 0 | Jos aikaa on vähemmän kuin vaaditut 30 sekuntia, lopeta tai siirrä sopimuksen mukaan. Älä lyhennä odotusta määräajan takia. |
| Enimmäisbudjetti | 20 × (1 + 3) = 80 | Kaikkien yritysten käyttö tuottaa 20 ensimmäistä pyyntöä ja 60 uusintaa eli 80 pyyntöä. Raja ei takaa onnistumista tai turvallista toistoa. |
Tarkistusmenettely
- Kirjaa kiintiö, rajaus ja yritysbudjetti.
- Kuluta kiintiö vain luvallisessa testissä.
- Säilytä 429, Retry-After ja rajattu aikajana. Erota tekninen rajoitus liiketoimintatuloksesta: täyttynyttä kiintiötä ei pidä muuttaa nollasaatavuutta ilmoittavaksi vastaukseksi.
- Simuloi ilman ulkoista kuormaa neljää kerrosta, joissa on kolme kokonaiskutsua, ja laske yritykset.
- Anna kuvitteellisen jonotehtävän vanhentua ja varmista, ettei uusi toiminto ala.
- Palauta valtuutettu työ vähitellen simuloidun vian jälkeen ja säilytä kutsut, määräajat ja yksilölliset tulokset.
Todistaako 429, ettei aiempi kirjoitus tapahtunut?
Ei. Vastausta vaille jäänyt toimi on täsmäytettävä erikseen; toisen yrityksen vastaus ei osoita sen tilaa.
Ensisijainen lähde: IETF — RFC 6585, HTTP 429. Aiheeseen liittyvä menetelmä: lue käytännön opas.
API: estä kerrosten kertautuvat uusintayritykset
Sovellus, SDK, välityspalvelin ja palvelu voivat kukin uusia kutsun. Neljä kuvitteellista kerrosta, joissa on kolme kokonaisyritystä kussakin, tuottavat enintään 81 kutsua vialliselle riippuvuudelle. Lisää yhteinen budjetti ja hyödyllinen määräaika kiintiöihin.
- Kartoita sovellus, SDK, välityspalvelin ja riippuvuuksien automaattiset yritykset. Valitse vastuukerros ja poista tai koordinoi lisäyritykset sopimuksen mukaan. Laske ensimmäinen yritys budjettiin. Säilytä toiminnon tunniste ja tarkista epävarmat vaikutukset ennen ei-idempotenttia uusintaa.
- Määritä kokonaismääräaika odotukselle, yhteydelle ja käsittelylle asiakkaan todellisin rajoituksin. Hylkää vanhentunut tehtävä ennen jonoon pääsyä. Paikallinen peruutus ei todista palvelimen pysähtyneen: täsmäytä tila. Palauta liikenne vähitellen ilman kaikkien jonojen yhtäaikaista käynnistystä.
Tarkoittaako kolme yritystä per kerros kolmea yhteensä?
Ei. Neljä kuvitteellista kerrosta ja kolme kokonaisyritystä tuottavat enintään 3⁴ = 81 viimeistä kutsua.
Peruuttaako määräaika ulkoisen vaikutuksen?
Ei välttämättä. Se estää uutta turhaa työtä; aloitettu etätoiminto tarvitsee tilatarkistuksen ja mahdollisen kompensaation.
Ensisijainen lähde: AWS — Timeouts, retries, and backoff with jitter. Aiheeseen liittyvä menetelmä: lue käytännön opas.