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执行，否则网络和解析开销不小。
