Redis 不只是缓存：高并发场景下的多种核心应用实践

引言

在初级开发者的认知中，Redis = 缓存 。

但在真实的互联网系统中，Redis 的定位远不止如此：

它是高并发系统中的"基础设施组件"。

从消息队列、分布式锁，到并发控制、事务保障，Redis 几乎参与了每一个高并发系统的核心链路。

本文将围绕几个实战问题，系统性讲清楚 Redis 在缓存之外的典型应用场景，并深入其实现原理与适用边界。

一、Redis 除了缓存，还能用来做什么？

问题简答

Redis 除了缓存，还常用于：

1 消息队列

Pub/Sub 发布订阅
基于 List 结构实现的轻量级 MQ

2 分布式锁

SETNX + 过期时间
Redlock 分布式锁算法

3 计数器、限流、排行榜、Session 共享等（本文重点放在前两类）

二、Redis 实现消息队列的几种方式

1 Pub/Sub：发布订阅模型

原理说明

生产者向 channel 发布消息
消费者订阅 channel，即可实时收到消息
Redis 负责消息转发

Publisher → Redis Channel → Subscriber

优点

实现简单
实时性强（低延迟）
适合广播通知类场景

缺点（非常重要）

消息不持久化
消费者不在线就会丢消息
无法确认消费状态

适用场景

配置变更通知
即时广播
实时推送（非核心数据）

结论：

Pub/Sub 更像"通知系统"，不是真正意义上的可靠消息队列。

2 基于 List 的消息队列（BRPOP / BLPOP）

实现方式

生产者：LPUSH queue msg
消费者：BRPOP queue timeout

Redis 的 List 天然支持 FIFO / LIFO，非常适合做轻量级队列。

优点

支持阻塞消费（避免空轮询）
消息不会立刻丢失
实现成本低

问题与风险

消费者宕机，消息可能已被取走但未处理
不支持消息确认（ACK）
不支持重试机制

进阶改进方案

使用 "待处理队列 + 工作队列"
消费成功后再从 processing queue 删除
类似 MQ 的"至少一次"语义

三、Redis 支持并发操作吗？

问题简答

支持，而且并发安全的核心原因有两点：

单条命令的原子性
事务机制（MULTI / EXEC）

1 Redis 命令的原子性

为什么 Redis 单条命令是原子的？

Redis 采用 单线程模型
同一时刻只会执行一条命令
命令执行过程中不会被打断

SET / INCR / LPUSH / HSET
→ 天然原子

实际意义

INCR 可直接作为计数器
SETNX 可用于并发控制
不需要额外加锁

2 Redis 事务（MULTI / EXEC）

基本用法

复制代码

MULTI
INCR stock
DECR balance
EXEC

Redis 事务的特点（非常重要）

不支持回滚
不是强一致事务
保证命令顺序执行
批量原子提交（从执行角度）

Redis 事务 vs MySQL 事务

对比项	Redis	MySQL
隔离级别	无	支持
回滚	不支持	支持
原子性	命令级	事务级
使用场景	并发控制	数据一致性

结论：

Redis 事务更像是"命令打包执行机制"，而不是数据库事务。

四、Redis 分布式锁的实现原理

为什么需要分布式锁？

在分布式系统中：

多个服务实例
多台机器
本地锁（synchronized / ReentrantLock）失效

典型场景：

秒杀库存扣减
定时任务防止重复执行
分布式任务调度
防止接口并发重复提交

1 基于 SETNX 的分布式锁

标准实现方式

复制代码

SET lock_key unique_value NX EX 30

含义：

NX：不存在才设置
EX：设置过期时间（防止死锁）
unique_value：标识锁的持有者

解锁（必须校验持有者）

复制代码

if redis.call("get", key) == value then
    return redis.call("del", key)
end

解锁一定要用 Lua 脚本，保证原子性

2 Redlock 算法（多节点分布式锁）

背景

单 Redis 节点存在风险：

主从切换
网络分区
单点故障

Redlock 核心思想

多个独立 Redis 节点（一般 5 个）
在 大多数节点（N/2+1） 上获取锁
才认为加锁成功

优点

提高可用性
降低单点失效风险

争议点

对网络延迟敏感
对时间同步依赖
并非强一致锁

实际建议：

业务对一致性要求极高 → ZooKeeper / etcd
高性能场景 → Redis 分布式锁

总结

Redis 早已不是"缓存工具"这么简单，它在高并发系统中承担着：

并发控制器
分布式协调组件
轻量级消息中间件

但同时也要清楚它的边界：

Redis 是性能型组件，不是强一致型组件。