O rejudecare nu este o a doua decizie de cumpărare
Fluxurile de cumpărare eşuează în spaţiul dintre un eveniment de plată externă şi o subvenţie în joc. O chitanţă poate sosi de două ori. O cerere de reţea poate dura după ce serverul a comis starea, dar înainte ca clientul să primească răspunsul. Un proces poate să se prăbuşească după rezervarea unei tranzacţii, dar înainte de acordarea unei monede. La repornire, cea mai sigură acţiune poate fi rejudecarea lucrărilor întrerupte. Dacă sistemul tratează fiecare retriere ca permisiune de acordare, drepturile duplicate sunt o consecinţă normală a recuperării.
Distincția utilă este intenția față de grant. Intenția este solicitarea de a obține un anumit produs sub o anumită identitate de tranzacție. Grant este rezultatul durabil al jocului: dreptul de proprietate, o delta valutară, un element de inventar, sau o perioadă de subscriere. Aceeași intenție poate fi livrată, interogat, retried, sau retried de mai multe ori. Ea ar trebui să rezolve în continuare la o decizie de grant.
Acesta este un model de inginerie, nu o garanție specifică platformei. diferite magazine, furnizori de plată, și backend-uri de joc expune diferite chitanță, recunoaștere, și comportamentul de rambursare. Nu presupune o chitanță dovedește o subvenție, sau că o confirmare a văzut un element. Construiți înregistrarea server-side astfel încât jocul poate spune ceea ce știe și recupera în condiții de siguranță atunci când un rezultat extern este incomplet sau întârziat.
Da fiecare intenție de cumpărare o cheie stabilă
O cheie de idempotență leagă încercările repetate de livrare la o singură decizie. Ea poate deriva dintr-un identificator de tranzacție platforma de încredere atunci când acest identificator este disponibil și verificat, sau poate fi emis de către un server înainte de a începe o achiziție și legate mai târziu de informații de primire de încredere. Cheia trebuie să fie stabilă peste retries. Crearea unei noi chei aleatoare de fiecare dată când clientul depaseste
Stochează suficient context cu cheia pentru a respinge neconcordanțele: domeniul de aplicare al jucătorului sau al contului, identitatea produsului, cantitatea preconizată sau forma dreptului, canalul sursă, timpul primit, starea de verificare și un stat cum ar fi așteptarea, comiterea, respingerea sau revizuirea nevoilor. Păstrați materialele sensibile de primire din jurnalele obișnuite. În cazul în care sarcinile utile ale furnizorului brut au nevoie de o reținere scurtă pentru un flux de recuperare verificat, protejați-le separat și faceți-le accesul deliberat.
Modelul de date are nevoie, de asemenea, de o limită de unicitate. Pentru un drept neconsumabil, unicitatea poate fi cont plus ID-ul produsului. Pentru monedă, unicitatea este, de obicei, înregistrarea registru sau tranzacția de grant mai degrabă decât soldul curent. Pentru consumabile, un identificator de tranzacție de încredere poate fi unic chiar și atunci când se repetă ID-ul produsului. Definește cheia înainte de codificarea politicii de retriere; în caz contrar, două subsisteme pot deduplica împotriva identității incompatibile.
Modelează rezultatul comiterii necunoscute
Rezultatul dificil nu este un succes curat sau un eșec curat. Este necunoscut: clientul nu știe dacă serverul a comis grantul. Un timeout, resetare conexiune, repornire proces, sau de serviciu poate produce acest stat. Comportamentul client sigur este de a cere starea tranzacției sau retry aceeași intenție. Comportamentul server în condiții de siguranță este de a privi în sus această intenție și de a returna decizia durabilă, mai degrabă decât de a aplica o altă mutație.
Nu face clientul să afișeze cu autoritate de stat. Un spinner dispare, un cache de primire locală, sau o schimbare optimistă de echilibru poate îmbunătăți experiența, dar nu poate decide dacă contul deține un drept. Autoritatea Server înseamnă că serverul verifică tranzacția acceptată în conformitate cu limita de încredere a produsului, angajează înregistrarea durabilă o dată, și returnează starea curentă atunci când este întrebată din nou.
Secvența ar trebui să facă vizibilă politica de completare parțială. De exemplu: primiți intenție, validați dovezi de cumpărare de încredere, creați sau încărcați registrul de registru durabil, comiteți dreptul sau mutația valutară, marcați înregistrarea acordată, confirmați livrarea externă atunci când este cazul, apoi returnați rezultatul. Dacă procesul se oprește între două etape, un lucrător de recuperare sau interogarea ulterioară a statutului poate relua din registrul durabil. Comanda exactă depinde de furnizorul extern și arhitectura de joc, dar identitatea unică de grant nu.
Protejarea drepturilor și a variabilelor valutare
O cheie de idempotenta previne reluarea unei intentii; aceasta nu face automat fiecare efect secundar corect. Defineste invariantii un grant trebuie sa pastreze. Un drept neconsumabil apare cel mult o data pentru cont si produs. Un grant valutar are o intrare in registru cu o singura cheie de tranzactie, o delta cunoscuta, si un sold rezultat care se potriveste cu suma de inregistrari valide. Granturi inventariale respecta stiva, capacitate, si reguli de definire a elementelor. O perioada de abonare nu se extinde de doua ori deoarece obiectivul de confirmare a fugit de doua ori.
Asigurați-verifica invariant parte a aceleiași operațiuni durabile care angajează grantul. O citire urmată de o mai târziu scrie poate cursa în cadrul livrării concomitente. Doi lucrători pot observa atât ? Nu deținute și ambele grant. Utilizați semantica de stocare tranzacției, compara-și-setați, o cale de mutație cont serializate, sau un alt connection primitiv explicit potrivit pentru magazinul de date. Proprietatea importantă este că decizia și markerul său nu poate fi câștigat în mod independent prin două încercări.
Pentru jocuri cu un runtime in-memorie, distinge succesul durabil de prezentare. Serverul poate actualiza un player. Soldul vizibil după intrarea în registru durabil se angajează, dar actualizarea vizibilă nu este dovada. La reconectarea sau repornirea, reconstrui starea prezentată de recordul de cont durabil. Asta face un răspuns întârziat client inconvenient, mai degrabă decât nesigur financiar.
Accidente de testare, reporniri și relivrare în mod deliberat
Începe cu un scenariu determinist. Creați un cont, un produs, un echilibru de pornire cunoscut sau un set de drepturi, și o cheie de tranzacție stabilă. Rulați fluxul, apoi injectați un eșec după fiecare limită numită: după primirea, după crearea de registru, după mutația dreptului, după marcarea statutului, după confirmarea externă, și după răspunsul este pregătit. Reporniți lucrătorul relevant sau procesul, retry aceeași cheie, și afirma starea finală durabilă.
Rezultatul așteptat ar trebui să fie specific. O retrimitere poate returna bază deja acordată cu rezultatul inițial, relua o operațiune în așteptare, respinge o sarcină utilă neuniform, sau deține un record pentru revizuire. Ea nu ar trebui să adauge un al doilea element de inventar, aplica o delta a doua monedă, sau ascunde starea necunoscută cu un succes fabricat. Captura clasificarea în rezultatul testului, astfel încât un refactor ulterior nu poate transforma o exploatație intenționată într-un duplicat accidental.
Utilizaţi relivrarea chitanţei în acelaşi scenariu. Livraţi tranzacţia de încredere exactă de două ori, apoi livraţi-o după o repornire, apoi livraţi-o alături de o rejudecare duplicată a clientului. Starea de înregistrare şi cont rezultată ar trebui să fie identică cu cazul de livrare unică. În cazul în care produsul permite achiziţii repetate, executaţi aceeaşi secvenţă cu două identităţi de tranzacţie cu adevărat distincte pentru a dovedi că sistemul nu este supra-dedus prin ID-ul produsului numai.
Păstrează limitele cinstite.
Testarea poate dovedi doar interacțiunile pe care le executați. Un răspuns simulat furnizor poate valida mașina de stat, dar nu este o dovadă că fiecare margine furnizor de producție se comportă exact în același mod. Un test executabil împotriva unei cutii de nisip poate adăuga încredere pentru această integrare, dar încă are condiții operaționale diferite de la un magazin live. Înregistrați dacă un scenariu utilizează o simulare, adaptor local, nisip, sau mediu verificat furnizor.
De asemenea, limita de încredere ar trebui să fie clară. Un client nu ar trebui să prezinte o sumă arbitrară, ID-ul produsului, sau steagul verificat și să primească un grant. Intrările sunt neîncredere până când serverul le validează împotriva configurației relevante și să cumpere dovezi. În cazul în care validarea nu poate termina, ține intenția în așteptare sau respinge-l cu o categorie recuperabilă. Nu lăsați o coadă de rejudecare să devină un bypass în jurul verificării.
Confidențialitatea se aplică acestei discipline de testare. Fixările ar trebui să utilizeze date de tranzacție sintetice. Jurnalele ar trebui să facă trimitere la un identificator de test sigur, nu la o chitanță brută sau la un nume de cont. Un incident de producție poate necesita dovezi restrânse, dar suita de testare de rutină nu ar trebui niciodată să devină un al doilea depozit de date de plată.
Lista de verificare practică
- Separați o intenție de cumpărare stabilă de la grantul de mai târziu joc-side.
- Utilizați o cheie idempotency peste timeouts, retriries, reporniri, și relivrare chitanță.
- Legați cheia contului, forma produsului sau a drepturilor și contextul sursă de încredere.
- Definirea unor state durabile, cum ar fi aşteptarea, comiterea, respingerea şi revizuirea necesităţilor.
- Inutilitatea în materie de drepturi și invarianții care au dreptul la monedă străină în cadrul aceleiași limite de schimb valutar ca și grantul.
- Injectaţi eşecurile după fiecare tranziţie de stat, apoi reporniţi şi rejudecaţi aceeaşi intenţie.
- Se testează separat livrarea duplicatului și se repetă cumpărăturile legitime.
- Raportați rezultatele necunoscute sincer; nu transformați un timeout într-un succes inventat.
- Păstrați dispozitive de chitanță și jurnale de testare sintetice și redactate.
Întrebări frecvente
O chitanţă unică este suficientă pentru idempotenţă?
Acesta poate fi o componentă utilă atunci când serverul poate verifica dacă identitatea de primire este de încredere și domeniul de aplicare corect. Este încă important pentru a stoca decizia de grant rezultat, politica de neconcordanță și starea de recuperare. Un sistem poate primi același identificator în mod repetat, primiți-l târziu, sau primiți-l cu o sarcină utilă care nu se potrivește contextului produsului stocat.
Ar trebui un client să încerce automat după un timeout?
De obicei, aceasta ar trebui să retrimeace rezoluţia statutului folosind aceeaşi identitate de intenţie, cu feedback-ul de rezervă şi clar al utilizatorului. Fie că ar trebui să resusciteze dovezi de cumpărare externă depinde de furnizor şi de designul de verificare. Comportamentul nesigur este crearea în tăcere o nouă cerere de cumpărare sau aplicarea unei subvenţii locale, deoarece răspunsul iniţial a fost pierdut.
Cum diferă consumabilele de drepturile permanente?
Drepturile permanente se deduplică de obicei în funcţie de cont şi produs. Consumabilele pot permite acelaşi produs să fie cumpărat de mai multe ori, astfel încât limita unicităţii trebuie să includă o identitate de tranzacţie sau o secvenţă de registru mai degrabă decât o identitate de produs singur. Ambele au nevoie de o singură subvenţie durabilă pentru fiecare intenţie acceptată.
Ce pretinde Persistium aici?
Persistium este în dezvoltare. Această notă explică integritatea larg aplicabile și modele de testare-proiectare; nu pretinde un produs de achiziție publică, certificare platformă, istoricul incidentului clientului, sau un serviciu găzduit. Direcția sa Continuitate este interesat în același tip de dovezi delimitate și replay-safe recuperare disciplina.
