Stellen Sie sich zwei gleichzeitige Transaktionen vor, die um Mitternacht stattfinden. Beide können get(dt_key) ausführen, aber einer führt zuerst den MULTI/EXEC-Block aus. Es setzt den Zähler zurück, stellt das neue Datum ein und erhöht den Zähler. Der zweite wird ebenfalls in seinen MULTI/EXEC-Block eintreten, aber da sich der Wert von 'dt' geändert hat, schlägt die Ausführung fehl und incr_daily_number wird erneut aufgerufen. Dieses Mal gibt get(dt_key) das neue Datum zurück, sodass der Zähler bei Ausführung des MULTI/EXEC-Blocks ohne Zurücksetzen inkrementiert wird. Die beiden Transaktionen geben das neue Datum mit unterschiedlichen Zählerwerten zurück.
Ich glaube also, dass es hier keine Rassenbedingung gibt und dass die (Datum, Zahl)-Paare eindeutig sein werden.
Sie hätten dies auch mit einem serverseitigen Lua-Skript implementieren können (dessen Ausführung immer atomar ist). Das ist normalerweise bequemer.
Beachten Sie, dass es eigentlich keine Redis-Sperre gibt. Der in der API verfügbare Sperrmechanismus wird vom Python-Client bereitgestellt – nicht vom Redis-Server. Wenn Sie sich die Implementierung ansehen, werden Sie feststellen, dass sie auch auf SETNX + WATCH/MULTI/EXEC-Blöcken oder Lua-Skripten basiert.
