1. 从一次库存超卖事故说起

去年我负责一个电商秒杀项目，核心逻辑很简单：用户点击“立即购买”，系统先检查商品库存，如果库存大于0，则扣减库存，然后生成订单。我们最初的设计是，在应用层用Java代码先执行一次SELECT stock FROM product WHERE id = ?查询库存，判断stock > 0后，再执行UPDATE product SET stock = stock - 1 WHERE id = ?来扣减。上线后风平浪静，但在第一次大促的流量洪峰下，噩梦来了——部分热门商品出现了库存超卖，卖出的数量竟然超过了实际库存。

事后复盘，问题根因就在于这两步操作（查询和更新）不是原子性的。在高并发场景下，两个线程可能同时查询到库存为1，都判断为可售，然后相继执行扣减，最终导致库存被扣成了-1。这就是典型的“竞态条件”。为了解决这个问题，我们几乎毫不犹豫地将库存扣减这个核心操作迁移到了Redis，并使用了它的INCRBY和DECRBY命令。自那以后，再未发生过超卖。今天，我就结合这个踩坑经历，来深入聊聊Redis是如何实现原子性的自增自减操作的，这远不止是一个命令那么简单，背后涉及到Redis的单线程模型、命令的原子性保证以及在高并发业务中的实战应用。

2. Redis命令原子性的基石：单线程事件循环

要理解Redis如何实现原子性自增，首先要抛开对传统数据库“锁”机制的固有印象。Redis的原子性，其核心保障来源于它那经典且高效的单线程事件循环架构。

2.1 为什么单线程反而成了优势？

与MySQL等关系型数据库使用多线程处理并发请求不同，Redis的核心网络I/O和命令执行是由一个主线程串行处理的。这意味着，在任何给定的时刻，Redis服务器只会执行一个客户端发来的命令。当多个客户端同时发送INCR key命令时，这些命令会在Redis的队列中排队，被主线程一个一个地顺序执行。

这就从根本上杜绝了并发冲突。因为不存在两个线程同时操作同一个内存数据的情况。对于一个键stock:1001的INCR或DECR操作，从读取旧值、计算新值到写回内存的整个过程，对于其他命令来说是不可分割的。这个特性使得像INCR,DECR,INCRBY,DECRBY,HINCRBY等命令天生就是原子操作。

注意：这里说的“单线程”指的是核心命令处理逻辑。实际上，Redis在6.0版本之后引入了多线程来处理网络I/O，但命令的解析和执行依然由主线程串行进行，因此原子性特性得以保留。

2.2 原子操作命令家族一览

Redis提供了一组用于对数值进行原子操作的命令，它们不仅是原子的，而且性能极高，因为只是内存操作。以下是核心成员：

这些命令有一个共同前提：操作的键对应的值必须是数字类型（Redis内部存储为字符串，但能被解释为整数或浮点数）。如果键不存在，命令会先将值初始化为0，然后再执行操作。如果值不能被解释为数字，命令将返回一个错误。

2.3 与事务（MULTI/EXEC）的对比

很多人会混淆原子命令和Redis事务。虽然事务（MULTI...EXEC）能将多个命令打包执行，但其原子性含义不同：

• 原子命令：单个命令的执行是原子的，不可分割。
• Redis事务：它保证的是序列化隔离——事务中的所有命令会被排队，在EXEC时作为一个整体、按顺序执行。在执行过程中，不会被其他客户端的命令插入。但它不提供回滚机制。如果事务中的某个命令出错，其他命令依然会继续执行。

因此，对于简单的计数器场景，直接使用INCR/DECR是最高效、最安全的选择。而对于需要连续执行多个不同命令且希望它们不被干扰的场景（例如，先GET再SET，但中间值不能被其他客户端修改），则需要结合WATCH命令来实现乐观锁，这就复杂多了。

3. 自增自减在实战中的典型应用场景

理解了原理，我们来看看这些原子操作命令能用在哪些具体业务中，它们是如何解决实际痛点的。

3.1 场景一：高并发库存扣减与计数器

这是最经典的应用，开篇的库存超卖问题就是最佳案例。将商品库存存放在Redis中，秒杀时直接使用DECR或DECRBY进行扣减。

# 初始化库存 SET stock:product_1001 1000 # 用户下单时，原子扣减1 DECR stock:product_1001

如果DECR命令返回的值大于等于0，说明扣减成功，库存充足；如果返回-1，则说明库存已售罄（假设我们从0开始扣减）。这种方案完美解决了并发下的超卖问题。

实操心得：

1. 初始化与回滚：库存初始化通常是在活动开始前，从数据库加载到Redis。活动结束后，需要将Redis中的最终库存同步回数据库。如果遇到订单取消等需要回滚库存的情况，不能简单地用INCR，因为可能造成超库存（比如恶意取消）。更安全的做法是使用一个独立的回滚库存键或记录回滚日志，在活动结束后统一处理。
2. 防负数处理：DECR不会阻止值变为负数。在业务上，我们通常需要在扣减前判断。可以使用Lua脚本（同样是原子执行）将判断和扣减合二为一：

   local current = redis.call('GET', KEYS[1]) if current and tonumber(current) > 0 then return redis.call('DECR', KEYS[1]) else return -1 -- 或一个特定的错误码 end

3.2 场景二：分布式环境下的全局ID生成与序列号

在分布式系统中，生成全局唯一的递增ID（如订单号、消息ID）是一个常见需求。利用Redis单机单线程的特性，INCR命令可以轻松实现一个高性能的序列生成器。

# 生成下一个订单ID， key可以按业务+日期划分 INCR order:id:20231027

为什么可行？因为INCR命令的原子性保证了即使在成千上万的并发请求下，每次调用返回的值也一定是唯一的、递增的。

进阶技巧：

• 分段设计：直接使用INCR生成的ID过于简单。通常我们会组合业务前缀、日期和自增序列，例如ORDER20231027000001。这可以通过在应用层拼接实现：业务码 + 日期 + (INCR序列).ToString().PadLeft(8, '0')。
• 性能与持久化权衡：纯内存操作性能极高，但需要警惕Redis重启导致序列丢失或重复的风险。一种方案是定期将当前序列值持久化到数据库；另一种更常见的方案是使用Redis的RDB或AOF持久化机制，虽然可能丢失最近几秒的数据，但对于订单ID这类业务，通常可以接受一个小的“空洞”（丢失的ID不再使用），或者通过初始值设置一个较大的偏移量来规避风险。

3.3 场景三：用户行为限流与频率控制

原子自增是实现滑动窗口限流算法的核心组件。例如，限制一个用户每分钟只能发送5条短信。

# 用户UID:1001， 使用当前分钟数作为key的一部分 local key = 'sms_limit:1001:' .. os.date('%Y%m%d%H%M') # 原子增加本次操作计数 local current = redis.call('INCR', key) # 如果是第一次访问，设置key的过期时间为60秒 if current == 1 then redis.call('EXPIRE', key, 60) end # 如果计数超过阈值，则拒绝请求 if current > 5 then return 0 -- 表示限流 else return 1 -- 表示允许 end

这段Lua脚本保证了“判断-计数-设置过期时间”整个操作的原子性，避免了在并发下可能出现的过期时间设置竞争条件。

3.4 场景四：实时统计与热度排行

统计文章的阅读量、视频的播放次数、用户的点赞数等，要求实时性高且并发更新频繁。

# 文章阅读量+1 INCR article:view:12345 # 用户获赞数+10（比如一次操作代表10个赞） INCRBY user:like:67890 10

这些数据可以先在Redis中高速累加，再通过定时任务（例如每5分钟）将增量数据同步到持久化数据库中，从而大大减轻数据库的写入压力。

踩坑记录： 在早期的一次活动中，我们直接将INCR的返回值作为实时热度值展示在大屏上。当QPS极高时，虽然Redis本身毫无压力，但频繁通过GET命令读取这个计数器（用于展示）的网络开销和序列化/反序列化成本变得不可忽视。后来我们改为在本地应用层使用一个短期缓存，每100毫秒或每累计100次更新才去Redis读取一次最新值，显著降低了Redis的读压力。

4. 超越基础命令：用Lua脚本实现复杂原子逻辑

虽然INCR/DECR能解决单一操作的原子性，但业务逻辑往往更复杂。例如，“只有当库存大于10时才扣减1，否则返回库存不足”。这涉及到“判断-执行”的组合，在Redis中，确保这种组合原子性的银弹就是Lua脚本。

4.1 Lua脚本的原子性保障

当Redis执行一个Lua脚本时，它会将整个脚本作为一个命令来执行。在此期间，Redis服务器不会处理其他任何命令，直到脚本执行完毕。这相当于给一段自定义逻辑加了一个“全局锁”。

用Lua脚本实现安全库存扣减：

-- KEYS[1] 库存key -- ARGV[1] 扣减数量 local current = tonumber(redis.call('GET', KEYS[1]) or 0) local decrement = tonumber(ARGV[1]) if current >= decrement then redis.call('DECRBY', KEYS[1], decrement) return current - decrement -- 返回扣减后的库存 else return -1 -- 库存不足 end

在客户端（如Java的Jedis或Lettuce）中，你可以加载并执行这个脚本，它比发送多个命令再用WATCH监控的方式更简洁、性能更好。

4.2 脚本编写的注意事项与性能

1. 保持脚本精简：Lua脚本执行期间会阻塞整个Redis实例。务必确保脚本逻辑简单，执行速度快，避免在脚本中执行耗时的循环或复杂的计算。
2. 避免硬编码：将key和参数作为KEYS和ARGV数组传入，提高脚本的复用性。
3. 脚本缓存：Redis会缓存执行过的脚本（通过SHA1摘要）。客户端可以先尝试用EVALSHA执行缓存的脚本，如果不存在，再使用EVAL命令，这样可以节省网络传输脚本内容的开销。

5. 高可用与集群环境下的考量

在单机Redis上，原子性由单线程模型天然保证。但在主从复制或Redis Cluster集群环境下，我们需要有新的认识。

5.1 主从复制与读写分离的陷阱

常见的架构是主库写，从库读以分担压力。但这里有一个数据一致性的时间窗口。当你在主库上执行了一个INCR操作后，这个命令需要异步地复制到从库。如果在复制完成之前，一个读请求被路由到了从库，那么读到的就是旧值。

解决方案：

• 强一致性要求：对于需要绝对强一致的场景（如扣减库存后立刻查询余额），这类读请求必须强制走主库。大多数Redis客户端都支持设置“读主库”的标签。
• 最终一致性容忍：对于阅读量、点赞数这类允许短暂不一致的场景，可以放心使用读写分离。通常主从延迟在毫秒级，业务上可以接受。

5.2 Redis Cluster与键哈希分区

在Redis Cluster中，数据根据键被分片到不同的节点上。INCR一个键的操作，只会发生在该键所在的特定节点上，其原子性在该节点内部依然由单线程保证。

需要注意的问题：

• 多键操作：如果你想原子性地对多个键进行操作（例如，同时扣减商品A和商品B的库存），如果这两个键通过哈希计算后被分配到了不同的集群节点，那么就无法用一个Lua脚本或事务来实现原子性，因为Redis Cluster要求Lua脚本中的所有key必须在同一个哈希槽（slot）内。
• 应对策略：可以通过使用哈希标签（Hash Tag）来“欺骗”集群的键分配算法。例如，使用{order}123:stock_A和{order}123:stock_B作为键名，Redis只会根据{}内的内容order来计算分片，从而确保这两个键落在同一个节点上，使得针对它们的多键原子操作成为可能。但这需要谨慎设计，避免导致数据倾斜。

6. 性能监控与最佳实践

将核心计数器放在Redis，意味着Redis成为了系统的关键依赖。它的稳定性直接关系到业务核心流程。

1. 监控命令延迟：使用redis-cli --latency-history或通过监控系统（如Prometheus+Grafana）采集redis_command_duration_seconds等指标。特别关注INCR/DECR等高频命令的P99、P999延迟。突增可能意味着Redis负载过高或网络问题。
2. 避免大Key：虽然一个计数器本身很小，但如果你错误地使用了一个Hash结构来存储成千上万个商品的库存，并频繁对其中某个字段进行HINCRBY，整个大Hash的序列化/反序列化、网络传输会成为瓶颈。建议将计数器分散到独立的key中。
3. 设置合理的过期时间：对于临时性的计数器（如限流key、当日累计值），一定要设置EXPIRE。我曾遇到过因为忘记设置过期时间，导致Redis内存被无数个历史活动的计数器Key慢慢撑满的线上事故。
4. 容量规划与预警：根据业务峰值估算计数器Key的增长速度和内存占用，对Redis内存使用设置预警线。例如，一个全局ID生成器，每天增长100万，那么order:id:20231027这个键的值大约会占用几MB内存（Redis存储数字很高效），这是可以接受的，但需要心里有数。

原子自增自减这个看似简单的功能，是Redis作为高性能数据结构的精髓体现之一。它背后是单线程模型的简洁哲学，解决的是高并发下最棘手的数据一致性问题。从库存扣减到分布式ID，从限流到统计，它的身影无处不在。下次当你面临一个需要确保计数准确无误的高并发场景时，不妨首先想一想：“这个问题，能不能用一个INCR命令来解决？” 在大多数情况下，答案会是肯定的。