App Engine, Transaktionen und Idempotenz

Question

Bitte helfen Sie mir mein Missverständnis zu finden.

Ich schreibe ein RPG auf App Engine. Bestimmte Aktionen des Spielers verbrauchen einen bestimmten Wert. Wenn der Wert Null erreicht, kann der Spieler keine Aktionen mehr ausführen. Ich fing an, mir Gedanken darüber zu machen, ob ich Spieler betrügen könnte - was wäre, wenn ein Spieler zwei Aktionen sehr schnell, direkt nebeneinander schickte? Wenn der Code, der den Wert dekrementiert, nicht in einer Transaktion ist, hat der Spieler die Chance, die Aktion zweimal auszuführen. Also sollte ich den Code, der die Statistik dekrementiert, in eine Transaktion einbinden, oder? So weit, ist es gut.

In GAE Python, aber wir haben dies in den documentation:

Hinweis: Wenn Ihre Anwendung eine Ausnahme empfängt, wenn eine Transaktion einreichen, ist es nicht bedeutet immer, dass die Transaktion fehlgeschlagen. Sie können Timeout-, TransactionFailedError- oder InternalError-Exceptions in Fällen empfangen, in denen Transaktionen festgeschrieben wurden und schließlich erfolgreich angewendet werden. Wenn möglich, machen Sie Ihre Datastore-Transaktionen so Idempotent, dass , dass, wenn Sie eine Transaktion wiederholen, das Endergebnis das gleiche sein wird.

Whoops. Das bedeutet, dass die Funktion, die ich, dass lief wie folgt aussieht:

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

Nun, das wird nicht funktionieren, weil die Sache nicht idempotent, nicht wahr? Wenn ich eine Wiederholungsschleife darum herumlege (muss ich in Python? Ich habe gelesen, dass ich nicht auf SO muss ... aber ich kann es nicht in den Dokumenten finden), könnte es den Wert zweimal erhöhen, Recht? Da mein Code eine Ausnahme abfangen kann, aber der Datenspeicher die Daten trotzdem festlegt ... hm? Wie behebe ich das? Ist das ein Fall, wo ich distributed transactions brauche? Tue ich wirklich?

Answer 1

Zunächst ist Nick's Antwort nicht korrekt. Die Transaktion von DHayes ist nicht idempotent. Wenn sie mehrmals ausgeführt wird (dh ein erneuter Versuch, wenn der erste Versuch als fehlgeschlagen galt, wenn dies nicht der Fall war), wird der Wert mehrmals dekrementiert. Nick sagt, dass "der Datenspeicher überprüft, ob die Entitäten seit dem Abrufen geändert wurden", aber das verhindert das Problem nicht, da die beiden Transaktionen getrennte Abrufe hatten und der zweite Abruf NACH der ersten abgeschlossenen Transaktion erfolgte.

Um das Problem zu lösen, können Sie die Transaktion idempotent machen, indem Sie einen "Transaktionsschlüssel" erstellen und diesen Schlüssel in einer neuen Entität als Teil der Transaktion aufzeichnen. Die zweite Transaktion kann nach diesem Transaktionsschlüssel suchen und wird, wenn sie gefunden wird, nichts tun. Der Transaktionsschlüssel kann gelöscht werden, sobald Sie mit dem Abschluss der Transaktion zufrieden sind oder wenn Sie den Vorgang erneut abbrechen.

Ich würde gerne wissen, was "extrem selten" für AppEngine bedeutet (1-in-einer-Million oder 1-in-einer-Milliarde?), Aber mein Rat ist, dass idempotente Transaktionen für finanzielle Angelegenheiten erforderlich sind , aber nicht für Spielstände oder sogar "Leben" ;-)

Answer 2

Sollten Sie nicht versuchen, diese Art von Informationen in Memcache zu speichern, das ist viel schneller als der Datenspeicher (etwas, das Sie benötigen, wenn dieser Wert häufig in Ihrer Anwendung verwendet wird). Memcache bietet Ihnen eine nette Funktion: decr welche:

Atomically dekrementiert den Wert eines Schlüssels. Intern ist der Wert eine vorzeichenlose 64-Bit-Ganzzahl. Memcache überprüft keine 64-Bit-Überläufe. Der Wert wird, wenn er zu groß ist, umlaufen.

Suchen Sie nach decrhere. Sie sollten dann eine Aufgabe verwenden, um den Wert in diesem Schlüssel entweder alle x Sekunden oder wenn eine bestimmte Bedingung erfüllt ist, im Datenspeicher zu speichern.

Answer 3

Wenn Sie genau darüber nachdenken, was Sie beschreiben, ist es möglicherweise kein Problem. Denken Sie darüber nach:

Ihr Spieler hat einen Statpunkt übrig. Er sendet dann böswillig 2 Aktionen (A1 und A2), die diesen Punkt sofort verbrauchen müssen. Sowohl A1 als auch A2 sind transaktional.

Hier ist, was passieren könnte:

A1 erfolgreich ist. A2 wird dann abgebrochen. Alles gut.

A1 schlägt rechtmäßig fehl (ohne Daten zu ändern). Wiederholung geplant A2 versucht dann, gelingt. Wenn A1 es erneut versucht, wird es abgebrochen.

A1 ist erfolgreich, meldet jedoch einen Fehler. Wiederholung geplant Wenn A1 oder A2 das nächste Mal versuchen, werden sie abgebrochen.

Damit dies funktioniert, müssen Sie nachverfolgen, ob A1 und A2 abgeschlossen sind - geben Sie ihnen vielleicht eine Aufgaben-UUID und speichern Sie eine Liste abgeschlossener Aufgaben? Oder benutze einfach nur die Aufgabenwarteschlange.

Answer 4

Edit: Das ist falsch - bitte beachten Sie die Kommentare.

Ihr Code ist in Ordnung. Die Idempotenz, auf die sich die Dokumente beziehen, bezieht sich auf Nebenwirkungen. Wie die Dokumentation erklärt, kann Ihre Transaktionsfunktion mehr als einmal ausgeführt werden. In solchen Situationen, wenn die Funktion irgendwelche Nebenwirkungen hat, werden sie mehrmals angewendet. Da Ihre Transaktionsfunktion dies nicht tut, ist es in Ordnung.

Ein Beispiel für eine problematische Funktion in Bezug auf idempotence etwas so sein würde:

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

In diesem Fall, indem Sie durch 1 oder möglicherweise mehr als 1. Dies könnte vermieden werden, erhöht werden kann self.counter die Nebenwirkungen außerhalb der Transaktion:

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