Considere dos transacciones simultáneas que ocurren a la medianoche. Ambos pueden ejecutar get(dt_key), pero uno ejecutará primero el bloque MULTI/EXEC. Reiniciará el contador, establecerá la nueva fecha, incrementará el contador. El segundo entrará también en su bloque MULTI/EXEC, pero debido a que el valor de 'dt' ha cambiado, la ejecución fallará y se volverá a llamar a incr_daily_number. Esta vez, get(dt_key) devolverá la nueva fecha, por lo que cuando se ejecute el bloque MULTI/EXEC, el contador se incrementará sin ningún reinicio. Las dos transacciones devolverán la nueva fecha con diferentes valores de contador.
Entonces, creo que aquí no hay una condición de carrera, y que las parejas (fecha, número) serán únicas.
También podría haber implementado esto usando un script Lua del lado del servidor (cuya ejecución es siempre atómica). Por lo general, es más conveniente.
Tenga en cuenta que, en realidad, no existe un bloqueo de Redis. El mecanismo de bloqueo disponible en la API lo proporciona el cliente Python, no el servidor Redis. Si observa su implementación, se dará cuenta de que también se basa en bloques SETNX + WATCH/MULTI/EXEC o secuencias de comandos Lua.
