Lua 脚本原子性

做的事：同一个"读出来+1再写回去"的逻辑，两种不同的实现方式

一种是客户端自己做两次round-trip(GET，算，SET)，一种是整个逻辑写进一段Lua脚本让Redis自己做。

代码# 非原子版本：20个线程，每个跑50次 def naive_worker(): for _ in range(50): val = int(rr.get("naive_counter")) time.sleep(0.0005) # 模拟应用层在GET和SET之间做了点计算 rr.set("naive_counter", val + 1) # 原子版本：同样的逻辑，整段交给一个Lua脚本 script = """ local v = tonumber(redis.call('GET', KEYS[1])) v = v + 1 redis.call('SET', KEYS[1], v) return v """

验证：非原子版本丢了924次更新

20线程×50次，理论上最终值应该是1000。

结果naive GET-then-SET: expected=1000, actual=76, lost_updates=924, time=0.202s

丢失率高达92.4%——因为GET和SET是两条独立的命令，中间隔着一次客户端本地的sleep(0.0005秒)，这段时间足够让另外19个线程都执行完自己的GET，拿到同一个旧值，最后20个线程几乎都在往同一个"过时的值"上加1再写回去，前面写入的结果被后面的覆盖掉了——这正是经典的丢失更新问题（lost update），根源是"读"和"写"之间存在一个客户端能感知到的时间窗口，别人能在这个窗口里插进来。

验证：Lua脚本版本一次更新都没丢

同样20线程，同样50次，同样的最终目标1000。

结果atomic Lua script: expected=1000, actual=1000, lost_updates=0, time=0.099s

分步演示：924次丢失更新是怎么消失的

每一步都是本文上面用多线程并发压测跑出来的原始结果。