Considérons deux transactions simultanées se produisant à minuit. Les deux peuvent exécuter get(dt_key), mais l'un exécutera d'abord le bloc MULTI/EXEC. Il réinitialisera le compteur, réglera la nouvelle date, incrémentera le compteur. Le second entrera également dans son bloc MULTI/EXEC, mais comme la valeur de 'dt' a changé, l'exécution échouera et incr_daily_number sera appelé à nouveau. Cette fois, get(dt_key) renverra la nouvelle date, donc lorsque le bloc MULTI/EXEC sera exécuté, le compteur sera incrémenté sans aucune réinitialisation. Les deux transactions renverront la nouvelle date avec des valeurs de compteur différentes.
Donc, je crois qu'il n'y a pas de condition de concurrence ici, et que les couples (date, nombre) seront uniques.
Vous auriez également pu implémenter cela à l'aide d'un script Lua côté serveur (dont l'exécution est toujours atomique). C'est généralement plus pratique.
Notez qu'en réalité, il n'existe pas de verrou Redis. Le mécanisme de verrouillage disponible dans l'API est fourni par le client Python et non par le serveur Redis. Si vous regardez son implémentation, vous vous rendrez compte qu'il est également basé sur des blocs SETNX + WATCH/MULTI/EXEC ou des scripts Lua.
