stackexchange.redis 的 transaction 不保证真正原子性，本质是基于 watch+multi/exec 的乐观锁，冲突时 exec 返回 null 而非回滚；应改用 lua 脚本通过 scriptevaluateasync 实现真原子性，脚本须纯操作 redis 且参数经 keys/argv 传入。
Redis 在 C# 高并发下原子性失效的典型表现
直接说结论：StackExchange.Redis 的 Transaction（IDatabase.CreateTransaction()）在 Redis 服务端**不保证真正原子性**——它底层是基于 WATCH + MULTI/EXEC 实现的乐观锁，一旦被监控的 key 在事务执行前被其他客户端修改，整个 EXEC 就会返回 null，事务失败。这不是“回滚”，而是“放弃执行”。很多 C# 开发者误以为 transaction.ExecuteAsync() 成功就等于原子完成，结果在压测时出现数据错乱。
用 Lua 脚本替代 Transaction 实现真原子性
Lua 脚本在 Redis 中是单线程原子执行的，只要脚本逻辑正确，无论多少并发调用，Redis 都不会中断或交错执行。C# 中通过 IDatabase.ScriptEvaluateAsync() 提交脚本即可。
常见错误：把复杂业务逻辑全塞进 Lua，导致脚本过长、难以调试、阻塞 Redis 主线程；或在 Lua 里做 HTTP 请求、时间计算等非纯 Redis 操作——这些在 Lua 中根本不可行。
- 脚本必须只操作 Redis 数据结构，所有输入参数通过
KEYS和ARGV传入 - C# 调用时，
KEYS传的是 key 名列表（如new[] { "user:1001", "balance:1001" }），ARGV传字符串参数（数字也要转成 string） - 避免在 Lua 中用
redis.call("GET", ...)多次读取再判断——应改用redis.call("HGET", ...)或管道化操作减少往返
string luaScript = @"
local balance = tonumber(redis.call('HGET', KEYS[1], 'balance'))
if not balance or balance < tonumber(ARGV[1]) then
return 0
end
redis.call('HINCRBYFLOAT', KEYS[1], 'balance', '-' .. ARGV[1])
redis.call('LPUSH', KEYS[2], ARGV[2])
return 1
";
<p>var result = await db.ScriptEvaluateAsync(
luaScript,
new RedisKey[] { "user:1001", "user:1001:history" },
new RedisValue[] { "99.5", "deduct_20240520_abc" });StackExchange.Redis Transaction 的适用边界
事务不是不能用，而是得清楚它只适合「低冲突、高成功率」场景，比如批量写入互不干扰的 key，或配合业务层重试逻辑。
容易踩的坑：
-
transaction.StringSetAsync("k1", "v1")和transaction.HashSetAsync("k2", hashEntries)混用时，如果其中一个失败（如 key 类型不匹配），整个EXEC仍可能成功返回部分结果——因为 Redis 不校验命令间依赖 -
WATCH的 key 必须和事务中操作的 key 完全一致，大小写、前缀都不能差；watch 多个 key 时，任一被改都会导致失败 - 事务内不能跨数据库（
SELECT），StackExchange.Redis 默认只连一个 database，所以这点影响不大
性能与可维护性的实际权衡点
Lua 脚本快且原子，但调试困难、上线需重新加载（SCRIPT LOAD）、版本管理麻烦；Transaction 更易读易测，但需要业务层处理 ExecuteAsync() 返回 false 的情况并重试。
真实建议：
- 扣款、库存预占这类强一致性要求的操作，必须用 Lua
- 日志记录、状态标记等幂等写入，可用 Transaction + 最多重试 2 次
- 不要在 Lua 脚本里解析 JSON 或做浮点精度运算——Redis 的 Lua 不支持
math.round，tonumber("1.01")可能丢失精度，要用redis.call("HINCRBYFLOAT")这类原生命令
最常被忽略的一点：Lua 脚本的 SHA1 值会被 Redis 缓存，但 ScriptEvaluateAsync 每次都发完整脚本。高频调用时，应先用 ScriptLoadAsync 缓存，再用 ScriptEvaluateShaAsync 执行，否则网络和解析开销不小。
