1. Redis原子操作到底怎么实现？
1.1 原子性定义与核心原理
原子性在计算机领域指的是一个操作要么完整执行要么完全不执行，任何中间状态对外不可见。在 Redis 的语义中，原子性意味着一个命令或一组命令在执行期间不会被中断，外部观察者要么看到执行前的状态，要么看到执行后的状态，期间的中间过程对其他客户端不可窥探。
理解这一点的关键在于对 Redis 的执行模型的认知：单线程事件循环确保在任意时刻只有一个客户端在处理请求。这就天然避免了线程切换导致的竞态条件，因此大多数单条命令都是原子执行的，从而满足“要么执行要么失败”的基本要求。
1.2 实现原理的三条主线
首先，单条命令的原子性来自于 Redis 的单线程模式，在一个请求到来时，Redis 会顺序执行该命令，随后再处理下一个请求，期间不会并发执行同一命令的其他实例。
其次，事务（MULTI/EXEC）提供的是“将多条命令组合在一个原子区间内执行”的能力。通过 WATCH、MULTI、EXEC 等组合，可以实现乐观锁、在执行阶段统一提交或回滚的效果。
2. 通过单条命令实现原子性的方法
2.1 单条命令的原子性特征
在 Redis 中，很多计数、集合、哈希等操作的命令本身具有原子性性质，例如 INCR、HINCRBY、SADD、LPUSH、ZADD 等。这些命令在执行时不会被其他命令打断，能保证在多并发场景下的一致性。
单条命令的原子性是高并发场景的首选解决方案，因为它不涉及网络往返和额外的锁开销，性能开销最低，且实现简单直接。
2.2 常见原子性命令示例
下面列举几个常用的原子性命令及简单用法，帮助理解在实际场景中的一致性保障。
# 自增计数，确保并发安全
INCR user:1001:pageviews# 原子地向哈希表中增加字段
HINCRBY user:1001:profile likes 1# 原子地向集合中添加成员
SADD active_users 42
这些命令在执行时不会被打断，且对外部的观察者而言，只有执行完成的状态会被看到，确保了操作的原子性。在设计时，可以优先考虑尽量使用单条命令来完成简单的并发一致性需求，以减少复杂性和延迟。
3. 通过事务（MULTI/EXEC）实现原子性
3.1 事务的工作流程与要点
如果需要把多条相关操作放在同一个原子区间内执行，可以使用WATCH + MULTI + EXEC的组合。流程通常是：先对关键键进行 WATCH，随后进入 MULTI 阶段，添加多条命令，最后执行 EXEC。当在执行期间监视的键被其他客户端修改，EXEC 将返回空，表示本次事务回滚，需要重新执行。
通过这种方式，开发者可以实现复杂的业务流程中的原子性，例如从一个账户扣款并同时记账、或在一个库存系统中扣减库存并增加销售记录。整个过程要么在单次 EXEC 内完成，要么在中途被外部修改时不执行任何改动，从而避免部分执行带来的不一致性。
3.2 WATCH 的使用场景与注意事项
WATCH 机制适用于需要乐观锁的场景：在提交事务前，检测关键键是否被其他客户端修改。如果被修改，当前事务会被撤销，开发者可以选择重试逻辑。
需要注意的是，事务中的命令在 EXEC 时才真正执行；在 EXEC 之前的命令只是被放入队列，直到确认提交时才一次性执行完毕。长期持有 WATCH 的键可能导致阻塞，设计上应避免在事务内进行耗时操作或阻塞性查询。
4. 使用 Lua 脚本实现原子性
4.1 为什么 Lua 脚本天然具备原子性
Redis 内置的 Lua 引擎在执行 EVAL 脚本时会独占当前 Redis 实例的执行权，整个脚本在一个原子单元内执行，不会被其他命令打断。这也意味着在脚本执行过程中对 KEYS/ARGV 的访问具备一致性。
使用 Lua 脚本可以把一个复杂的原子性需求封装成一个单独的可复用逻辑，减少客户端和服务端之间的往返次数，从而提升性能和稳定性。
4.2 常见示例：扣减库存、幂等性与转账等
以一个简单的库存扣减和订单创建的原子性为例，可以使用 Lua 脚本在一个执行块中完成从库存到下单的完整流程，避免在多步操作中产生不一致。
-- Lua 脚本示例：从库存扣减并标记订单状态
-- KEYS[1] 库存键，KEYS[2] 订单键
-- ARGV[1] 需扣减的数量
local stock = tonumber(redis.call('GET', KEYS[1]))
local need = tonumber(ARGV[1])if stock == nil then return -1 end
if stock < need then return 0 endredis.call('DECRBY', KEYS[1], need)
redis.call('SET', KEYS[2], 'PENDING')
return 1
通过上述脚本，可以在一次执行内完成库存校验、扣减以及状态变更等操作，避免了跨网络和多次交互带来的竞态风险，并且在需要幂等性或复杂逻辑时尤为有用。
5. 典型应用场景与性能对比
5.1 典型应用场景
在高并发场景中，计数器、分布式锁、限流、幂等性处理、库存扣减等需求经常需要原子性保障。单条命令原子性适用于简单的并发计数、集合并发写入等，能够以最低开销实现一致性。
在需要组合多个步骤才能完成的业务场景，事务（MULTI/EXEC）提供了完整的原子提交能力，避免部分执行导致的数据不一致。当然，事务会带来额外的网络往返和回滚成本，需要结合具体业务来权衡。
5.2 性能对比要点
总体上，单条命令的原子性开销最低，吞吐最高，适合简单并发场景。Lua 脚本的原子性则适合需要多步逻辑且要避免多次客户端往返的场景，但执行时间越长，若资源占用过多，可能影响到其他请求的响应时间。
对于需要复杂控制流的场景，WATCH/MULTI/EXEC 的原子性保障来自乐观锁和原子提交，在冲突较多时可能需要重复执行，但对一致性提供了强有力的保障。不同实现路径的选择，应结合并发等级、延迟容忍度和脚本大小等因素综合评估。
