redis单个命令原子性的根本原因是主线程串行执行，命令排队依次完成，不切换、不打断；6.0+版本虽有多线程i/o，但命令执行仍由唯一主线程完成，无需锁机制。
Redis 的单个命令是原子性的，根本原因不是“用了锁”或“加了事务”，而是它压根没给其他命令插队的机会——主线程串行执行，命令进来排队、挨个跑完，中间不切换、不打断。
单个命令的原子性靠的是单线程串行执行，不是锁
很多人看到 SETNX 或 INCR 原子，下意识觉得 Redis 内部加了互斥锁。其实没有：Redis 6.0 之前完全单线程；6.0+ 虽引入多线程处理网络 I/O（io-threads），但命令实际执行仍由唯一一个主线程完成。
这意味着：
-
GET、SET、LPUSH这类基础命令，在执行过程中不会被任何其他客户端的命令中断 - 不存在“读取旧值 → 计算 → 写入新值”这种三步操作的竞态窗口——因为这三步本身就被压缩成一个不可拆分的原生命令（如
INCR） - 你用两个客户端同时发
INCR counter，结果一定是 2，绝不会是 1（不会出现“都读到 0，都写 1”的情况）
Redis 事务（MULTI/EXEC）不保证“全成功或全失败”
事务只是把多个命令打包进队列、按序执行，但它不提供回滚能力。一旦 EXEC 开始运行，哪怕中间某条命令报错（比如对字符串执行 HGET），后续命令照常执行。
典型误用场景：
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 想用事务实现“先查后改”，但没加
WATCH—— 这时事务只保证顺序，不保证业务逻辑正确性 - 在事务里混用类型不兼容的命令（如对同一 key 先
SET后HINCRBY），第二条会失败，但第一条已生效 -
WATCH只监控 key 是否被修改，但不阻塞其他客户端——它靠的是乐观检查 + 事务放弃重试，不是加锁
Lua 脚本才是多命令原子组合的可靠方式
当业务逻辑需要条件判断、循环或读写混合（比如“如果 key 不存在则设初值，否则自增”），必须用 EVAL 或 EVALSHA 执行 Lua 脚本。
关键点：
- 整个脚本在主线程中一次性执行完毕，期间不会有其他命令插入
- 脚本能调用所有 Redis 命令（
redis.call('GET', 'x')），还能用if/for控制流程 - 网络开销小：一次请求替代多次往返，避免客户端侧的延迟和重试逻辑
- 注意：
redis.pcall()不抛异常，redis.call()报错会中断脚本——选哪个取决于你是否要兜底处理
真正该警惕的不是“原子性失效”，而是“误以为原子”
最常踩的坑，是把多个独立命令拼在一起，却当成原子操作用：
- 写成
GET key→ 应用层计算 →SET key newval，这三步在网络和应用层之间存在天然时间窗口 - 用
SET key val EX 60 NX实现分布式锁，却忘了在业务完成后主动DEL，或没处理锁过期与业务超时的冲突 - 在集群模式下直接跨 slot 执行多 key 操作（如
MGET多个不同 hash tag 的 key），会被拒绝或路由错误
原子性只管“Redis 主线程内怎么跑”，不管“你的代码怎么调”、“网络怎么传”、“集群怎么分片”。越复杂的逻辑，越要回归到 INCR、GETSET、Lua 这些真正受控的机制上，而不是靠事务或应用层同步去补救。
