App Engine, transakcje i idempotencja

Question

Proszę, pomóżcie mi znaleźć moje nieporozumienie.

Piszę RPG na App Engine. Pewne działania, które gracz bierze, zużywają pewną statystykę. Jeśli stat osiągnie zero, gracz nie może wykonać więcej akcji. Zacząłem się jednak martwić o oszustów - co jeśli gracz wysłał dwie akcje bardzo szybko, tuż obok siebie? Jeśli kod, który zmniejsza statystyki, nie znajduje się w transakcji, wówczas gracz ma szansę wykonać akcję dwukrotnie. Więc powinienem owinąć kod, który zmniejsza statystyki w transakcji, prawda? Jak na razie dobrze.

W GAE Python, choć mamy to w documentation:

Uwaga: Jeśli aplikacja odbiera wyjątek przy składaniu transakcję, to nie zawsze znaczy że transakcja nie powiodła się. Możesz otrzymywać wyjątki Timeout, TransactionFailedError lub InternalError w przypadkach, w których transakcje zostały zatwierdzone i ostatecznie zostaną pomyślnie zastosowane . Gdy tylko jest to możliwe, twórz transakcje Datastore idempotent tak, aby po powtórzeniu transakcji wynik końcowy był taki sam.

Whoops. Oznacza to, że funkcja biegałam, które wygląda następująco:

def decrement(player_key, value=5): 
    player = Player.get(player_key) 
    player.stat -= value 
    player.put() 

Dobrze, że nie zadziała, ponieważ sprawa nie jest idempotent, prawda? Jeśli umieściłem wokół niego pętlę retry (czy muszę w Pythonie? Czytałem, że nie muszę na SO ... ale nie mogę znaleźć go w dokumentach) może on zwiększyć wartość dwukrotnie, dobrze? Ponieważ mój kod może wychwycić wyjątek, ale magazyn danych nadal zatwierdził dane ... huh? Jak to naprawić? Czy jest to przypadek, w którym potrzebuję distributed transactions? Czy ja naprawdę?

Answer 1

pierwsze, odpowiedź Nicka nie jest poprawna. Transakcja DHayesa nie jest idempotentna, więc jeśli jest uruchamiana wiele razy (tj. Ponowna próba, gdy pierwsza próba została uznana za zakończoną niepowodzeniem, a kiedy nie), to wartość zostanie wielokrotnie zmniejszona. Nick mówi, że "magazyn danych sprawdza, czy jednostki zostały zmodyfikowane, ponieważ zostały pobrane", ale to nie zapobiega problemowi, ponieważ dwie transakcje miały oddzielne pobory, a drugie pobranie było PO pierwszej transakcji zakończonej.

Aby rozwiązać problem, można uczynić transakcję idempotentną, tworząc "klucz transakcji" i rejestrując ten klucz w nowej jednostce jako część transakcji. Druga transakcja może sprawdzić ten klucz transakcji, a jeśli zostanie znaleziony, nic nie da. Klucz transakcji można usunąć, gdy jesteś zadowolony z ukończenia transakcji lub zrezygnujesz z ponawiania próby.

Chciałbym wiedzieć, co "niezwykle rzadkie" oznacza dla AppEngine (1 na milion lub 1 na miliard?), Ale moja rada jest taka, że ​​idempotentne transakcje są wymagane w sprawach finansowych , ale nie dla wyników gier, ani nawet "żyć" ;-)

Answer 2

Nie powinieneś próbować przechowywać tego rodzaju informacji w Memcache, który jest znacznie szybszy niż Datastore (coś, czego będziesz potrzebować, jeśli ta stat jest często używana w twojej aplikacji). Memcache zapewnia piękny funkcję: decr których:

atomowo zmniejsza wartość klucza jest. Wewnętrznie wartość to 64-bitowa liczba całkowita bez znaku. Memcache nie sprawdza przekroczeń 64-bitowych. Wartość, jeśli jest zbyt duża, będzie się zawijać.

Szukaj decrhere. Następnie należy użyć zadania, aby zapisać wartość w tym kluczu do magazynu danych co x sekund lub gdy określony warunek zostanie spełniony.

Answer 3

Jeśli uważnie zastanowisz się nad tym, co opisujesz, może to nie być problem. Pomyśl o tym w ten sposób:

Gracz ma jeszcze jeden punkt statystyk. Następnie złośliwie wysyła natychmiast 2 akcje (A1 i A2), z których każda musi skonsumować ten punkt. Zarówno A1, jak i A2 są transakcyjne.

Oto co może się zdarzyć:

A1 powiedzie. A2 następnie przerwie. Wszystko dobrze.

A1 nie działa prawidłowo (bez zmiany danych). Spróbuj ponownie. A2 następnie próbuje, kończy się sukcesem. Gdy A1 spróbuje ponownie, zostanie przerwane.

A1 powiedzie się, ale zgłasza błąd. Spróbuj ponownie. Następnym razem, gdy A1 lub A2 spróbuje, zostaną przerwane.

Aby to zadziałało, musisz mieć kontrolę nad tym, czy A1 i A2 zostały zakończone - może dać im UUID zadania i zapisać listę wykonanych zadań? Lub nawet po prostu użyć kolejki zadań.

Answer 4

Edytuj: To jest nieprawidłowe - zapoznaj się z komentarzami.

Twój kod jest w porządku. Idempotencja, do której odnoszą się docs, dotyczy skutków ubocznych. Jak wyjaśniają doktorzy, twoja funkcja transakcyjna może być uruchamiana więcej niż jeden raz; w takich sytuacjach, jeśli funkcja ma jakieś skutki uboczne, będą one stosowane wielokrotnie. Ponieważ funkcja transakcyjna tego nie robi, wszystko będzie dobrze.

Przykładem problematycznej funkcji w odniesieniu do idempotentność byłoby coś takiego:

def do_something(self): 
    def _tx(): 
    # Do something transactional 
    self.counter += 1 
    db.run_in_transaction(_tx) 

W tym przypadku self.counter może być zwiększony o 1, lub potencjalnie więcej niż 1. Można tego uniknąć, wykonując skutki uboczne poza transakcją:

def do_something(self): 
    def _tx(): 
    # Do something transactional 
    return 1 
    self.counter += db.run_in_transaction(_tx)