Et forsøg igen er ikke en anden købsbeslutning
En kvittering kan ankomme to gange. En netværksanmodning kan time ud efter serveren forpligtede tilstand, men før klienten modtog svaret. En proces kan gå ned efter reservering af en transaktion, men før tildeling af valuta. Ved genstart, kan den sikreste handling være at prøve arbejde, der blev afbrudt. Hvis systemet behandler hver gentagelse som tilladelse til at give, duplikerede rettigheder er en normal konsekvens af inddrivelse.
Den nyttige sondring er hensigt versus tilskud. Formålet er anmodningen om at få et bestemt produkt under en specifik transaktion identitet. Grant er den holdbare spilside resultat: ejendomsret, en valuta delta, en beholdning element, eller en abonnementsperiode. Den samme hensigt kan leveres, forespurgt, prøvet, eller genleveret mange gange. Det bør stadig løse til en tilskudsbeslutning.
Dette er en engineering mønster, ikke en platform- specifik garanti. Forskellige butikker, betalingsudbydere, og spil backends afsløre forskellige modtagelse, anerkendelse, og refundering adfærd. Må ikke antage en kvittering beviser et tilskud, eller at en anerkendelse beviser spilleren så en vare. Byg server- side record, så spillet kan angive, hvad det ved, og inddrive sikkert, når et eksternt resultat er ufuldstændigt eller forsinket.
Giv hvert køb hensigt en stabil nøgle
En idempotens-nøgle binder gentagne leveringsforsøg til en beslutning. Den kan stamme fra en betroet platform transaktionsidentifikator, når denne identifikator er tilgængelig og verificeret, eller den kan udstedes af en server, før et køb begynder og er forbundet senere til betroede modtagelsesoplysninger. Nøglen skal være stabil på tværs af forsøg. Oprettelse af en ny tilfældig nøgle, hver gang klienten trykker "retablerbar" simpelthen skaber flere transaktioner, der tilfældigvis ser ens ud.
Gem nok sammenhæng med nøglen til at afvise mismatch: spiller eller konto omfang, produkt identitet, forventede mængde eller berettigelse form, kildekanal, modtaget tid, verifikationsstatus, og en tilstand som verserende, forpligtet, afvist, eller need-review. Hold følsomme kvittering materiale ud af almindelige logfiler. Hvis rå udbyder nyttelast har brug for kort tilbageholdelse for en verificeret inddrivelse flow, beskytte dem separat og gøre deres adgang bevidst.
Datamodellen har også brug for en unik grænse. For en ikke-forbrugbar rettighed, kan unikke være konto plus produkt-id. For valuta, unikke er normalt den hovedbog post eller tilskud transaktion snarere end den aktuelle saldo. For hjælpematerialer, en betroet transaktion id kan være unik, selv når produktet ID gentager. Definér nøglen før kodning af gentry politik; ellers to delsystemer kan deduplikere mod uforenelige identiteter.
Model det ukendte commit resultat
Det vanskelige resultat er ikke en ren succes eller en ren fiasko. Det er "ukendt": klienten ved ikke, om serveren har forpligtet tilskuddet. En timeout, forbindelse nulstilles, proces genstart, eller service afbrydelse kan producere denne tilstand. Den sikre klient adfærd er at bede om transaktionsstatus eller prøve igen samme hensigt. Den sikre server adfærd er at slå op denne hensigt og returnere den holdbare beslutning snarere end at anvende en anden mutation.
Gør ikke klientens display tilstand autoritativ. En spinner forsvinder, en lokal kvittering cache, eller en optimistisk balance ændring kan forbedre oplevelsen, men det kan ikke afgøre, om kontoen ejer en rettighed. Server myndighed betyder serveren verificerer den accepterede transaktion i henhold til produktets tillid grænse, forpligter den varige rekord én gang, og returnerer den aktuelle tilstand, når den bliver spurgt igen.
Sekvensen skal gøre partial- fuldførelse politik synlig. For eksempel: modtage hensigt, validere betroede køb beviser, oprette eller indlæse den holdbare hovedbog record, forpligte retten eller valuta mutation, markere den tildelte rekord, anerkende ekstern levering, når det er relevant, derefter returnere resultatet. Hvis processen stopper mellem to trin, kan en recovery arbejdstager eller senere status forespørgsel genoptage fra den holdbare record. Den nøjagtige bestilling afhænger af den eksterne udbyder og spil arkitektur, men den enkelte tilskud identitet ikke.
Beskyt rettigheder og valuta invariants
En idempotens nøgle forhindrer replay af en hensigt; det gør ikke automatisk hver bivirkning korrekt. Definer invariants et tilskud skal bevare. En ikke-forbrugbar ret vises på højst én gang for kontoen og produktet. Et valutatilskud har en hovedbog indgang med en transaktionsnøgle, en kendt delta, og en resulterende balance, der matcher summen af gyldige poster. Opgørelsestilskud adlyder stack, kapacitet, og item- definition regler. En abonnementsperiode strækker sig ikke to gange, fordi bekræftelsesendepunktet kørte to gange.
Gør den invariant kontrollere del af den samme holdbare drift, der forpligter tilskuddet. En læse efterfulgt af en senere skrive kan race under samtidig levering. To arbejdere kan begge observere "ikke ejet" og begge tilskud. Brug transaktionel opbevaring, compare- and-set semantics, en serialiseret konto mutation sti, eller en anden eksplicit concurrency primitiv egnet til datalageret. Den vigtige egenskab er, at beslutningen og dens markør ikke kan vindes uafhængigt af to forsøg.
For spil med en in- memory runtime, skelne varig succes fra præsentation. Serveren kan opdatere en spillers synlige balance efter den holdbare hovedbog indtastning forpligter, men den synlige opdatering er ikke beviset. Ved gentilslutning eller genstart, genopbygge den præsenterede tilstand fra den holdbare konto rekord. Det gør en forsinket klient respons ubelejlig snarere end økonomisk usikker.
Test nedbrud, genstarter, og genlevering bevidst
Start med et deterministisk scenario. Opret en konto, et produkt, en kendt startsaldo eller rettighedssæt, og en stabil transaktionstast. Kør strømmen, og injicer derefter en fejl efter hver navngivet grænse: efter modtagelse accept, efter oprettelse af en hovedbog, efter statusmarkering, efter ekstern anerkendelse, og efter reaktionen er forberedt. Genstart den relevante arbejdstager eller proces, prøv igen den samme nøgle, og gør gældende den endelige holdbare tilstand.
Det forventede resultat bør være specifikt. Et forsøg kan vende tilbage "allerede givet" med det oprindelige resultat, genoptage en verserende operation, afvise en forkert nyttelast, eller holde en rekord for gennemgang. Det bør ikke tilføje en anden beholdning element, anvende en anden valuta delta, eller skjule den ukendte tilstand med en fabrikeret succes. Optage klassificeringen i testresultatet, så en senere refaktor kan ikke vende et forsætligt hold til en utilsigtet duplikat.
Brug kvitteringen genlevering i det samme scenario. Levere den nøjagtige betroede transaktion to gange, derefter levere det efter en genstart, derefter levere det sammen med en duplikeret klient genprøve. Den resulterende hovedbog og kontotilstand skal være identisk med single- delivery case. Hvis produktet tillader gentagne køb, køre den samme sekvens med to virkelig forskellige transaktions identiteter for at bevise, at systemet ikke over- deduplikere af produkt ID alene.
Hold grænserne ærlige
Test kan kun bevise de interaktioner, du udfører. En simuleret udbyders respons kan validere din statsmaskine, men det er ikke bevis for, at hver producent udbyder kant opfører sig præcis på samme måde. En eksekverbar test mod en sandkasse kan tilføje tillid til denne integration, men alligevel har forskellige driftsbetingelser fra en levende butik. Optag, om et scenario bruger en simulering, lokal adapter, sandkasse eller verificeret udbyder miljø.
Trustgrænsen bør også være klar. En klient bør ikke indsende et vilkårligt beløb, produkt ID, eller "verificeret" flag og modtage et tilskud. Input er utroværdige, indtil serveren validerer dem mod den relevante konfiguration og køb beviser. Hvis validering ikke kan afslutte, holde hensigten venter eller afvise det med en inddrivelig kategori. Lad ikke en prøve kø blive en bypass omkring verifikation.
Privacy gælder for denne testdisciplin. Fixtures bør bruge syntetiske transaktionsdata. Logge bør henvise til en sikker test id, ikke en rå kvittering eller kontonavn. En produktionshændelse kan kræve begrænset dokumentation, men den rutinemæssige test suite bør aldrig blive en anden payment- data store.
Praktisk tjekliste
- Separat en stabil købshensigt fra den senere game-side tilskud.
- Brug en idempotens nøgle på tværs af timeouts, forsøg igen, genstarter, og kvittering genlevering.
- Bind nøglen til konto, produkt eller ret form, og betroede kildesammenhæng.
- Definer holdbare tilstande som verserende, forpligtede, afvist og behovsrevision.
- Styrke rettigheden unikke og curricul- leger invariants inden for samme concurrency grænse som tilskuddet.
- Injicer svigt efter hver tilstand overgang, derefter genstarte og prøve igen den samme hensigt.
- Test duplikering levering og legitime gentagne køb separat.
- Rapporter ukendte resultater ærligt; ikke omdanne en timeout til en opfundet succes.
- Hold kvitterings-lignende inventar og testlog syntetisk og redigeret.
Ofte stillede spørgsmål
Er et unikt kvitterings-id nok til idemstyrke?
Det kan være en nyttig komponent, når serveren kan kontrollere, at kvitteringen er troværdig og dækker det korrekt. Det er stadig vigtigt at gemme den resulterende beslutning om tilskud, mismatch politik, og recovery state. Et system kan modtage den samme identifikator gentagne gange, modtage det sent, eller modtage det med en nyttelast, der ikke passer til den lagrede produktsammenhæng. Den holdbare rekord er, hvad der gør disse tilfælde inspicerbar.
Skal en klient prøve igen automatisk efter en timeout?
Normalt bør det prøve statusopløsning ved hjælp af den samme intention identitet, med afgrænset backoff og klar brugerfeedback. Uanset om det skal genindsende eksterne købsbeviser afhænger af udbyderen og verifikationsdesign. Den usikre adfærd er lydløst at skabe en ny købsanmodning eller anvende et lokalt tilskud, fordi det oprindelige svar blev tabt.
Hvordan adskiller hjælpematerialer sig fra permanente rettigheder?
Permanente rettigheder normalt deduplikere efter konto og produkt. Forbrugsvarer kan tillade det samme produkt, der skal købes mange gange, så den unikke grænse skal omfatte en transaktion identitet eller hovedbog sekvens snarere end produkt ID alene. Begge har stadig brug for en enkelt varig tilskud for hver accepteret hensigt.
Hvad gør Persistium krav her?
Persistium er i udvikling. Denne note forklarer bredt gældende integritet og test- design mønstre; det gør ikke krav på et offentligt køb produkt, platform certificering, kundehændelse historie, eller en hosted service. Dens Kontinuitet retning er interesseret i den samme form for afgrænset dokumentation og replay- sikker recovery disciplin.
