Tänk på två samtidiga transaktioner som inträffar vid midnatt. Båda kan exekvera get(dt_key), men en kommer att exekvera MULTI/EXEC-blocket först. Det kommer att nollställa räknaren, ställa in det nya datumet, öka räknaren. Den andra kommer också in i sitt MULTI/EXEC-block, men eftersom värdet på 'dt' har ändrats, kommer exekveringen att misslyckas och incr_daily_number kommer att anropas igen. Denna gång kommer get(dt_key) att returnera det nya datumet, så när MULTI/EXEC-blocket kommer att exekveras, kommer räknaren att ökas utan någon återställning. De två transaktionerna kommer att returnera det nya datumet med olika räknarvärden.
Så jag tror att det inte finns något rasvillkor här och att paren (datum, antal) kommer att vara unika.
Du kunde också ha implementerat detta med ett Lua-skript på serversidan (vars exekvering alltid är atomär). Det är vanligtvis bekvämare.
Observera att det faktiskt inte finns något sådant som ett Redis-lås. Låsmekanismen som är tillgänglig i API:t tillhandahålls av Python-klienten - inte av Redis-servern. Om du tittar på dess implementering kommer du att inse att den också är baserad på SETNX + WATCH/MULTI/EXEC-block eller Lua-skript.