当你在招聘 JD 上看到“熟悉 Redis 优先”在公司里听同事讨论“缓存穿透、缓存击穿、缓存雪崩”或者在压测时发现数据库扛不住热点流量时Redis 总是第一个被想到的中间件。很多初学者对 Redis 的印象停留在“一个很快的缓存”但真正走进它之后会发现它背后藏着一整套设计哲学。这篇文章打算围绕“Redis 凭什么这么火”这个主题拆解它的三个核心秘密丰富的数据结构、极致的高性能设计、靠近生产可用的持久化与高可用体系。读完你会理解 Redis 适用场景背后的原理也能顺手掌握安装、常用命令、分布式锁和面试高频问题。1. Redis 为什么这么火从“缓存”到“基础设施”1.1 先从一句话说起Redis 到底是什么Redis 的全称是 Remote Dictionary Server直译过来就是“远程字典服务器”。它本质上是一个基于内存的键值型 NoSQL 数据库但它和传统的 Memcached、本地 Map 又不一样因为 Redis 不只支持简单的字符串还支持哈希、列表、集合、有序集合等多种数据结构。你可以把 Redis 想象成一个“住在内存里的万能仓库”这个仓库的读写速度非常快并且提供了各种方便的“货架结构”。开发者把高频访问的数据放进去下次再取的时候就不用每次都去硬盘里翻数据库了。用专业一点的方式说Redis 是一个开源的、基于内存的、支持持久化、支持多种数据结构的键值存储系统。它既可以当缓存也可以做消息队列还能实现分布式锁、排行榜、计数器、附近的人等功能。1.2 它解决了什么痛点在传统 Web 架构里关系型数据库比如 MySQL是系统的核心。但数据库的读写速度受限于磁盘 I/O连接数也有限。一旦出现热点数据高并发访问数据库很容易成为瓶颈。举个例子一个秒杀商品详情页同一时刻可能有几万人打开如果每个人都去 MySQL 查询商品信息数据库连接池会被瞬间打满页面响应会变得非常慢严重的还会拖垮整个系统。Redis 解决的就是这类问题。它把请求量最大的数据提前放进内存让大部分读请求直接命中 Redis只有缓存未命中时才回源到数据库。一次内存读可能只要几十微秒而一次磁盘读通常是几毫秒性能差距是非常直观的。另外在分布式系统里多个应用实例之间的状态共享也是一个难题。常见的场景比如分布式锁、会话共享、幂等控制本质上都需要一个所有实例都能快速访问的公共存储Redis 凭借低延迟和高吞吐成为很多团队的首选。1.3 为什么偏偏是 Redis市面上有很多缓存方案比如 Memcached、Ehcache、Hazelcast甚至本地 Map为什么 Redis 能脱颖而出一个很重要的原因是“通用性”。Memcached 只支持简单的字符串而 Redis 支持多种数据结构这意味着很多复杂业务逻辑可以直接借 Redis 实现不用额外引入中间件。另一个原因是“工程化成熟度”Redis 提供了 RDB 和 AOF 两种持久化方案还提供了主从复制、哨兵、集群等高可用能力这让它可以不只是一个“重启即丢”的缓存而是一个真正能抗生产环境的组件。再加上它的部署非常简单一条命令就能启动社区资料丰富面试和工作中都绕不开。所以 Redis 能火并不奇怪接下来我们就把它的三个核心秘密逐一拆开。2. 核心秘密一数据结构丰富不只是简单的缓存Redis 最容易被低估的一点就是它的数据结构。很多人以为 Redis 就是set和get但实际上Redis 的数据结构设计几乎决定了它可以在多少种场景里发挥作用。2.1 String不只是字符串String 是 Redis 最基础的数据结构但它的用处远不止存文本。它可以是字符串、数字甚至是序列化后的对象。常用命令# 设置键值 SET user:name zhangsan # 获取键值 GET user:name # 自增自减适合做计数器 INCR page:view:20250101 # 设置过期时间适合做限流 SET login:token abc123 EX 60 # 不存在时才设置适合做分布式锁 SET product:123:lock uuid-xxx NX EX 10场景举例缓存用户信息、页面浏览量、接口次数统计、登录 Token、分布式锁。String 虽然是“最基础”的数据结构但实际使用率最高。2.2 Hash更适合存储对象如果用一个 String 存一个用户对象通常是把对象序列化成 JSON 再塞进去。但这样做有一个问题当你只想修改对象里的某一个字段时必须把整个对象取出来反序列化修改再序列化回去。Hash 结构避免了这种开销。它类似 Java 里的MapString, String可以把对象的每个字段单独存储。# 存储用户对象 HSET user:1001 name zhangsan age 25 city beijing # 获取某个字段 HGET user:1001 name # 获取整个对象的所有字段 HGETALL user:1001 # 给某个字段加数字 HINCRBY user:1001 age 1Hash 很适合存用户资料、商品信息、配置项等结构化数据尤其在字段经常需要部分更新的场景下比 String 序列化方案更高效。2.3 List可以实现消息队列和时间线List 是双向链表结构支持从头部或尾部推入、弹出数据。它的使用场景包括简单消息队列、最新消息列表、粉丝时间线等。# 从右边推入消息 RPUSH news:list news-1 RPUSH news:list news-2 # 从左边弹出消息模拟队列消费 LPOP news:list # 获取列表范围 LRANGE news:list 0 -1需要注意的是Redis 的 List 可以作为简陋的消息队列使用但如果有严格的消费确认、消息回溯、死信机制等需求还是建议使用专业的消息队列中间件比如 RabbitMQ、Kafka 或 RocketMQ。Redis Stream 出现后消息队列能力得到增强但它更适合轻量场景。2.4 Set天生的去重利器Set 是去重集合支持交集、并集、差集运算也非常适合做标签、好友关系、抽奖等场景。# 添加用户标签 SADD user:1001:tags java redis mysql # 查看用户所有标签 SMEMBERS user:1001:tags # 计算两个用户的共同好友 SINTER user:1001:friends user:1002:friends # 抽奖从集合中随机弹出 SPOP lottery:2025场景举例共同好友、关注关系、UV 去重、随机抽奖、黑白名单。Set 的运算能力在社交类业务中非常有用。2.5 ZSet有“权重”的排行榜ZSet 是带分数的有序集合每个成员有一个 scoreRedis 会根据 score 自动排序。排行榜、延时队列、优先级队列都可以用它实现。# 添加成员和分数 ZADD leaderboard 100 player:1 ZADD leaderboard 90 player:2 # 查看排名前 10 ZREVRANGE leaderboard 0 9 WITHSCORES # 给某个玩家加分 ZINCRBY leaderboard 10 player:1 # 查询某个玩家的排名 ZRANK leaderboard player:1ZSet 是 Redis 里非常“值钱”的数据结构因为它轻松解决了关系型数据库里“按分数排序并实时更新”这种比较麻烦的问题。2.6 扩展数据结构不只是一张表除了五种基础结构Redis 还提供了 Bitmap位图、HyperLogLog基数统计、GEO地理位置、Stream流等扩展能力。Bitmap 可以用来做签到统计HyperLogLog 可以用来统计 UVGEO 可以计算附近的人Stream 可以用于轻量级消息队列。数据结构丰富意味着 Redis 不是简单的缓存而是一个“能帮你省掉很多中间件的多功能存储”。很多看似需要单独开发的功能用 Redis 的某个数据结构就能实现。3. 核心秘密二内存 单线程 I/O 多路复用性能快到极致Redis 为什么快这是面试里几乎必问的问题也是理解 Redis 设计思路的关键。3.1 内存存储和磁盘拉开数量级差距Redis 的数据主要存放在内存中而传统数据库是把数据存到磁盘。内存的访问速度通常在几十纳秒到几百纳秒级别而磁盘的顺序读写也有毫秒级延迟随机读写更慢。Redis 把数据放在内存里天然避开了磁盘 I/O 这个最大瓶颈。不过“数据放内存”并不完全准确。Redis 有两种持久化机制RDB 和 AOF会把数据以快照或日志形式写到磁盘但磁盘写入是异步或按策略执行的不会阻塞主读写流程这点我们后面会展开。3.2 单线程模型没有锁竞争没有线程切换开销Redis 的网络读写和键值对读写是由单线程处理的。听到“单线程”很多人第一反应是“那不是浪费多核 CPU 吗”但 Redis 的设计者认为Redis 的瓶颈通常不在 CPU而在网络 I/O 和内存读写单线程反而带来三个好处不需要处理并发锁问题代码更简单。没有线程上下文切换开销。所有命令按顺序执行天然原子不用担心数据竞争。需要注意的是Redis 并不是“从头到尾只有一个线程”。比如 RDB 持久化会 fork 子进程AOF 重写也会使用后台线程异步删除某些大 key 也会用后台线程处理。我们说的单线程主要指“处理命令的网络模型和主执行链路”。3.3 I/O 多路复用一个线程管大量连接高并发场景下一个服务端需要同时管理成千上万个客户端连接。如果每个连接都分配一个线程线程数会暴涨开销非常大。Redis 使用 I/O 多路复用技术核心是epollLinux 环境。简单来说一个线程可以同时监听很多 socket 连接哪个连接有数据来了就处理哪个没数据就继续等待。这样单个线程就能支撑海量连接。可以把 I/O 多路复用理解成“一个服务员同时服务很多桌客人”客人不说话时服务员不用一直站在旁边只有客人喊“点菜”时服务员才过去处理。3.4 高效的数据编码与对象设计Redis 在内存中并不是简单使用普通的字符串结构而是设计了一套对象系统。例如小整数用 int 编码短字符串用 embstr 编码Hash、ZSet 在元素数量少时会使用紧凑的 ziplist/listpack 编码减少内存占用和查询复杂度。等数据量变大后再自动转换成哈希表或跳表结构。这种“根据数据规模自动换用编码”的设计是 Redis 内存效率高的重要原因。跳表Skip List是 ZSet 的核心实现它让有序集合的插入、删除、查找都能维持在 O(log N) 的复杂度同时实现起来比平衡树简单。3.5 单线程也有注意事项虽然单线程带来很多好处但也意味着一条命令不能执行太久否则会阻塞后面所有命令。典型的坑是使用KEYS *去匹配大量 key或者在生产环境执行HGETALL获取超大的 Hash这些操作都会导致 Redis 阻塞。如果想遍历 key应该改用SCAN命令它虽然是分批遍历但不会一个瞬间卡住整个 Redis。4. 核心秘密三持久化 高可用它不是“重启即空”的缓存很多缓存工具重启后就什么都没了Redis 却不是这样。它提供了完善的持久化、主从复制、哨兵和集群方案让它在生产环境里可以作为稳定的数据组件使用。4.1 RDB内存快照式持久化RDBRedis Database Backup是 Redis 默认的持久化方式。它会定期把当前内存里的全量数据生成一个压缩的二进制快照文件默认文件是dump.rdb。触发 RDB 的方式有几种配置文件中配置save规则、手动执行SAVE或BGSAVE命令、Redis 关闭时自动保存。RDB 优点文件小加载快适合做备份和灾难恢复。RDB 缺点因为是定期快照如果 Redis 在两次快照之间宕机这期间写入的数据会丢失。RDB 配置示例# 900 秒内有 1 次写操作就触发一次快照 save 900 1 # 300 秒内有 10 次写操作就触发一次快照 save 300 10 # 60 秒内有 10000 次写操作就触发一次快照 save 60 10000 # 压缩快照文件 rdbcompression yes # 快照文件名 dbfilename dump.rdb # 快照文件目录 dir /var/lib/redis4.2 AOF追加日志式持久化AOFAppend Only File会把每一条写命令追加到日志文件中。当 Redis 需要恢复数据时重新执行一遍 AOF 文件里的命令即可。相比 RDBAOF 的数据安全性更高你可以配置同步策略# 开启 AOF appendonly yes # 每次写命令都同步到磁盘最安全但性能开销最大 appendfsync always # 每秒同步一次兼顾性能和安全生产环境较常用 appendfsync everysec # 交给操作系统决定何时同步最快但最不安全 appendfsync noAOF 的问题在于文件体积会越来越大所以 Redis 提供了 AOF 重写rewrite机制把历史命令压缩成最小命令集合。从 Redis 4.0 开始可以配置混合持久化即同时使用 RDB 快照和 AOF 日志兼顾加载速度和数据安全。AOF 重写配置示例# 当 AOF 文件体积比上一次重写后体积增长 100% 时触发重写 auto-aof-rewrite-percentage 100 # 当 AOF 文件达到 64mb 时开始触发重写 auto-aof-rewrite-min-size 64mb4.3 主从复制读多写少的标配Redis 支持主从复制。主节点负责写从节点负责同步主节点的数据可以处理读请求。这样既能提高读吞吐量也能为主节点宕机提供数据备份。配置从节点非常简单在从节点的配置文件中添加# 指定主节点的 IP 和端口 replicaof 192.168.1.10 6379主从复制的流程大致是从节点启动后向主节点发送同步请求主节点执行 BGSAVE 生成 RDB 快照发给从节点从节点加载快照之后主节点再把后续写命令同步给从节点。4.4 哨兵与集群走向高可用主从复制有一个问题主节点宕机后从节点不会自动升级为主节点需要人工介入。哨兵Sentinel就是用来监控主节点状态、自动完成故障转移的组件。哨兵模式下如果主节点挂了哨兵会从从节点里选举出一个新的主节点客户端自动感知新的主节点地址整个过程无需人工干预。如果数据量超过单机内存或者写入吞吐量非常高可以用 Redis Cluster。集群会把数据按照哈希槽Hash Slot分散到多个节点上每个节点负责一部分槽位从而实现水平扩展。集群模式下Redis 支持在线扩容缩容、自动故障转移但客户端也相对更复杂一些。如果你想在 Docker 环境快速体验主从复制下面这个命令可以启动一个从节点docker run -d --name redis-slave \ -p 6380:6379 \ -v /docker/redis-slave/redis.conf:/etc/redis/redis.conf \ redis:latest \ redis-server /etc/redis/redis.conf注意示例配置文件里需要开启replicaof配置并替换成正确的主节点地址。生产环境的主从配置建议结合实际情况设计不能直接照搬命令。5. 环境准备Redis 下载安装与可视化客户端前面聊了很多理论接下来我们把环境跑起来。掌握 Redis 安装是入门的第一步同时也是绕不开的实操基础。5.1 Windows 安装与注意事项首先要明确一个历史问题Redis 官方并不直接提供 Windows 安装包官方推荐在 Linux 或 macOS 上运行。Windows 上使用 Redis常见方式有三种使用微软开发的旧版 Windows 移植版维护较少不建议生产使用。使用 WSLWindows Subsystem for Linux安装 Linux 版 Redis。使用 Docker Desktop 运行 Redis 容器。如果只是想本地做测试最简单的方式是用 Docker。确保 Docker Desktop 启动后执行docker run -d --name redis-local \ -p 6379:6379 \ redis:latest这个命令会下载最新版 Redis 镜像并在 6379 端口启动一个容器。如果你本机已经有 wsl 环境也可以直接在 WSL 里安装。5.2 Linux 安装Ubuntu 和 CentOS 示例在 Ubuntu/Debian 系统上用 apt 安装非常方便sudo apt update sudo apt install redis-server -y # 启动 Redis sudo systemctl start redis-server # 设置开机自启 sudo systemctl enable redis-server # 查看运行状态 sudo systemctl status redis-server在 CentOS/RHEL 系统上如果 yum 源没有 redis可能需要先安装 EPEL 源或者通过源码编译安装sudo yum install -y gcc make # 下载源码包注意版本号需要去官网或镜像站确认 wget https://download.redis.io/releases/redis-7.0.11.tar.gz tar xzf redis-7.0.11.tar.gz cd redis-7.0.11 make # 安装到 /usr/local/bin make install源码编译是一种非常通用的方式建议学习时手动编译一次理解 Redis 的依赖和构建过程。5.3 启动与基础命令验证安装完成后启动服务并验证# 启动 redis-server redis-server /path/to/redis.conf # 连接 Redis redis-cli -h 127.0.0.1 -p 6379 # 在 redis-cli 中执行 127.0.0.1:6379 PING PONG 127.0.0.1:6379 SET hello world OK 127.0.0.1:6379 GET hello world看到PONG说明 Redis 服务已经正常运行。5.4 可视化客户端选择命令行工具redis-cli适合基本操作但查看复杂数据结构时不够直观。常见的 Redis 可视化客户端有几个Redis Desktop ManagerRDM比较经典但部分版本需要激活。Another Redis Desktop ManagerARDM开源免费功能较全社区热度高。Redis InsightRedis 官方推出的可视化工具功能丰富支持内存分析、慢查询日志等。连接可视化客户端时需要填写 Redis 所在机器的 IP、端口、密码如果配置了requirepass并确认 Redis 开启了允许远程连接生产环境要注意开放范围。5.5 基础配置建议启动 Redis 时建议指定配置文件。常用的配置项# 绑定地址默认只允许本机访问 # 生产环境不要设置为 0.0.0.0除非你清楚风险 bind 127.0.0.1 # 端口 port 6379 # 是否开启保护模式 protected-mode yes # 设置访问密码 requirepass yourpassword # 是否以守护进程方式运行 daemonize yes # 最大可用内存示例为 256MB maxmemory 256mb # 内存淘汰策略 maxmemory-policy allkeys-lru需要再次提醒requirepass和bind是生产环境安全的重要边界不要在不做任何安全防护的情况下把 Redis 暴露到公网否则极容易被扫描和攻击。6. 实战案例用 Redis 实现分布式锁了解了 Redis 的基本能力后我们做一个完整的实战案例分布式锁。这个问题在面试和项目中都非常常见也是 Redis 生态里最能体现工程价值的功能之一。6.1 场景分析假设你有一个下单接口同一个用户重复点击“提交订单”按钮如果不做任何控制可能会创建两条重复订单。单体时代我们可以用 Java 的synchronized或ReentrantLock做 JVM 内锁。但微服务架构下接口可能部署在多台机器上JVM 内锁只对单台机器有效防不住跨节点的并发问题。这时候需要一个所有服务实例都能访问的统一锁机制。Redis 凭借高可用和低延迟成为最常见的分布式锁存储。6.2 核心命令SET NX EXRedis 分布式锁的核心是下面这条命令SET lock:order:1001 uuid-value NX EX 10参数说明lock:order:1001锁的 key一般以业务维度命名。uuid-value锁的 value必须是唯一值用来标识“谁持有锁”。NX表示只有当 key 不存在时才设置成功这是“加锁”的关键。EX 10表示锁的过期时间是 10 秒避免持有锁的线程宕机导致死锁。如果SET返回OK说明加锁成功返回nil空说明锁已被别人持有加锁失败。6.3 Java 代码实现下面是一个基于 Spring Boot 和StringRedisTemplate的分布式锁示例// 文件路径src/main/java/com/example/demo/RedisLockService.java import org.springframework.data.redis.core.StringRedisTemplate; import org.springframework.data.redis.core.script.DefaultRedisScript; import org.springframework.stereotype.Service; import java.util.Collections; import java.util.UUID; import java.util.concurrent.TimeUnit; Service public class RedisLockService { private final StringRedisTemplate redisTemplate; public RedisLockService(StringRedisTemplate redisTemplate) { this.redisTemplate redisTemplate; } /** * 尝试加锁 * * param lockKey 锁的 key * param expireTime 锁自动过期时间 * param timeUnit 时间单位 * return 加锁成功返回唯一标识失败返回 null */ public String tryLock(String lockKey, long expireTime, TimeUnit timeUnit) { String token UUID.randomUUID().toString(); Boolean success redisTemplate.opsForValue() .setIfAbsent(lockKey, token, expireTime, timeUnit); if (Boolean.TRUE.equals(success)) { return token; } return null; } /** * 释放锁必须校验 value防止误删别人的锁 * * param lockKey 锁的 key * param token 加锁时返回的唯一标识 */ public void unlock(String lockKey, String token) { // Lua 脚本保证“判断与删除”是原子操作 String script if redis.call(get, KEYS[1]) ARGV[1] then return redis.call(del, KEYS[1]) else return 0 end; redisTemplate.execute( new DefaultRedisScript(script, Long.class), Collections.singletonList(lockKey), token ); } }注意释放锁时不能直接delete必须先判断 value 是否是自己加锁时的值。否则可能出现线程 A 的锁过期后线程 B 获取到同一把锁此时线程 A 执行完想释放锁直接把线程 B 的锁删掉了。逻辑上会出大问题。加锁和解锁的调用示例// 文件路径src/main/java/com/example/demo/OrderController.java import org.springframework.web.bind.annotation.GetMapping; import org.springframework.web.bind.annotation.RestController; import java.util.concurrent.TimeUnit; RestController public class OrderController { private final RedisLockService redisLockService; public OrderController(RedisLockService redisLockService) { this.redisLockService redisLockService; } GetMapping(/order) public String createOrder() { String lockKey lock:order:1001; String token redisLockService.tryLock(lockKey, 10, TimeUnit.SECONDS); if (token null) { return 请求过于频繁请稍后重试; } try { // 这里执行真实的下单逻辑 return 下单成功; } finally { // 无论成功失败都要释放锁 redisLockService.unlock(lockKey, token); } } }6.4 更专业的方案Redisson上面的手写锁已经能用但有一些细节需要自己处理比如锁的自动续期、可重入等。如果项目使用 Spring Boot可以引入 Redisson 框架它提供了更完善的分布式锁实现。dependency groupIdorg.redisson/groupId artifactIdredisson-spring-boot-starter/artifactId version3.23.5/version /dependency使用示例import org.redisson.api.RLock; import org.redisson.api.RedissonClient; import org.springframework.web.bind.annotation.GetMapping; import org.springframework.web.bind.annotation.RestController; import java.util.concurrent.TimeUnit; RestController public class RedissonLockController { private final RedissonClient redissonClient; public RedissonLockController(RedissonClient redissonClient) { this.redissonClient redissonClient; } GetMapping(/order/redisson) public String createOrderWithRedisson() throws InterruptedException { RLock lock redissonClient.getLock(lock:order:1001); // 尝试加锁最多等待 3 秒加锁后 10 秒自动释放 boolean isLocked lock.tryLock(3, 10, TimeUnit.SECONDS); if (!isLocked) { return 请求过于频繁请稍后重试; } try { // 真实下单逻辑 return 下单成功; } finally { lock.unlock(); } } }Redisson 的锁默认有一个“看门狗”机制如果业务没执行完锁快过期时会自动续期避免业务还在跑锁先没了。但这个机制是两面的如果业务执行时间特别长锁一直续期也会拖慢其他线程需要结合超时时间合理设置。需要说明的是以上 Redisson 版本号只是示例实际使用时应去 Maven 仓库查找当前稳定版本。Redis 主从架构下如果主节点宕机分布式锁可能出现短暂失效极端高一致性场景可以考虑 RedLock 方案但 RedLock 本身也有争议需要根据业务容忍度做取舍。7. Redis 高频面试题与常见坑很多开发者学习 Redis 是奔着面试去的所以我整理了几个高频问题同时也是实际项目中容易踩的坑。7.1 为什么 Redis 这么快这是经典面试题。回答时可以从四个角度展开数据在内存中读写速度快。单线程模型避免锁竞争和线程切换开销。I/O 多路复用单线程能够高效处理海量连接。高效的数据编码与对象设计比如跳表、压缩表等。另外可以补充一句Redis 的瓶颈不是 CPU而是内存大小和网络带宽因此单线程在 Redis 场景下是合理选择。7.2 缓存穿透、缓存击穿、缓存雪崩的区别与解决这三个概念很容易混淆也是面试高频。缓存穿透请求的数据在缓存和数据库中都不存在每次请求都会直接打到数据库。攻击者可以利用这一点大量发起无效请求导致数据库压力过大。解决思路缓存空值并设置较短过期时间或者使用布隆过滤器过滤不在数据库中的 key。缓存击穿某个热点 key 突然过期同一时刻大量请求打到数据库。解决思路热点 key 不设置过期时间或者使用互斥锁控制回源查询。缓存雪崩大量 key 在同一时间段集体过期数据库瞬间承担大量请求。解决思路过期时间加随机量错开过期时间或者使用高可用 Redis 集群和限流降级手段。7.3 为什么不能在生产环境执行 KEYS 命令KEYS *会遍历 Redis 中所有 key在单线程模型下一旦 key 数量很大比如上百万执行期间 Redis 会完全阻塞所有正常读写都会卡住这是生产事故级别的操作。正确做法是使用SCAN命令分批遍历# 从游标 0 开始扫描 SCAN 0 MATCH user:* COUNT 100SCAN会返回一个新的游标和一批 key用返回的游标继续扫描直到游标回到 0。虽然它不能保证一次拿到所有 key但不会阻塞 Redis 太久。如果只是拿一批测试数据SCAN足够用。7.4 Big Key 和 Hot Key 问题Big Key 指某个 key 的 value 特别大比如一个 List 有几百万条元素或者一个 Hash 字段特别多。Big Key 会导致删除、HGETALL、LRANGE等操作耗时很长阻塞其他命令。应对策略大对象拆分转换成多个小 key或者使用UNLINK命令异步删除避免阻塞主线程。Hot Key 指某个 key 被超高并发访问单个 Redis 节点压力过大。常见方案是给热 key 加随机后缀做本地缓存或者在 Redis 集群中让热 key 尽量分散到多个分片。7.5 缓存和数据库一致性怎么保证这是很有深度的问题。业界没有“万能办法”常见思路有先更新数据库再删除缓存Cache Aside Pattern。对删除失败的情况可以用消息队列重试删除。设置较短的过期时间作为兜底让缓存最终过期并回源到最新数据。尽量避免“先删缓存再更新数据库”这种顺序因为一旦更新数据库失败缓存已经是空的后续请求会大量打到数据库。实际操作中还要考虑并发场景下的读旧数据、写新数据相互覆盖问题需要结合业务容忍度设计方案。8. 最佳实践与工程建议到这里Redis 的核心价值已经讲得差不多。最后我们再聊一些工程上的实践经验和建议帮你在项目里用得更稳。8.1 key 命名规范Redis 的 key 没有目录结构但我们可以用分隔符模拟命名空间。推荐格式业务名:模块名:唯一标识例如order:detail:1001 user:login:token:888 product:stock:20250101清晰命名能极大降低后期维护成本。避免使用含义不明的 key比如a:1、temp123。8.2 设置键过期时间除了少数需要长期保存的数据绝大多数缓存 key 都应该设置过期时间。一个不设置过期时间的 key会一直占用内存最后可能导致内存耗尽触发淘汰策略甚至影响正常业务。使用SET时可以直接加EX或者使用EXPIRESET user:session:1001 token-value # 设置 30 分钟过期 EXPIRE user:session:1001 18008.3 控制单 key 大小单个 String value 建议控制在几十 KB 以内超级大的对象要拆分或重新设计结构。Redis 是单线程执行命令一个几 MB 的 value 在序列化、网络传输、内存分配上都会明显耗时。8.4 内存淘汰策略设置maxmemory后Redis 在内存达到上限时会根据maxmemory-policy淘汰数据。常见策略allkeys-lru在全部 key 中按 LRU 淘汰适合缓存场景。volatile-lru只在设置了过期时间的 key 中按 LRU 淘汰。allkeys-lfu按访问频率淘汰适合访问频率差异明显的场景。noeviction内存满后写命令直接报错适合不能丢数据的场景。生产环境选择淘汰策略需要结合业务不是所有场景都适合 LRU。8.5 安全性配置Redis 在默认配置下只允许本机访问不要轻易改成公网可访问。生产环境至少要做这几件事设置requirepass密码。修改默认端口或做好访问控制。使用专有网络和安全组限制来源 IP。开启protected-mode yes。避免把 Redis 暴露到不受信任的网络。Redis 中如果有敏感数据建议在应用层加密后再存储不要把数据库账号密码等直接放进 Redis。8.6 日志与监控Redis 的日志文件位置由配置文件中的logfile控制。排查问题时先看 Redis 日志能节省很多时间。慢查询日志也需要关注可以使用SLOWLOG GET查看执行时间较长的命令# 查看最近 10 条慢查询 SLOWLOG GET 10 # 查询慢查询阈值 CONFIG GET slowlog-log-slower-than生产环境建议接入监控系统关注内存使用率、连接数、命中率、慢查询数量、主从同步延迟等指标。Redis 本身也支持INFO命令快速查看当前运行状态INFO memory INFO clients INFO replication8.7 缓存数据一致性方案不要过度设计缓存和数据库一致性是分布式系统里的经典难题。如果业务允许短时间数据不一致简单设置过期时间就够了如果要求很高再考虑引入 Canal 监听数据库变更、消息队列异步删除缓存等方案。不要在一开始就把方案设计得很复杂容易被“过度设计”反噬。9. 总结Redis 值得学吗回到最初的问题Redis 凭什么这么火因为它的三个核心秘密恰好对应了后端开发的三个需求丰富的数据结构让它能解决多种业务场景高性能的内存设计让它成为抗住高并发的利器持久化和高可用体系让它从“缓存玩具”升级为生产级基础设施。你不需要把 Redis 的所有命令背下来但一定要理解它为什么这么设计以及在什么场景下该用它。如果你还没动手我建议你现在就去下载安装一个 Redis把SET、GET、HSET、ZADD、SET NX EX这些命令都敲一遍再结合 Spring Boot 写一个分布式锁案例。光看文章和真正跑一遍代码的差距很大只有实际部署过、排查过、卡过坑Redis 才真正变成你的技术栈。如果这篇文章对你有帮助可以收藏起来下次需要安装配置或者写分布式锁的时候直接对照着做。也欢迎在评论区留下你遇到过的 Redis 故障或面试题大家一起探讨。 Redis凭什么这么火？三大核心秘密深度解析
当你在招聘 JD 上看到“熟悉 Redis 优先”在公司里听同事讨论“缓存穿透、缓存击穿、缓存雪崩”或者在压测时发现数据库扛不住热点流量时Redis 总是第一个被想到的中间件。很多初学者对 Redis 的印象停留在“一个很快的缓存”但真正走进它之后会发现它背后藏着一整套设计哲学。这篇文章打算围绕“Redis 凭什么这么火”这个主题拆解它的三个核心秘密丰富的数据结构、极致的高性能设计、靠近生产可用的持久化与高可用体系。读完你会理解 Redis 适用场景背后的原理也能顺手掌握安装、常用命令、分布式锁和面试高频问题。1. Redis 为什么这么火从“缓存”到“基础设施”1.1 先从一句话说起Redis 到底是什么Redis 的全称是 Remote Dictionary Server直译过来就是“远程字典服务器”。它本质上是一个基于内存的键值型 NoSQL 数据库但它和传统的 Memcached、本地 Map 又不一样因为 Redis 不只支持简单的字符串还支持哈希、列表、集合、有序集合等多种数据结构。你可以把 Redis 想象成一个“住在内存里的万能仓库”这个仓库的读写速度非常快并且提供了各种方便的“货架结构”。开发者把高频访问的数据放进去下次再取的时候就不用每次都去硬盘里翻数据库了。用专业一点的方式说Redis 是一个开源的、基于内存的、支持持久化、支持多种数据结构的键值存储系统。它既可以当缓存也可以做消息队列还能实现分布式锁、排行榜、计数器、附近的人等功能。1.2 它解决了什么痛点在传统 Web 架构里关系型数据库比如 MySQL是系统的核心。但数据库的读写速度受限于磁盘 I/O连接数也有限。一旦出现热点数据高并发访问数据库很容易成为瓶颈。举个例子一个秒杀商品详情页同一时刻可能有几万人打开如果每个人都去 MySQL 查询商品信息数据库连接池会被瞬间打满页面响应会变得非常慢严重的还会拖垮整个系统。Redis 解决的就是这类问题。它把请求量最大的数据提前放进内存让大部分读请求直接命中 Redis只有缓存未命中时才回源到数据库。一次内存读可能只要几十微秒而一次磁盘读通常是几毫秒性能差距是非常直观的。另外在分布式系统里多个应用实例之间的状态共享也是一个难题。常见的场景比如分布式锁、会话共享、幂等控制本质上都需要一个所有实例都能快速访问的公共存储Redis 凭借低延迟和高吞吐成为很多团队的首选。1.3 为什么偏偏是 Redis市面上有很多缓存方案比如 Memcached、Ehcache、Hazelcast甚至本地 Map为什么 Redis 能脱颖而出一个很重要的原因是“通用性”。Memcached 只支持简单的字符串而 Redis 支持多种数据结构这意味着很多复杂业务逻辑可以直接借 Redis 实现不用额外引入中间件。另一个原因是“工程化成熟度”Redis 提供了 RDB 和 AOF 两种持久化方案还提供了主从复制、哨兵、集群等高可用能力这让它可以不只是一个“重启即丢”的缓存而是一个真正能抗生产环境的组件。再加上它的部署非常简单一条命令就能启动社区资料丰富面试和工作中都绕不开。所以 Redis 能火并不奇怪接下来我们就把它的三个核心秘密逐一拆开。2. 核心秘密一数据结构丰富不只是简单的缓存Redis 最容易被低估的一点就是它的数据结构。很多人以为 Redis 就是set和get但实际上Redis 的数据结构设计几乎决定了它可以在多少种场景里发挥作用。2.1 String不只是字符串String 是 Redis 最基础的数据结构但它的用处远不止存文本。它可以是字符串、数字甚至是序列化后的对象。常用命令# 设置键值 SET user:name zhangsan # 获取键值 GET user:name # 自增自减适合做计数器 INCR page:view:20250101 # 设置过期时间适合做限流 SET login:token abc123 EX 60 # 不存在时才设置适合做分布式锁 SET product:123:lock uuid-xxx NX EX 10场景举例缓存用户信息、页面浏览量、接口次数统计、登录 Token、分布式锁。String 虽然是“最基础”的数据结构但实际使用率最高。2.2 Hash更适合存储对象如果用一个 String 存一个用户对象通常是把对象序列化成 JSON 再塞进去。但这样做有一个问题当你只想修改对象里的某一个字段时必须把整个对象取出来反序列化修改再序列化回去。Hash 结构避免了这种开销。它类似 Java 里的MapString, String可以把对象的每个字段单独存储。# 存储用户对象 HSET user:1001 name zhangsan age 25 city beijing # 获取某个字段 HGET user:1001 name # 获取整个对象的所有字段 HGETALL user:1001 # 给某个字段加数字 HINCRBY user:1001 age 1Hash 很适合存用户资料、商品信息、配置项等结构化数据尤其在字段经常需要部分更新的场景下比 String 序列化方案更高效。2.3 List可以实现消息队列和时间线List 是双向链表结构支持从头部或尾部推入、弹出数据。它的使用场景包括简单消息队列、最新消息列表、粉丝时间线等。# 从右边推入消息 RPUSH news:list news-1 RPUSH news:list news-2 # 从左边弹出消息模拟队列消费 LPOP news:list # 获取列表范围 LRANGE news:list 0 -1需要注意的是Redis 的 List 可以作为简陋的消息队列使用但如果有严格的消费确认、消息回溯、死信机制等需求还是建议使用专业的消息队列中间件比如 RabbitMQ、Kafka 或 RocketMQ。Redis Stream 出现后消息队列能力得到增强但它更适合轻量场景。2.4 Set天生的去重利器Set 是去重集合支持交集、并集、差集运算也非常适合做标签、好友关系、抽奖等场景。# 添加用户标签 SADD user:1001:tags java redis mysql # 查看用户所有标签 SMEMBERS user:1001:tags # 计算两个用户的共同好友 SINTER user:1001:friends user:1002:friends # 抽奖从集合中随机弹出 SPOP lottery:2025场景举例共同好友、关注关系、UV 去重、随机抽奖、黑白名单。Set 的运算能力在社交类业务中非常有用。2.5 ZSet有“权重”的排行榜ZSet 是带分数的有序集合每个成员有一个 scoreRedis 会根据 score 自动排序。排行榜、延时队列、优先级队列都可以用它实现。# 添加成员和分数 ZADD leaderboard 100 player:1 ZADD leaderboard 90 player:2 # 查看排名前 10 ZREVRANGE leaderboard 0 9 WITHSCORES # 给某个玩家加分 ZINCRBY leaderboard 10 player:1 # 查询某个玩家的排名 ZRANK leaderboard player:1ZSet 是 Redis 里非常“值钱”的数据结构因为它轻松解决了关系型数据库里“按分数排序并实时更新”这种比较麻烦的问题。2.6 扩展数据结构不只是一张表除了五种基础结构Redis 还提供了 Bitmap位图、HyperLogLog基数统计、GEO地理位置、Stream流等扩展能力。Bitmap 可以用来做签到统计HyperLogLog 可以用来统计 UVGEO 可以计算附近的人Stream 可以用于轻量级消息队列。数据结构丰富意味着 Redis 不是简单的缓存而是一个“能帮你省掉很多中间件的多功能存储”。很多看似需要单独开发的功能用 Redis 的某个数据结构就能实现。3. 核心秘密二内存 单线程 I/O 多路复用性能快到极致Redis 为什么快这是面试里几乎必问的问题也是理解 Redis 设计思路的关键。3.1 内存存储和磁盘拉开数量级差距Redis 的数据主要存放在内存中而传统数据库是把数据存到磁盘。内存的访问速度通常在几十纳秒到几百纳秒级别而磁盘的顺序读写也有毫秒级延迟随机读写更慢。Redis 把数据放在内存里天然避开了磁盘 I/O 这个最大瓶颈。不过“数据放内存”并不完全准确。Redis 有两种持久化机制RDB 和 AOF会把数据以快照或日志形式写到磁盘但磁盘写入是异步或按策略执行的不会阻塞主读写流程这点我们后面会展开。3.2 单线程模型没有锁竞争没有线程切换开销Redis 的网络读写和键值对读写是由单线程处理的。听到“单线程”很多人第一反应是“那不是浪费多核 CPU 吗”但 Redis 的设计者认为Redis 的瓶颈通常不在 CPU而在网络 I/O 和内存读写单线程反而带来三个好处不需要处理并发锁问题代码更简单。没有线程上下文切换开销。所有命令按顺序执行天然原子不用担心数据竞争。需要注意的是Redis 并不是“从头到尾只有一个线程”。比如 RDB 持久化会 fork 子进程AOF 重写也会使用后台线程异步删除某些大 key 也会用后台线程处理。我们说的单线程主要指“处理命令的网络模型和主执行链路”。3.3 I/O 多路复用一个线程管大量连接高并发场景下一个服务端需要同时管理成千上万个客户端连接。如果每个连接都分配一个线程线程数会暴涨开销非常大。Redis 使用 I/O 多路复用技术核心是epollLinux 环境。简单来说一个线程可以同时监听很多 socket 连接哪个连接有数据来了就处理哪个没数据就继续等待。这样单个线程就能支撑海量连接。可以把 I/O 多路复用理解成“一个服务员同时服务很多桌客人”客人不说话时服务员不用一直站在旁边只有客人喊“点菜”时服务员才过去处理。3.4 高效的数据编码与对象设计Redis 在内存中并不是简单使用普通的字符串结构而是设计了一套对象系统。例如小整数用 int 编码短字符串用 embstr 编码Hash、ZSet 在元素数量少时会使用紧凑的 ziplist/listpack 编码减少内存占用和查询复杂度。等数据量变大后再自动转换成哈希表或跳表结构。这种“根据数据规模自动换用编码”的设计是 Redis 内存效率高的重要原因。跳表Skip List是 ZSet 的核心实现它让有序集合的插入、删除、查找都能维持在 O(log N) 的复杂度同时实现起来比平衡树简单。3.5 单线程也有注意事项虽然单线程带来很多好处但也意味着一条命令不能执行太久否则会阻塞后面所有命令。典型的坑是使用KEYS *去匹配大量 key或者在生产环境执行HGETALL获取超大的 Hash这些操作都会导致 Redis 阻塞。如果想遍历 key应该改用SCAN命令它虽然是分批遍历但不会一个瞬间卡住整个 Redis。4. 核心秘密三持久化 高可用它不是“重启即空”的缓存很多缓存工具重启后就什么都没了Redis 却不是这样。它提供了完善的持久化、主从复制、哨兵和集群方案让它在生产环境里可以作为稳定的数据组件使用。4.1 RDB内存快照式持久化RDBRedis Database Backup是 Redis 默认的持久化方式。它会定期把当前内存里的全量数据生成一个压缩的二进制快照文件默认文件是dump.rdb。触发 RDB 的方式有几种配置文件中配置save规则、手动执行SAVE或BGSAVE命令、Redis 关闭时自动保存。RDB 优点文件小加载快适合做备份和灾难恢复。RDB 缺点因为是定期快照如果 Redis 在两次快照之间宕机这期间写入的数据会丢失。RDB 配置示例# 900 秒内有 1 次写操作就触发一次快照 save 900 1 # 300 秒内有 10 次写操作就触发一次快照 save 300 10 # 60 秒内有 10000 次写操作就触发一次快照 save 60 10000 # 压缩快照文件 rdbcompression yes # 快照文件名 dbfilename dump.rdb # 快照文件目录 dir /var/lib/redis4.2 AOF追加日志式持久化AOFAppend Only File会把每一条写命令追加到日志文件中。当 Redis 需要恢复数据时重新执行一遍 AOF 文件里的命令即可。相比 RDBAOF 的数据安全性更高你可以配置同步策略# 开启 AOF appendonly yes # 每次写命令都同步到磁盘最安全但性能开销最大 appendfsync always # 每秒同步一次兼顾性能和安全生产环境较常用 appendfsync everysec # 交给操作系统决定何时同步最快但最不安全 appendfsync noAOF 的问题在于文件体积会越来越大所以 Redis 提供了 AOF 重写rewrite机制把历史命令压缩成最小命令集合。从 Redis 4.0 开始可以配置混合持久化即同时使用 RDB 快照和 AOF 日志兼顾加载速度和数据安全。AOF 重写配置示例# 当 AOF 文件体积比上一次重写后体积增长 100% 时触发重写 auto-aof-rewrite-percentage 100 # 当 AOF 文件达到 64mb 时开始触发重写 auto-aof-rewrite-min-size 64mb4.3 主从复制读多写少的标配Redis 支持主从复制。主节点负责写从节点负责同步主节点的数据可以处理读请求。这样既能提高读吞吐量也能为主节点宕机提供数据备份。配置从节点非常简单在从节点的配置文件中添加# 指定主节点的 IP 和端口 replicaof 192.168.1.10 6379主从复制的流程大致是从节点启动后向主节点发送同步请求主节点执行 BGSAVE 生成 RDB 快照发给从节点从节点加载快照之后主节点再把后续写命令同步给从节点。4.4 哨兵与集群走向高可用主从复制有一个问题主节点宕机后从节点不会自动升级为主节点需要人工介入。哨兵Sentinel就是用来监控主节点状态、自动完成故障转移的组件。哨兵模式下如果主节点挂了哨兵会从从节点里选举出一个新的主节点客户端自动感知新的主节点地址整个过程无需人工干预。如果数据量超过单机内存或者写入吞吐量非常高可以用 Redis Cluster。集群会把数据按照哈希槽Hash Slot分散到多个节点上每个节点负责一部分槽位从而实现水平扩展。集群模式下Redis 支持在线扩容缩容、自动故障转移但客户端也相对更复杂一些。如果你想在 Docker 环境快速体验主从复制下面这个命令可以启动一个从节点docker run -d --name redis-slave \ -p 6380:6379 \ -v /docker/redis-slave/redis.conf:/etc/redis/redis.conf \ redis:latest \ redis-server /etc/redis/redis.conf注意示例配置文件里需要开启replicaof配置并替换成正确的主节点地址。生产环境的主从配置建议结合实际情况设计不能直接照搬命令。5. 环境准备Redis 下载安装与可视化客户端前面聊了很多理论接下来我们把环境跑起来。掌握 Redis 安装是入门的第一步同时也是绕不开的实操基础。5.1 Windows 安装与注意事项首先要明确一个历史问题Redis 官方并不直接提供 Windows 安装包官方推荐在 Linux 或 macOS 上运行。Windows 上使用 Redis常见方式有三种使用微软开发的旧版 Windows 移植版维护较少不建议生产使用。使用 WSLWindows Subsystem for Linux安装 Linux 版 Redis。使用 Docker Desktop 运行 Redis 容器。如果只是想本地做测试最简单的方式是用 Docker。确保 Docker Desktop 启动后执行docker run -d --name redis-local \ -p 6379:6379 \ redis:latest这个命令会下载最新版 Redis 镜像并在 6379 端口启动一个容器。如果你本机已经有 wsl 环境也可以直接在 WSL 里安装。5.2 Linux 安装Ubuntu 和 CentOS 示例在 Ubuntu/Debian 系统上用 apt 安装非常方便sudo apt update sudo apt install redis-server -y # 启动 Redis sudo systemctl start redis-server # 设置开机自启 sudo systemctl enable redis-server # 查看运行状态 sudo systemctl status redis-server在 CentOS/RHEL 系统上如果 yum 源没有 redis可能需要先安装 EPEL 源或者通过源码编译安装sudo yum install -y gcc make # 下载源码包注意版本号需要去官网或镜像站确认 wget https://download.redis.io/releases/redis-7.0.11.tar.gz tar xzf redis-7.0.11.tar.gz cd redis-7.0.11 make # 安装到 /usr/local/bin make install源码编译是一种非常通用的方式建议学习时手动编译一次理解 Redis 的依赖和构建过程。5.3 启动与基础命令验证安装完成后启动服务并验证# 启动 redis-server redis-server /path/to/redis.conf # 连接 Redis redis-cli -h 127.0.0.1 -p 6379 # 在 redis-cli 中执行 127.0.0.1:6379 PING PONG 127.0.0.1:6379 SET hello world OK 127.0.0.1:6379 GET hello world看到PONG说明 Redis 服务已经正常运行。5.4 可视化客户端选择命令行工具redis-cli适合基本操作但查看复杂数据结构时不够直观。常见的 Redis 可视化客户端有几个Redis Desktop ManagerRDM比较经典但部分版本需要激活。Another Redis Desktop ManagerARDM开源免费功能较全社区热度高。Redis InsightRedis 官方推出的可视化工具功能丰富支持内存分析、慢查询日志等。连接可视化客户端时需要填写 Redis 所在机器的 IP、端口、密码如果配置了requirepass并确认 Redis 开启了允许远程连接生产环境要注意开放范围。5.5 基础配置建议启动 Redis 时建议指定配置文件。常用的配置项# 绑定地址默认只允许本机访问 # 生产环境不要设置为 0.0.0.0除非你清楚风险 bind 127.0.0.1 # 端口 port 6379 # 是否开启保护模式 protected-mode yes # 设置访问密码 requirepass yourpassword # 是否以守护进程方式运行 daemonize yes # 最大可用内存示例为 256MB maxmemory 256mb # 内存淘汰策略 maxmemory-policy allkeys-lru需要再次提醒requirepass和bind是生产环境安全的重要边界不要在不做任何安全防护的情况下把 Redis 暴露到公网否则极容易被扫描和攻击。6. 实战案例用 Redis 实现分布式锁了解了 Redis 的基本能力后我们做一个完整的实战案例分布式锁。这个问题在面试和项目中都非常常见也是 Redis 生态里最能体现工程价值的功能之一。6.1 场景分析假设你有一个下单接口同一个用户重复点击“提交订单”按钮如果不做任何控制可能会创建两条重复订单。单体时代我们可以用 Java 的synchronized或ReentrantLock做 JVM 内锁。但微服务架构下接口可能部署在多台机器上JVM 内锁只对单台机器有效防不住跨节点的并发问题。这时候需要一个所有服务实例都能访问的统一锁机制。Redis 凭借高可用和低延迟成为最常见的分布式锁存储。6.2 核心命令SET NX EXRedis 分布式锁的核心是下面这条命令SET lock:order:1001 uuid-value NX EX 10参数说明lock:order:1001锁的 key一般以业务维度命名。uuid-value锁的 value必须是唯一值用来标识“谁持有锁”。NX表示只有当 key 不存在时才设置成功这是“加锁”的关键。EX 10表示锁的过期时间是 10 秒避免持有锁的线程宕机导致死锁。如果SET返回OK说明加锁成功返回nil空说明锁已被别人持有加锁失败。6.3 Java 代码实现下面是一个基于 Spring Boot 和StringRedisTemplate的分布式锁示例// 文件路径src/main/java/com/example/demo/RedisLockService.java import org.springframework.data.redis.core.StringRedisTemplate; import org.springframework.data.redis.core.script.DefaultRedisScript; import org.springframework.stereotype.Service; import java.util.Collections; import java.util.UUID; import java.util.concurrent.TimeUnit; Service public class RedisLockService { private final StringRedisTemplate redisTemplate; public RedisLockService(StringRedisTemplate redisTemplate) { this.redisTemplate redisTemplate; } /** * 尝试加锁 * * param lockKey 锁的 key * param expireTime 锁自动过期时间 * param timeUnit 时间单位 * return 加锁成功返回唯一标识失败返回 null */ public String tryLock(String lockKey, long expireTime, TimeUnit timeUnit) { String token UUID.randomUUID().toString(); Boolean success redisTemplate.opsForValue() .setIfAbsent(lockKey, token, expireTime, timeUnit); if (Boolean.TRUE.equals(success)) { return token; } return null; } /** * 释放锁必须校验 value防止误删别人的锁 * * param lockKey 锁的 key * param token 加锁时返回的唯一标识 */ public void unlock(String lockKey, String token) { // Lua 脚本保证“判断与删除”是原子操作 String script if redis.call(get, KEYS[1]) ARGV[1] then return redis.call(del, KEYS[1]) else return 0 end; redisTemplate.execute( new DefaultRedisScript(script, Long.class), Collections.singletonList(lockKey), token ); } }注意释放锁时不能直接delete必须先判断 value 是否是自己加锁时的值。否则可能出现线程 A 的锁过期后线程 B 获取到同一把锁此时线程 A 执行完想释放锁直接把线程 B 的锁删掉了。逻辑上会出大问题。加锁和解锁的调用示例// 文件路径src/main/java/com/example/demo/OrderController.java import org.springframework.web.bind.annotation.GetMapping; import org.springframework.web.bind.annotation.RestController; import java.util.concurrent.TimeUnit; RestController public class OrderController { private final RedisLockService redisLockService; public OrderController(RedisLockService redisLockService) { this.redisLockService redisLockService; } GetMapping(/order) public String createOrder() { String lockKey lock:order:1001; String token redisLockService.tryLock(lockKey, 10, TimeUnit.SECONDS); if (token null) { return 请求过于频繁请稍后重试; } try { // 这里执行真实的下单逻辑 return 下单成功; } finally { // 无论成功失败都要释放锁 redisLockService.unlock(lockKey, token); } } }6.4 更专业的方案Redisson上面的手写锁已经能用但有一些细节需要自己处理比如锁的自动续期、可重入等。如果项目使用 Spring Boot可以引入 Redisson 框架它提供了更完善的分布式锁实现。dependency groupIdorg.redisson/groupId artifactIdredisson-spring-boot-starter/artifactId version3.23.5/version /dependency使用示例import org.redisson.api.RLock; import org.redisson.api.RedissonClient; import org.springframework.web.bind.annotation.GetMapping; import org.springframework.web.bind.annotation.RestController; import java.util.concurrent.TimeUnit; RestController public class RedissonLockController { private final RedissonClient redissonClient; public RedissonLockController(RedissonClient redissonClient) { this.redissonClient redissonClient; } GetMapping(/order/redisson) public String createOrderWithRedisson() throws InterruptedException { RLock lock redissonClient.getLock(lock:order:1001); // 尝试加锁最多等待 3 秒加锁后 10 秒自动释放 boolean isLocked lock.tryLock(3, 10, TimeUnit.SECONDS); if (!isLocked) { return 请求过于频繁请稍后重试; } try { // 真实下单逻辑 return 下单成功; } finally { lock.unlock(); } } }Redisson 的锁默认有一个“看门狗”机制如果业务没执行完锁快过期时会自动续期避免业务还在跑锁先没了。但这个机制是两面的如果业务执行时间特别长锁一直续期也会拖慢其他线程需要结合超时时间合理设置。需要说明的是以上 Redisson 版本号只是示例实际使用时应去 Maven 仓库查找当前稳定版本。Redis 主从架构下如果主节点宕机分布式锁可能出现短暂失效极端高一致性场景可以考虑 RedLock 方案但 RedLock 本身也有争议需要根据业务容忍度做取舍。7. Redis 高频面试题与常见坑很多开发者学习 Redis 是奔着面试去的所以我整理了几个高频问题同时也是实际项目中容易踩的坑。7.1 为什么 Redis 这么快这是经典面试题。回答时可以从四个角度展开数据在内存中读写速度快。单线程模型避免锁竞争和线程切换开销。I/O 多路复用单线程能够高效处理海量连接。高效的数据编码与对象设计比如跳表、压缩表等。另外可以补充一句Redis 的瓶颈不是 CPU而是内存大小和网络带宽因此单线程在 Redis 场景下是合理选择。7.2 缓存穿透、缓存击穿、缓存雪崩的区别与解决这三个概念很容易混淆也是面试高频。缓存穿透请求的数据在缓存和数据库中都不存在每次请求都会直接打到数据库。攻击者可以利用这一点大量发起无效请求导致数据库压力过大。解决思路缓存空值并设置较短过期时间或者使用布隆过滤器过滤不在数据库中的 key。缓存击穿某个热点 key 突然过期同一时刻大量请求打到数据库。解决思路热点 key 不设置过期时间或者使用互斥锁控制回源查询。缓存雪崩大量 key 在同一时间段集体过期数据库瞬间承担大量请求。解决思路过期时间加随机量错开过期时间或者使用高可用 Redis 集群和限流降级手段。7.3 为什么不能在生产环境执行 KEYS 命令KEYS *会遍历 Redis 中所有 key在单线程模型下一旦 key 数量很大比如上百万执行期间 Redis 会完全阻塞所有正常读写都会卡住这是生产事故级别的操作。正确做法是使用SCAN命令分批遍历# 从游标 0 开始扫描 SCAN 0 MATCH user:* COUNT 100SCAN会返回一个新的游标和一批 key用返回的游标继续扫描直到游标回到 0。虽然它不能保证一次拿到所有 key但不会阻塞 Redis 太久。如果只是拿一批测试数据SCAN足够用。7.4 Big Key 和 Hot Key 问题Big Key 指某个 key 的 value 特别大比如一个 List 有几百万条元素或者一个 Hash 字段特别多。Big Key 会导致删除、HGETALL、LRANGE等操作耗时很长阻塞其他命令。应对策略大对象拆分转换成多个小 key或者使用UNLINK命令异步删除避免阻塞主线程。Hot Key 指某个 key 被超高并发访问单个 Redis 节点压力过大。常见方案是给热 key 加随机后缀做本地缓存或者在 Redis 集群中让热 key 尽量分散到多个分片。7.5 缓存和数据库一致性怎么保证这是很有深度的问题。业界没有“万能办法”常见思路有先更新数据库再删除缓存Cache Aside Pattern。对删除失败的情况可以用消息队列重试删除。设置较短的过期时间作为兜底让缓存最终过期并回源到最新数据。尽量避免“先删缓存再更新数据库”这种顺序因为一旦更新数据库失败缓存已经是空的后续请求会大量打到数据库。实际操作中还要考虑并发场景下的读旧数据、写新数据相互覆盖问题需要结合业务容忍度设计方案。8. 最佳实践与工程建议到这里Redis 的核心价值已经讲得差不多。最后我们再聊一些工程上的实践经验和建议帮你在项目里用得更稳。8.1 key 命名规范Redis 的 key 没有目录结构但我们可以用分隔符模拟命名空间。推荐格式业务名:模块名:唯一标识例如order:detail:1001 user:login:token:888 product:stock:20250101清晰命名能极大降低后期维护成本。避免使用含义不明的 key比如a:1、temp123。8.2 设置键过期时间除了少数需要长期保存的数据绝大多数缓存 key 都应该设置过期时间。一个不设置过期时间的 key会一直占用内存最后可能导致内存耗尽触发淘汰策略甚至影响正常业务。使用SET时可以直接加EX或者使用EXPIRESET user:session:1001 token-value # 设置 30 分钟过期 EXPIRE user:session:1001 18008.3 控制单 key 大小单个 String value 建议控制在几十 KB 以内超级大的对象要拆分或重新设计结构。Redis 是单线程执行命令一个几 MB 的 value 在序列化、网络传输、内存分配上都会明显耗时。8.4 内存淘汰策略设置maxmemory后Redis 在内存达到上限时会根据maxmemory-policy淘汰数据。常见策略allkeys-lru在全部 key 中按 LRU 淘汰适合缓存场景。volatile-lru只在设置了过期时间的 key 中按 LRU 淘汰。allkeys-lfu按访问频率淘汰适合访问频率差异明显的场景。noeviction内存满后写命令直接报错适合不能丢数据的场景。生产环境选择淘汰策略需要结合业务不是所有场景都适合 LRU。8.5 安全性配置Redis 在默认配置下只允许本机访问不要轻易改成公网可访问。生产环境至少要做这几件事设置requirepass密码。修改默认端口或做好访问控制。使用专有网络和安全组限制来源 IP。开启protected-mode yes。避免把 Redis 暴露到不受信任的网络。Redis 中如果有敏感数据建议在应用层加密后再存储不要把数据库账号密码等直接放进 Redis。8.6 日志与监控Redis 的日志文件位置由配置文件中的logfile控制。排查问题时先看 Redis 日志能节省很多时间。慢查询日志也需要关注可以使用SLOWLOG GET查看执行时间较长的命令# 查看最近 10 条慢查询 SLOWLOG GET 10 # 查询慢查询阈值 CONFIG GET slowlog-log-slower-than生产环境建议接入监控系统关注内存使用率、连接数、命中率、慢查询数量、主从同步延迟等指标。Redis 本身也支持INFO命令快速查看当前运行状态INFO memory INFO clients INFO replication8.7 缓存数据一致性方案不要过度设计缓存和数据库一致性是分布式系统里的经典难题。如果业务允许短时间数据不一致简单设置过期时间就够了如果要求很高再考虑引入 Canal 监听数据库变更、消息队列异步删除缓存等方案。不要在一开始就把方案设计得很复杂容易被“过度设计”反噬。9. 总结Redis 值得学吗回到最初的问题Redis 凭什么这么火因为它的三个核心秘密恰好对应了后端开发的三个需求丰富的数据结构让它能解决多种业务场景高性能的内存设计让它成为抗住高并发的利器持久化和高可用体系让它从“缓存玩具”升级为生产级基础设施。你不需要把 Redis 的所有命令背下来但一定要理解它为什么这么设计以及在什么场景下该用它。如果你还没动手我建议你现在就去下载安装一个 Redis把SET、GET、HSET、ZADD、SET NX EX这些命令都敲一遍再结合 Spring Boot 写一个分布式锁案例。光看文章和真正跑一遍代码的差距很大只有实际部署过、排查过、卡过坑Redis 才真正变成你的技术栈。如果这篇文章对你有帮助可以收藏起来下次需要安装配置或者写分布式锁的时候直接对照着做。也欢迎在评论区留下你遇到过的 Redis 故障或面试题大家一起探讨。