企业官网建设流程全解析

1. 先聊清楚：Redis 到底值不值得花大把时间学

这两年只要打开招聘网站，后端相关岗位的 JD 上几乎都会挂着 Redis。问起到手能干什么，很多新人第一反应是"缓存数据库"，再往深了问——缓存穿透怎么解决、主从切换丢不丢数据、集群选型为什么不用哨兵——就开始含糊了。这不是个例。我见过不少写了三五年业务代码的开发，Redis 停留在set/get层面，项目一遇到大流量就抓瞎。标题里的"redis学习目录"看起来像一张零散的知识点清单，实际上背后藏着一个问题：Redis 的知识体系到底该怎么搭，才能从"会用"走向"用好"。

这篇文章我按自己的学习路径和踩坑经历，把 Redis 从安装、数据结构、持久化、分布式锁，到主从哨兵集群、SpringBoot 集成、缓存治理、面试高频题梳理成一条可执行的主线。它不是官方文档的复述，而是实打实跑过、验证过、踩过坑之后整理出来的学习地图。适合三种人看：刚接触 Redis 想系统入门的，工作中经常用但没梳理过全貌的，以及准备面试想查漏补缺的。

先说一个反直觉的结论：学 Redis 最忌讳按文档顺序从头读到尾。官方文档把命令按字母排列，把数据结构一个个拆开讲，看起来工整，但你看完大概率还是不知道项目里该用哪个。正确的打开方式是"场景倒推"——先从业务问题出发，比如"用户会话为什么不能全放 MySQL""双十一库存为什么不能靠数据库扣减"，带着问题去学，那些命令和原理自然就串起来了。

2. 安装、启动、可视化客户端：这关卡住了太多初学者

2.1 别再纠结 Windows 版了，生产环境没人用这个

"redis 下载"和"redis windows 下载"的热度一直很高，这是初学者第一个容易陷进去的坑。Redis 官方并不提供 Windows 版本，GitHub 上的 Windows 移植版停留在老版本，主要用于本地开发调试，生产环境基本都是 Linux。我刚开始学的时候也犯过这个错，在 Windows 下装了 3.x 的移植版，后面学持久化、学主从复制，发现很多配置项对不上，浪费了不少时间。

正确的姿势是：本地开发用 Docker，服务器用 Linux。如果你机器上已经装了 Docker，一条命令就能跑起来：

docker run -d --name redis \ -p 6379:6379 \ -v /data/redis:/data \ redis:7.0

这里做了三件事：后台运行、映射端口、把容器内的数据目录挂载到宿主机。挂载数据目录很关键，不挂的话容器一删，你辛辛苦苦写的测试数据全没了。Redis 的持久化文件默认存在/data目录，RDB 快照和 AOF 日志都在里面，挂载出来方便排查问题。

2.2 启动命令和配置文件，先搞清楚谁优先

很多教程让你直接redis-server启动，这在学习阶段够用，但一到自定义配置就露馅了。Redis 启动时配置的来源有三个，优先级从高到低：命令行参数、配置文件、默认配置。

# 指定配置文件启动 redis-server /etc/redis/redis.conf # 命令行参数覆盖配置文件 redis-server /etc/redis/redis.conf --port 6380 --maxmemory 256mb

生产环境我强烈建议养成"配置文件 + 命令行参数"组合使用的习惯。把端口、密码、持久化策略、内存上限这些写进配置文件，用版本管理工具管起来，不要在命令行里临时堆参数——不然哪天上线的节点配置和别人不一样，排查到天亮都找不到原因。

2.3 可视化客户端怎么选

"redis desktop manager"和"another redis desktop manager"这两个词搜索量一直居高不下。我的建议是：学习阶段用一个顺手的，工作阶段慢慢脱离它。

• Redis Desktop Manager：老牌工具，界面干净，社区版够用，但新版闭源后部分功能收费。
• Another Redis Desktop Manager：开源免费，功能上很像 RDM 的增强版，支持多开、密钥树形展示、命令执行，我目前主力用它。
• Redis Commander：Web 界面，浏览器打开就能用，适合临时上服务器看一眼，功能相对基础。

用可视化客户端的时候有个小建议：把它当成"巡检工具"而不是"操作工具"。flushall、del这种危险操作尽量在命令行里想清楚了再执行，客户端界面上点错一下，可能一整片缓存就没了。

3. 五种核心数据类型别死记硬背，用业务场景把它们焊死在脑子里

3.1 String 和 Hash：存储结构的选择决定了后续的维护成本

String 是最基础的类型，key-value 形式，适合存序列化后的对象、计数器、验证码这类简单数据。Hash 是 field-value 的嵌套结构，适合存"一个对象的多个属性"。

举个例子，用户信息缓存：

# String 方式，序列化整个对象 SET user:1001 {"name":"张三","age":30,"level":3} # Hash 方式 HSET user:1001 name 张三 age 30 level 3

看起来差不多，但差别在更新场景。用户等级变了，String 方式要先把整个对象取出来、反序列化、改字段、再序列化写回；Hash 方式一条HINCRBY user:1001 level 1就搞定了。数据量小的时候无所谓，数据量大了，这种细节就是性能和代码简洁度的分水岭。

还有几个高频命令值得注意：SETEX设置带过期时间的 key，适合验证码；INCR原子自增，适合计数器；SETNX是后面分布式锁的基础，先记住它"不存在才设置"的语义。

3.2 List 和 Set：一个管顺序，一个管去重

List 底层是双向链表，特点是有序、支持两端操作。常见场景是消息队列的简化版——用户发帖后把动态 IDLPUSH进用户的 feed 列表，然后LRANGE分页拉取。但要注意：Redis List 做的队列是"轻量级"的，不支持消息确认、不支持延迟消息，生产环境的消息队列还是交给 RabbitMQ 或 Kafka。List 更适合的场景是"最近浏览记录""操作日志"这类丢几条无所谓的列表。

Set 是无序去重集合，场景非常明显：点赞用户集合、关注关系、抽奖去重。SINTER求交集可以算共同关注，SUNIONSTORE可以合并标签。还有一个容易被忽略的用法：SPOP随机弹出元素，做"随机推荐"的时候特别好用。

3.3 ZSet：Redis 里最值钱的数据结构

ZSet 在 Set 基础上加了 score（分数），每个元素按分数排序。它是我认为 Redis 里"投入产出比"最高的一个知识点。排行榜是它最经典的应用：

ZADD leaderboard 100 user1 ZADD leaderboard 95 user2 ZADD leaderboard 120 user3 # 获取前三名 ZREVRANGE leaderboard 0 2 WITHSCORES # 获取某人排名 ZRANK leaderboard user2

但 ZSet 能做的事远不止排行榜。延时队列可以用 score 存执行时间戳，轮询ZRANGEBYSCORE取出到期的任务；固定窗口限流可以用 score 存时间戳，ZCOUNT统计窗口内请求数；文章热度排序可以用 score 存"点赞数 + 评论数 * 权重"组合出来的热度值。每多接触一种业务，你就会发现 ZSet 又多一种用法。

学习这五种类型的时候，我建议大家不要按类型去背命令，而是按"场景 -> 数据结构 -> 命令"的路径去理解。遇到一个业务需求，先想想它本质上是"查最新""去重""排序""计数"还是"存对象"，再对应到具体的类型上去。

3.4 多余的数据类型：布隆过滤器、HyperLogLog、Geo

除了五种基础类型，Redis 模块和扩展里还有几个高频选手。布隆过滤器解决缓存穿透问题，用一个位数组判断"这个 key 一定不存在"，能挡住大量恶意请求打到数据库。HyperLogLog 用极小内存做去重计数，比如统计 UV（独立访客量），标准误差 0.81% 对大多数业务完全够用。Geo 类型存经纬度，附近的人、门店距离排序直接用它。

这些不是入门阶段必须掌握的，但你要知道它们"存在且解决什么问题"。面试聊到"怎么设计一个海量 UV 统计系统"的时候，能脱口而出 HyperLogLog，这比背十道面试题都好使。

4. 进阶必踩的四道坎：持久化、内存淘汰、分布式锁、过期策略

4.1 RDB 和 AOF：数据能存多久，取决于你怎么配置

Redis 是内存数据库，数据默认存在内存里，不配置持久化的话，重启就啥都没了。持久化有两种方式，初学者必须搞懂它们各自的定位：

• RDB（快照）：把内存数据定期落盘成一个二进制文件。优点是恢复快、文件紧凑，缺点是可能丢最后一次快照之后的数据。
• AOF（追加日志）：把每条写操作追加到日志文件里。数据更安全，但文件会越来越大，恢复速度比 RDB 慢。

生产环境通常是两个都开，RDB 做冷备和快速恢复，AOF 保证数据安全。配置上注意几个参数：

# 开启 AOF appendonly yes # 同步策略：always 每条都同步 / everysec 每秒同步 / no 交给系统 appendfsync everysec # AOF 重写触发条件 auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb

appendfsync everysec是默认也是推荐配置，兼顾安全和性能。always最安全但性能损耗大，no性能最好但可能丢好几秒数据。AOF 日志会越来越大，Redis 提供了BGREWRITEAOF进行重写，把日志压缩成恢复当前数据的最小命令集。

我踩过一个坑：把 AOF 关掉只开 RDB，然后配置了save ""（禁用所有 RDB 触发条件），等于两种持久化都没生效。后来线上服务重启，缓存穿越直接把数据库打挂了。从那以后我养成了个习惯：每次改完配置，用redis-cli config get save确认一下真正生效的配置项。

4.2 内存淘汰策略：内存满了以后会发生什么

Redis 默认不设内存上限，但生产环境必须在配置文件里设maxmemory，不然内存耗尽会触发系统 OOM Kill。设了之后，当写入导致内存达到上限，Redis 按maxmemory-policy决定怎么处理新写入：

# 不淘汰，直接返回错误 maxmemory-policy noeviction # 从设置了过期时间的 key 里，淘汰最近最少使用的 maxmemory-policy volatile-lru # 从所有 key 里，淘汰最近最少使用的（推荐） maxmemory-policy allkeys-lru # 从所有 key 里，随机淘汰 maxmemory-policy allkeys-random

这里有一个很重要的判断：你的缓存是"可完全重建"还是"不可丢失"。如果是商品详情、用户资料这种能从数据库重建的，用allkeys-lru没毛病；如果是分布式锁、验证码这类关键状态，被淘汰了会出大问题，要确保它们不在淘汰范围内，或者干脆换存储方案。

4.3 过期删除策略：过期 key 是怎么被清掉的

过期 key 的清理不是"时间一到立刻删除"，Redis 用的是惰性删除 + 定期删除的组合。惰性删除是访问这个 key 的时候检查是否过期，过期就删；定期删除是后台每 100ms 随机抽一批设置了过期时间的 key，把过期的删掉。

这个机制带来一个现象：过期 key 可能占着内存，到内存快满的时候才被淘汰掉，或者明明已过期但还没来得及删，EXISTS查它还会返回 1。做缓存治理的时候，别指望"设置了过期时间就万事大吉"，要结合刚才的内存淘汰策略一起看。

4.4 分布式锁：SETNX 和 Lua 脚本

分布式锁是 Redis 面试逃不开的题。最基础的版本是SET key value NX EX 10——NX保证 key 不存在才设置，EX设置过期时间防止客户端崩了锁不释放。然后再配一个 Lua 脚本，保证"判断是不是自己的锁 + 删除"两步操作是原子的：

if redis.call("get", KEYS[1]) == ARGV[1] then return redis.call("del", KEYS[1]) else return 0 end

为什么必须用 Lua？因为"GET 判断 + DEL 删除"两步之间如果线程切换，可能出现"锁过期了，别人拿到了锁，然后你把别人的锁删了"的经典事故。Lua 脚本把两步合并成一步，Redis 执行 Lua 脚本是原子的，中间不会被其他命令插入。

这套方案能解决大多数业务场景，但它不是银弹。锁过期时间设置多长？业务执行时间超过锁过期时间怎么办？这时候要上"看门狗"续期机制。跨多实例怎么办？要上 Redisson 或者 RedLock。学习顺序应该是：先理解单机版问题，再理解续期问题，最后理解 RedLock 的争议和适用边界——面试官要的就是这个层层深入的过程。

5. 从单机到集群：主从、哨兵、Cluster 三种架构的关键差异

5.1 主从复制：读写分离的基础，