Una ricerca non è una seconda decisione di acquisto
I flussi di acquisto falliscono nello spazio tra un evento di pagamento esterno e una sovvenzione in-game. Una ricevuta può arrivare due volte. Una richiesta di rete può time out dopo che il server ha commesso lo stato, ma prima che il client ha ricevuto la risposta. Un processo può crash dopo la prenotazione di una transazione ma prima di concedere la valuta.
La distinzione utile è l'intento contro la sovvenzione. Intento è la richiesta di ottenere un prodotto specifico in base a una specifica identità di transazione. Grant è l'esito durevole del gioco: diritto di proprietà, un delta di valuta, un oggetto di inventario, o un periodo di abbonamento. Lo stesso intento può essere consegnato, interrogato, retried, o ridistribuito molte volte.
Questo è un modello di ingegneria, non una garanzia specifica della piattaforma. Diversi negozi, fornitori di pagamento e backend di gioco espongono diverso ricevimento, il riconoscimento e il comportamento di rimborso. Non assumere una ricevuta dimostra una sovvenzione, o che un riconoscimento dimostra che il giocatore ha visto un elemento.
Dare ad ogni intento di acquisto una chiave stabile
Una chiave di idempotency lega ripetuti tentativi di consegna a una decisione. Può derivare da un identificatore di transazione di piattaforma di fiducia quando l'identificatore è disponibile e verificato, o può essere rilasciato da un server prima che un acquisto inizia e poi collegato a informazioni di ricezione attendibili. La chiave deve essere stabile tra i ripetitori.
Conservare il contesto sufficiente con la chiave per rifiutare i mismatches: il giocatore o la portata del conto, l'identità del prodotto, la quantità prevista o la forma del diritto, il canale sorgente, il tempo ricevuto, lo stato di verifica, e uno stato come in attesa, commesso, rifiutato o bisogno-review.
Per un diritto non consumabile, l'unicità potrebbe essere l'account più l'ID del prodotto. Per la moneta, l'unicità è di solito l'entrata del registro o la transazione di sovvenzione piuttosto che l'equilibrio attuale. Per i materiali di consumo, un identificatore di transazione affidabile può essere unico anche quando l'ID del prodotto ripete. Definire la chiave prima di codificare la politica di riprovazione; altrimenti due sottosistemi possono deduplicare contro le identità compatibili.
Modello il risultato commit sconosciuto
Il risultato difficile non è un successo pulito o un fallimento pulito. È “sconosciuto”: il client non sa se il server ha commesso la sovvenzione. Un timeout, il ripristino della connessione, il riavvio del processo, o l'interruzione del servizio può produrre questo stato. Il comportamento client sicuro è quello di chiedere lo stato della transazione o riprovare lo stesso intento. Il comportamento del server sicuro è quello di cercare tale intento e restituire la decisione durevole piuttosto che applicare un'altra mutazione.
Non rendere autorevole lo stato di visualizzazione del cliente. Un spinner scompare, una cache di ricezione locale, o un cambiamento di equilibrio ottimista può migliorare l'esperienza, ma non può decidere se l'account possiede un diritto.
La sequenza dovrebbe rendere visibile la politica di compensazione parziale. Ad esempio: ricevere l'intento, convalidare le prove di acquisto attendibili, creare o caricare il record di registro durevole, commettere il diritto o la mutazione di valuta, contrassegnare il record concesso, riconoscere la consegna esterna, quindi restituire il risultato.
Proteggere il diritto e la valuta invarianti
Una chiave di idempotency impedisce il rigioco di un intento; non fa automaticamente correggere ogni effetto collaterale. Definire gli invarianti una sovvenzione deve preservare. Un diritto non consumabile appare al massimo una volta per il conto e il prodotto. Una sovvenzione di valuta ha una voce di registro con una chiave di transazione, un delta noto, e un saldo risultante che corrisponde alla somma delle voci valide.
Fare la parte di controllo invariante dello stesso funzionamento durevole che commette la sovvenzione. Una lettura seguita da una scrittura successiva può gareggiare sotto consegna concomitante. Due lavoratori possono entrambi osservare “non posseduto” ed entrambi sovvenzione. Utilizzare lo storage transazionale, confrontare-e-set semantics, un percorso di mutazione del conto serializzato, o un altro primitivo convaluta esplicita adatto al data store.
Per i giochi con un runtime in-memory, distinguere il successo durevole dalla presentazione. Il server può aggiornare l'equilibrio visibile di un giocatore dopo che l'entrata del registro duraturo commette, ma l'aggiornamento visibile non è la prova.
Test crash, riavviamenti e ridisegna deliberatamente
Iniziare con uno scenario deterministico. Creare un account, un prodotto, un bilancio di partenza noto o un set di diritto, e una chiave di transazione stabile. Eseguire il flusso, quindi iniettare un fallimento dopo ogni confine denominato: dopo l'accettazione del ricevimento, dopo la creazione del registro, dopo la mutazione del diritto, dopo la marcatura dello stato, dopo il riconoscimento esterno, e dopo la risposta è preparata.
Il risultato previsto dovrebbe essere specifico. Una riprovazione può restituire “già concesso” con il risultato originale, riprendere un'operazione in sospeso, rifiutare un carico utile errato, o tenere un record per la revisione. Non dovrebbe aggiungere un secondo elemento di inventario, applicare un secondo delta valuta, o nascondere lo stato sconosciuto con un successo fabbricato.
Utilizzare la ridistribuzione della ricevuta nello stesso scenario. Consegnare l'esatta transazione di fiducia due volte, quindi consegnarla dopo un riavvio, quindi consegnarla accanto a una ripetizione del client duplicato. Lo stato del registro e dell'account risultante dovrebbe essere identico al caso della consegna singola. Se il prodotto permette di ripetere gli acquisti, eseguire la stessa sequenza con due identità di transazione autenticamente distinte per dimostrare che il sistema non sovra-deduplica da solo l'ID del prodotto.
Tenere i confini onesti
Una risposta del fornitore simulato può convalidare la macchina statale, ma non è la prova che ogni bordo del fornitore di produzione si comporta esattamente allo stesso modo. Un test eseguibile contro una sandbox può aggiungere fiducia per tale integrazione, ma ha ancora diverse condizioni operative da un negozio live.
Un client non deve presentare un importo arbitrario, un ID del prodotto o una bandiera "verificata" e ricevere una sovvenzione. Gli input non sono attendibili fino a quando il server non li convalida contro la configurazione rilevante e le prove di acquisto. Se la convalida non può finire, mantenere l'intento in attesa o rifiutarlo con una categoria recuperabile.
I registri dovrebbero fare riferimento a un identificatore di prova sicuro, non a una ricevuta cruda o a un nome di conto. Un incidente di produzione può richiedere prove limitate, ma la suite di test di routine non dovrebbe mai diventare un secondo deposito di dati di pagamento.
Controllo pratico
- Separare un intento di acquisto stabile dalla concessione successiva.
- Utilizzare una chiave di idempotency attraverso timeout, retries, riavviamenti, e la consegna della ricevuta.
- Legare la chiave per il conto, la forma del prodotto o del diritto, e il contesto sorgente di fiducia.
- Definire stati durevoli come in attesa, commesso, respinto e la revisione dei bisogni.
- Enforce autorizza l'unicità e gli invarianti del registro valutario all'interno dello stesso limite di garanzia della sovvenzione.
- Iniezione fallimenti dopo ogni transizione statale, quindi riavviare e riprovare lo stesso intento.
- Prova la consegna duplicata e gli acquisti legittimi di ripetizione separatamente.
- Rapporto risultati sconosciuti onestamente; non trasformare un timeout in un successo inventato.
- Mantenere i dispositivi e i registri di prova sintetici e rifatti.
Domande frequenti
È un ID di ricezione unico abbastanza per idempotency?
Può essere un componente utile quando il server può verificare che l'identità di ricezione è affidabile e che lo scopo correttamente. È ancora importante memorizzare la decisione di concessione risultante, la politica di errore e lo stato di recupero. Un sistema può ricevere lo stesso identificatore ripetutamente, riceverlo in ritardo, o riceverlo con un payload che non corrisponde al contesto del prodotto memorizzato.
Un cliente dovrebbe riprovare automaticamente dopo un timeout?
Di solito dovrebbe riprovare la risoluzione dello stato utilizzando la stessa identità intenta, con un backoff limitato e un feedback chiaro dell'utente. Se dovesse resubmit le prove di acquisto esterne dipendono dal fornitore e dal disegno di verifica. Il comportamento non sicuro sta silenziosamente creando una nuova richiesta di acquisto o applicando una sovvenzione locale perché la risposta originale è stata persa.
Come i consumabili differiscono dai diritti permanenti?
I consumatori possono permettere che lo stesso prodotto sia acquistato molte volte, quindi il limite di unicità deve includere un'identità di transazione o una sequenza di registro, piuttosto che l'ID di prodotto da solo.
Cosa afferma Persistium qui?
Persistium è in fase di sviluppo. Questa nota spiega i modelli di integrità e di progettazione di test ampiamente applicabili; non rivendica un prodotto di acquisto pubblico, la certificazione della piattaforma, la storia dell'incidente del cliente, o un servizio ospitato.
