高并发|缓存优化 使用Redis计数器实现高效并发请求处理，提升redis计数器在并发场景下的应用

高并发场景下的Redis计数器：如何用一把「原子锁」扛住百万级请求？

最近某电商平台在「2025年618大促」中创下新纪录，其订单系统峰值达到每秒87万次请求，技术负责人透露，核心流量控制系统正是基于Redis计数器集群实现，这再次证明，在分布式高并发场景下,合理使用Redis计数器仍是性价比极高的解决方案。

为什么常规计数器会「崩盘」？

上周我排查过一个线上事故：某抽奖活动上线后，数据库CPU直接飙到100%,查看代码发现用的是简单的SQL计数器：

UPDATE activity SET count = count + 1 WHERE id = 123

这种写法在并发量超过500QPS时就会出现严重问题,我通过APM工具捕捉到三个致命现象：

1. 更新丢失：多个请求同时读取到初始值100，都计算为101后写入
2. 行锁竞争：数据库出现大量锁等待超时
3. 缓存穿透：计数器失效导致所有请求打到数据库

Redis计数器的四层防御体系

1 基础版：INCR命令

最简单的解决方案：

INCR activity:123:count

这个原子操作能轻松支撑10万+QPS,但存在两个隐患：

• 机器重启导致数据丢失
• 没有上限控制可能溢出

2 进阶版：INCR+EXPIRE

我们增加持久化和过期时间：

INCR activity:123:count
EXPIRE activity:123:count 86400

建议配合以下配置：

# redis.conf
auto-aof-rewrite-percentage 100
aof-rewrite-min-size 64mb

3 生产版：Lua脚本原子操作

用Lua脚本实现「比较并设置」的原子操作：

local current = redis.call('GET', KEYS[1])
if tonumber(current) < tonumber(ARGV[1]) then
    return redis.call('INCR', KEYS[1])
end
return -1

调用示例：

EVAL "脚本内容" 1 activity:123:count 10000

4 集群版：分片计数

当单个计数器QPS超过15万时需要分片：

// 分片算法
int shardNo = hash(userId) % 64; 
String key = "counter:" + bizType + ":" + shardNo;

五个实战避坑指南

1. 热点Key处理
   某社交平台曾因明星离婚事件导致某个Redis节点CPU100%,解决方案：

   

   # 对热点key增加随机后缀
   SET user:{id}:count:{random} 0

2. 限流器设计
   滑动窗口计数器实现：

   local now = tonumber(ARGV[1])
   local window = redis.call('TIME')[1]
   redis.call('ZREMRANGEBYSCORE', KEYS[1], 0, now - 60)
   local count = redis.call('ZCARD', KEYS[1])
   if count < 10 then
       redis.call('ZADD', KEYS[1], now, now)
   end
   return count

3. 分布式ID生成
   用Redis实现Snowflake变体：

   INCR global:id_generator  # 返回10000
   实际ID = 数据中心ID << 60 | 机器ID << 54 | (时间戳 << 20) | (序列号 & 0xFFFFF)

4. 库存扣减方案
   防止超卖的Lua脚本：

   local stock = tonumber(redis.call('GET', KEYS[1]))
   if stock <= 0 then
       return 0
   end
   redis.call('DECR', KEYS[1])
   return 1

5. 监控指标采集
   推荐采集以下metrics：

   • redis_command_latency_incr
   • counter_overflow_errors
   • shard_skew_ratio

性能压测数据对比

我们在8核32G的Redis6.2集群上测试（单位：QPS）：

未来演进方向

根据2025年Redis7.4的新特性,建议关注：

1. Server-assisted客户端缓存：减少网络往返
2. Shard-level复制：提升分片可用性
3. AI自动分片：动态调整热点数据分布

没有万能的解决方案，去年某金融系统盲目套用Redis计数器，反而因为跨机房同步延迟导致资损，技术选型必须结合业务场景，下次我将分享「如何用ETCD实现强一致计数器」,敬请期待。