Ponowna próba nie jest drugą decyzją o zakupie
Przepływy zakupu nie powiodły się w przestrzeni pomiędzy zewnętrznym zdarzeniem płatniczym a dotacją w grze. Paragon może przybyć dwa razy. Żądanie sieciowe może zakończyć się po stanie popełnionym przez serwer, ale zanim klient otrzymał odpowiedź. Proces może spaść po zarezerwowaniu transakcji, ale przed przyznaniem waluty. Na ponownym uruchomieniu, najbezpieczniejszym działaniem może być ponowne wykonanie pracy, która została przerwana. Jeśli system traktuje każde powtórzenie jako pozwolenie na przyznanie, duplikaty uprawnień są normalną konsekwencją odzyskania.
Użytecznym rozróżnieniem jest intencja kontra dotacja. Intent to prośba o uzyskanie określonego produktu pod konkretną tożsamością transakcji. Dotacja jest trwałym wynikiem: prawo własności, delta waluta, pozycja inwentaryzacyjna lub okres subskrypcji. Ten sam zamiar może być dostarczony, zapytany, ponownie wypróbowany lub ponownie dostarczony wiele razy.
Jest to wzór inżynieryjny, a nie gwarancja specyficzna dla platformy. Różne sklepy, dostawcy płatności, i backends gry ujawniają inny paragon, potwierdzenie i zachowanie zwrotu. Nie zakładaj, że paragon dowodzi dotacji, lub że potwierdzenie dowodzi, że gracz widział element. Build the server- side record so the game can state what it knows and recovery safely when an external result is complete or late.
Daj każdemu celowi zakupu stabilny klucz
Klucz idepotencji wiąże powtarzające się próby dostawy do jednej decyzji. Może on pochodzić z zaufanego identyfikatora transakcji platformy, gdy ten identyfikator jest dostępny i zweryfikowany, lub może być wydany przez serwer przed rozpoczęciem zakupu i związane później z zaufanymi informacjami o paragonie. Klucz musi być stabilny w czasie powtórzeń. Tworzenie nowego losowego klucza za każdym razem, gdy klient naciska "przywracanie" po prostu tworzy wiele transakcji, które się zdarza, aby wyglądać podobnie.
Przechowuj wystarczający kontekst z kluczem do odrzucenia rozbieżności: gracz lub zakres konta, tożsamość produktu, przewidywana ilość lub kształt uprawnień, kanał źródłowy, otrzymany czas, status weryfikacji i stan, taki jak oczekujący, zaangażowany, odrzucony lub neess- review. Zachowaj wrażliwe materiały kwitowe z zwykłych dzienników. Jeśli surowiec dostawca płatności wymaga krótkiego zatrzymywania dla zweryfikowanego przepływu odzysku, chronić je oddzielnie i uczynić ich dostęp celowe.
Model danych potrzebuje również granicy wyjątkowości. Dla uprawnienia nienadającego się do konsumpcji, niepowtarzalność może być rachunkiem plus ID produktu. Dla waluty, unikalność jest zazwyczaj wpisem do księgi lub transakcji dotacji, a nie bieżącym saldem. W przypadku materiałów konsumpcyjnych, zaufany identyfikator transakcji może być niepowtarzalny nawet wtedy, gdy identyfikator produktu powtarza się. Zdefiniuj klucz przed kodowaniem polityki ponownego testowania; w przeciwnym razie dwa podsystemy mogą zdedukować się z niekompatybilnymi tożsamościami.
Wzoruj nieznany wynik commit
Trudny wynik nie jest czysty sukces lub czyste niepowodzenie. Jest "nieznany": klient nie wie, czy serwer popełnił dotację. Czas, reset połączenia, proces restart, lub przerwa usługi może produkować ten stan. Bezpieczne zachowanie klienta jest poprosić o status transakcji lub spróbować ponownie ten sam zamiar. Zachowanie serwera jest sprawdzić, że zamiar i zwrócić trwałą decyzję zamiast stosowania innej mutacji.
Nie należy dokonywać autorytatywnego wyświetlania stanu klienta. Spinner znikający, lokalny cache paragon lub optymistyczna zmiana salda może poprawić doświadczenie, ale nie może zdecydować, czy konto posiada uprawnienia. Serwer oznacza, że serwer weryfikuje zaakceptowaną transakcję zgodnie z granicami zaufania produktu, wprowadza trwały rekord raz, i zwraca obecny stan, gdy zapyta ponownie.
Sekwencja powinna sprawić, że polityka częściowej realizacji będzie widoczna. Na przykład: otrzymać intencję, potwierdzić zaufanych dowodów zakupu, utworzyć lub załadować trwały rejestr, popełnić uprawnienia lub mutacja waluty, zaznaczyć rekord przyznany, potwierdzić zewnętrznej dostawy, a następnie zwrócić wynik. Jeśli proces zatrzymuje się między dwoma etapami, pracownik odzyskiwania lub późniejsze zapytanie statusu może wznowić z trwałego rekordu. Dokładne zamówienie zależy od zewnętrznego dostawcy i architektury gry, ale pojedyncza tożsamość dotacji nie.
Ochrona uprawnień i niezbywalnych aktywów walutowych
Klawisz idepotencji zapobiega powtórzeniu jednej intencji; nie czyni to automatycznie każdego efektu ubocznego poprawnym. Zdefiniuj niezbywalnych, które dotacja musi zachować. Niekonsumowane uprawnienie pojawia się co najmniej raz dla konta i produktu. Dotacja walutowa ma wpis do rejestru z jednym kluczem transakcji, znana delta, i wynikająca z niego równowaga, która odpowiada sumie ważnych wpisów. Inventory grants posłuszne stosu, pojemności, item- definition rules. Okres subskrypcji nie przedłuża się dwukrotnie, ponieważ punkt końcowy potwierdzenia działał dwukrotnie.
Zrobić niezmienny sprawdzić część tej samej trwałej operacji, która zobowiązuje dotację. Odczyt, a następnie późniejszy zapis może ścigać się pod równoczesną dostawą. Dwóch pracowników może zarówno obserwować "nie należący" i obu dotacji. Użyj transakcyjnej pamięci masowej, porównaj i-set semantyki, seryjnej ścieżki mutacji konta, lub innej wyraźnej konkubiny prymitywne dostosowane do przechowywania danych. Ważną właściwością jest to, że decyzja i jej marker nie mogą być niezależnie wygrane dwoma próbami.
W przypadku gier z runtime in- memory, odróżnić trwały sukces od prezentacji. Serwer może zaktualizować widoczną równowagę gracza po trwałym wpisem rejestru commits, ale widoczna aktualizacja nie jest dowodem. Po ponownym podłączeniu lub ponownym uruchomieniu, odbudować przedstawiony stan z trwałego rekordu konta. To sprawia, że opóźniona odpowiedź klienta niewygodnie, a nie finansowo niebezpieczne.
Awarie testowe, ponowne uruchomienie i ponowne dostarczenie celowo
Zacznij od scenariusza determinującego. Utwórz jedno konto, jeden produkt, jeden znany bilans początkowy lub zestaw uprawnień i jeden stabilny klucz transakcji. Uruchom przepływ, a następnie wstrzyknij niepowodzenie po każdej nazwie granicy: po akceptacji odbioru, po utworzeniu rejestru, po mutacji uprawnień, po oznaczeniu statusu, po potwierdzeniu zewnętrznego i po przygotowaniu odpowiedzi. Przywrócenie odpowiedniego pracownika lub procesu, ponownie spróbować tego samego klucza i potwierdzić ostateczny trwały stan.
Oczekiwany wynik powinien być specyficzny. Ponowna próba może zwrócić "już przyznane" z pierwotnym wynikiem, wznowić oczekiwaną operację, odrzucić niedopasowany ładunek, lub posiadać rekord do przeglądu. Nie powinien on dodać drugą pozycję inwentaryzacji, zastosować drugą walutę delta, lub ukryć nieznany stan ze sfabrykowanym sukcesem. Uchwycić klasyfikację w wyniku testu tak, że późniejszy refaktor nie może przekształcić zamierzonego uchwytu w przypadkowy duplikat.
Użyj redostawy paragonu w tym samym scenariuszu. Dostarcz dokładną, zaufaną transakcję dwa razy, a następnie dostarcz ją po restarcie, a następnie dostarcz ją obok duplikatu powtórnego klienta. Wynikający z tego rejestr i stan konta powinny być identyczne z przypadkiem pojedynczej dostawy. Jeśli produkt pozwala na powtórne zakupy, uruchom tę samą sekwencję z dwoma prawdziwie odrębnymi identyfikacjami transakcji, aby udowodnić, że system nie jest nadduplikowany tylko przez ID produktu.
Zachowaj granice uczciwości
Testy mogą udowodnić jedynie interakcje, które wykonujesz. Symulowana reakcja dostawcy może potwierdzić Twoją maszynę państwową, ale nie jest to dowód na to, że każda krawędź dostawcy produkcji zachowuje się dokładnie w ten sam sposób. Test wykonywalny na piaskownicy może zwiększyć zaufanie do tej integracji, ale nadal ma inne warunki operacyjne niż w sklepie na żywo. Zapisuj, czy scenariusz wykorzystuje symulację, lokalny adapter, piaskownica, czy zweryfikowane środowisko dostawcy.
Granica zaufania powinna być również jasna. Klient nie powinien przedkładać arbitralnej kwoty, ID produktu lub "zweryfikowanej" flagi i otrzymywać dotację. Wpisy są niezaufane, dopóki serwer nie potwierdzi ich z odpowiednią konfiguracją i zakupem dowodów. Jeżeli walidacja nie może zakończyć się, zachować intencję oczekującą lub odrzucić go z kategorii odzyskiwalnej. Nie pozwól kolejki powtórzeń stać się bajpakiem wokół weryfikacji.
Prywatność ma zastosowanie do tej dyscypliny testowej. Fixtures powinny korzystać z syntetycznych danych transakcyjnych. Logy powinny odnosić się do bezpiecznego identyfikatora testu, a nie do nieskazitelnej nazwy rachunku lub rachunku. Incydent produkcyjny może wymagać ograniczonych dowodów, ale rutynowy zestaw testów nigdy nie powinien stać się drugim składem danych płatności.
Praktyczna lista kontrolna
- Oddziel stały zamiar zakupu od późniejszej dotacji po stronie gry.
- Użyj jednego klucza idepotencji przez timeout, ponownie próbuje, ponownie uruchamia, i paragon redostawy.
- Zwiążcie klucz do rachunku, kształtu produktu lub uprawnienia oraz zaufanego kontekstu źródłowego.
- Zdefiniować trwałe państwa, takie jak w oczekiwaniu, zaangażowane, odrzucone i wymaga-przeglądu.
- Wymuszenie wyjątkowości uprawnień i nierezydentów dziennika bieżącego w ramach tej samej granicy konkursowej co dotacja.
- Wstrzyknąć awarie po każdym przejściu stanu, a następnie ponownie uruchomić i ponownie spróbować tego samego zamiaru.
- Test duplikat dostawy i uzasadnione ponowne zakupy oddzielnie.
- Zgłoś nieznane wyniki uczciwie; nie przekształcaj timeout w wymyślony sukces.
- Utrzymuj uchwyty podobne do odbiorników i logi testowe syntetyczne i zredagowane.
Często zadawane pytania
Czy niepowtarzalny dowód tożsamości jest wystarczający dla idepotencji?
Może to być użyteczny składnik, gdy serwer może sprawdzić, czy tożsamość odbioru jest wiarygodna i czy jest ona prawidłowo zakreślana. Nadal ważne jest, aby zachować wynikającą z tego decyzję o przyznaniu dotacji, politykę niedopasowania i stan odzyskiwania. System może otrzymywać ten sam identyfikator wielokrotnie, otrzymywać go późno, lub otrzymywać go z ładunkiem, który nie pasuje do kontekstu przechowywanego produktu. Trwały rekord jest tym, co sprawia, że te przypadki kontroli tabeli.
Czy klient powinien ponownie spróbować automatycznie po przerwie czasowej?
Zazwyczaj należy ponownie spróbować rozdzielczości statusu przy użyciu tej samej tożsamości intencji, z ograniczonym backupem i wyraźną informacją zwrotną dla użytkownika. Czy to powinno przywrócić zewnętrzne dowody zakupu zależy od dostawcy i projektu weryfikacji. Niebezpieczne zachowanie jest cichym tworzenie nowego wniosku o zakup lub stosowanie lokalnej dotacji, ponieważ oryginalna odpowiedź została utracona.
W jaki sposób materiały eksploatacyjne różnią się od stałych uprawnień?
Trwałe uprawnienia zwykle dedukowane przez konto i produkt. Materiały eksploatacyjne mogą pozwolić na zakup tego samego produktu wiele razy, więc granica wyjątkowości musi zawierać tożsamość transakcji lub sekwencję księgową, a nie tylko ID produktu. Oba nadal potrzebują jednej trwałej dotacji dla każdej zaakceptowanej intencji.
Co twierdzi Persistium tutaj?
Persistium jest w fazie rozwoju. Ta uwaga wyjaśnia szeroko stosowaną integralność i wzornictwo testowe; nie rości sobie publicznego zakupu produktu, certyfikacji platformy, historii incydentów klienta lub usługi hostingowej. Jego kierunek ciągłości jest zainteresowany tym samym rodzajem ograniczonego dowodu i odtwarzania- bezpiecznej dyscypliny odzyskiwania.
