企业官网建设流程全解析

1. 为什么你的项目越做越大，反而越需要Redis

做后端这些年，不少同事对Redis的态度其实分两种：一种人只把它当成一个“临时缓存”，存完就完事；另一种人用得很花，却也经常在半夜被线上告警吵醒。Redis这东西，说简单也简单，说深也深。如果你正从“能跑起来”往“扛得住高并发”这个阶段过渡，这份实战记录应该能帮你省掉不少翻车的时间。

先说清楚Redis在高并发场景下到底解决什么问题。关系型数据库的数据落在磁盘，每一次读写都要经过文件系统、缓冲区、锁机制，还要处理事务日志，天然不适合扛超高并发。举个例子，MySQL单机在普通配置下能撑住每秒几千次的简单查询就不错了，一旦到了秒杀、活动页、热点榜单这种动辄每秒几万次请求的场景，连接池先被打满，然后响应变慢，接着是雪崩式的超时。Redis不同，它的数据放在内存里，单线程模型配合IO多路复用，纯读场景能跑到十万级别QPS，写操作也能到几万级别，整体响应通常在毫秒以内。

你当然可以说“我用缓存中间件也能做”，但Redis真正厉害的地方在于它不是一个单一的KV缓存，而是一整套基础组件集合：字符串可以做分布式锁和计数器，有序集合可以做排行榜，列表和流可以做轻量队列，布隆过滤器可以挡缓存穿透。所以当你面对高并发系统时，Redis基本是绕不开的标配，问题只是你怎么把它用好。

这篇实战指南里讲的东西，全部来自我实际开发和排障过程中反复验证过的经验，不会只贴官方文档那种冷冰冰的说明。适合正在用Redis做业务开发的人，也适合想系统了解高并发缓存设计的小白。学完你能得到什么：一套能直接照抄的缓存规范、一套在故障现场的排查思路，以及一份不再被面试官问倒的Redis知识地图。

1.1 Redis与关系型数据库的定位差异

我习惯把存储体系比作超市：数据库是仓库，Redis是收银台旁的货架。仓库里放的是全部商品，容量大但取货慢；货架上放的是最热卖的商品，容量有限但拿起来快。一个合理的系统，不可能把仓库里的所有东西都搬到货架上，也不可能因为有了货架就把仓库拆了。

所以Redis最标准的定位是“数据库前面的热数据层”。它缓存的是高频读取、低频繁变化的数据，比如用户登录信息、商品详情、配置项、验证码、活动状态。真正需要持久化保存、有强事务要求的数据，最终还是应该落在关系型或文档型数据库里。不要指望Redis去替代数据库，也别把数据库的活全甩给Redis，两者的职责边界划清楚，后面很多架构问题都不会发生。

1.2 高并发下Redis真正解决了什么问题

除了扛住读流量，Redis在高并发系统里的价值主要集中在这几个方向：

• 读多写少场景的流量卸载。热点数据从数据库搬到Redis后，后端数据库的查询量大幅下降，原来需要几十台应用实例分摊的流量，可能几台就够了。
• 分布式环境下的共享状态。多个服务实例各自独立，但分布式锁、计数器、排行榜这类状态必须全局一致，Redis天然就是干这个的。
• 削峰填谷。瞬时流量来临时，通过Redis做限流计数，把超出的请求快速拒绝或排队，保护后端系统不被打垮。

简单说，Redis在系统里的作用是“让你用最少机器扛住最多流量”，而不是“帮你把业务复杂度抹平”。如果你只把它当缓存用，大约只发挥了三成功力；把分布式锁、限流、计数这些能力用起来，才谈得上高并发优化。

1.3 这篇实战指南适合谁读

如果你是刚接触Redis的开发者，建议从第2章的数据结构开始看，把命令亲手打一遍再往下走；如果你已经在项目里用过Redis，但被缓存穿透、击穿、雪崩这些词困扰过，直接跳到第4章，那是全篇最核心的部分；如果你已经在维护线上集群，第6章和第7章可以当作排障手册，遇到问题时翻开对照处理。

2. 基础实操：五种核心数据结构一次讲透

Redis之所以叫“数据结构服务器”，是因为它真正的价值不在“Key-Value”这几个字，而在于value的形态丰富。选对数据结构，能让你的代码量减少一半，性能提升数倍。这一章我用生产场景来拆解五种结构，每个都配上命令示例和选型理由。

2.1 String：计数、缓存、验证码的全能选手

String是Redis里最基础的结构，value可以是字符串、整数或者二进制数据，最大512MB。基础命令就这几个：SET、GET、SETNX、SETEX、INCR、DECR。平时用String踩坑最多的是不了解它的原子自增能力，结果自己用“读出来改回去”的方式实现了计数器，并发一高全是脏数据。

> SET login:count:20250301 0 OK > INCR login:count:20250301 (integer) 1 > GET login:count:20250301 "1"

INCR、DECR是原子操作，非常适合做登录次数统计、库存扣减、接口限流的基础计数。一个典型场景是验证码：发送短信前用SETEX存验证码，并设置60秒有效期，校验时用GET读取，发送前再用SETNX判断是否已有未过期的验证码，防止用户反复触发短信接口刷成本。

String存对象也很常用，一般会把对象序列化成JSON后SET进去。这里要提醒一句：大对象反复整体序列化、反序列化，CPU开销不小。如果业务只是频繁更新对象里的某一个字段，就别用String，换成Hash更划算。

2.2 Hash：对象存储场景比String更节省内存

Hash结构相当于一个小型Map，可以单独读写key底下的某个字段。命令主要有HSET、HGET、HGETALL、HDEL、HINCRBY。比如存用户信息：

> HSET user:1001 name "小A" age 25 city "北京" (integer) 3 > HGET user:1001 name "小A" > HINCRBY user:1001 age 1 (integer) 26

Hash最怕的就是用错命令把整个对象拉出来再改，那就失去了它“字段级操作”的意义。我见过P99延迟从5ms涨到50ms的案例，起因就是有人用HGETALL取了整个大Hash再在应用层修改。正确做法是只HGET需要的字段，只HSET改动的字段。

还有一个小细节：当Hash内部元素数量较少、字段值较短时，Redis会使用紧凑编码（listpack）存储，内存占用远小于正常哈希表。所以不要一开始就担心Hash费内存，大多数场景它比String更省。

2.3 List：消息队列与最新列表的旧派选择

List是链表结构，操作两端很快。常用命令：LPUSH、RPUSH、LPOP、RPOP、BRPOP、LRANGE。经典场景是“最新消息列表”：上线一个内容，LPUSH到列表头部，再用LRANGE 0 9取最新十条，性能远好过SQL里的ORDER BY LIMIT。

真正需要注意的，是很多人拿List当消息队列用。LPUSH + BRPOP确实能实现一个阻塞队列，我当时也这么干过，但用久了问题就出来了：消费者取走了消息却没来得及处理，进程崩溃的话消息直接丢失，没有ack机制，也不能重复消费。所以List适合做简单的任务分发，如果你需要可靠投递、消费组、消息追溯，Redis 5.0的Stream更合适。选型时别用List硬撑，后面会遭罪。

2.4 Set与ZSet：去重、交集与排行榜的正确姿势

Set是无序无重复集合，适合做去重、共同好友、随机抽奖。常用命令：SADD、SREM、SISMEMBER、SCARD、SINTER、SRANDMEMBER、SPOP。

> SADD follow:1001 2001 2002 2003 (integer) 3 > SADD follow:1002 2002 2003 2004 (integer) 3 > SINTER follow:1001 follow:1002 1) "2002" 2) "2003"

一行SINTER就拿到了两个用户的共同关注，这在粉丝关系链类系统里是高频操作。抽奖场景用SPOP随机弹出成员，天然不重复。

ZSet在Set基础上给每个元素加了分数，按分数排序。命令：ZADD、ZSCORE、ZINCRBY、ZRANGE、ZREVRANGE、ZRANGEBYSCORE。排行榜就是它的典型主场：

> ZADD leaderboard:game1 8000 "playerA" > ZADD leaderboard:game1 15000 "playerB" > ZINCRBY leaderboard:game1 1000 "playerA" > ZREVRANGE leaderboard:game1 0 9 WITHSCORES

ZSet还能做延时队列：把任务ID作为member，执行时间戳作为score，定时用ZRANGEBYSCORE取score小于当前时间的任务来处理。这个技巧实现简单，又不需要额外引入消息中间件，适合中小规模场景。

2.5 数据结构选型对照与选错后的修复思路

我经常用一个口诀帮人记忆：字符串存单值，Hash存对象，List存队列，Set存去重，ZSet存排行。下面是详细的选型对照表：

如果上线后才发现选型不对，千万别直接大范围修改代码。稳妥的做法是：先双写一段时间，新老逻辑并存，确认新方案的数据一致和性能没问题后，再切换读路径。这个“灰度迁移”的思路，在任何中间件选型调整里都适用。

3. 数据安全：持久化、过期策略与内存淘汰

很多人以为Redis只是缓存，丢了就丢了，重启恢复不恢复无所谓。这个认知在缓存场景勉强说得过去，但如果你用Redis存了分布式锁、未支付订单状态、限流计数，重启丢数据就会直接引发线上事故。所以持久化配置不是可有可无，而是要看场景认真设计。

3.1 RDB快照与AOF日志的取舍

Redis持久化有两条路：RDB和AOF。

RDB是内存数据的二进制快照，通过fork子进程生成，文件紧凑、加载快，适合做备份和灾难恢复。但它有个天然缺陷：两次快照之间的数据会丢。比如每5分钟生成一次快照，第4分59秒写入的数据在宕机后就会丢。

AOF则记录每次写操作的命令，像操作日志一样追加到文件，恢复时重放命令。它丢失数据的窗口小很多，但由于记录的是命令文本，文件体积比RDB大，恢复速度也慢。实际使用时，我通常建议两者都开：RDB作为快速恢复的底子，AOF作为精确到秒的补充。

3.2 appendfsync刷盘策略怎么选

AOF的可靠性核心在那个刷盘策略上。配置项是appendfsync，三个可选值：

• always：每次写命令都强制刷盘，最安全，性能牺牲最大，一般不会这么用。
• everysec：每秒刷一次盘，最多丢一秒数据，性能和可靠性比较均衡，生产上大多数时候选这个。
• no：交给操作系统决定什么时候刷盘，性能最好但丢数据风险不可控。

我在生产实践中直接写成everysec。如果你做的是账户余额、交易订单这类强一致业务，我劝你谨慎评估Redis是否适合作为唯一存储；如果只是缓存与状态标记，everysec完全够用。

还有一个配置容易被忽略：AOF文件会越来越大，需要定期执行重写。Redis提供了auto-aof-rewrite-percentage和auto-aof-rewrite-min-size来触发自动重写，默认配置基本够用，但如果你的写操作很频繁，要把重写阈值调小，防止AOF文件膨胀到几个G后拖垮启动恢复。

3.3 过期删除机制与内存淘汰策略

所有设了TTL的key，Redis并不是到点就立即物理删除，而是用了惰性删除加定期删除的混合机制。惰性删除是访问到某个key时才发现它过期了，顺手删掉；定期删除是后台周期性地抽样检查一部分过期key并清理。这个设计的理由是，为了精确到点的删除而扫描全量key，代价太大，没必要。

如果你只设了过期时间，却没有配置内存淘汰策略，Redis默认是noeviction——内存满了之后所有写请求直接报错。生产环境里绝对不能用默认值，否则高峰期一个缓存写操作失败，连锁反应能把业务打崩。

常用的淘汰策略就几个：allkeys-lru（所有key按LRU淘汰）、volatile-lru（只淘汰设置了过期时间的key）、allkeys-lfu（按访问频率淘汰）、volatile-random。对纯缓存场景，我一般用allkeys-lfu或allkeys-lru；对“某些key必须常驻但可以淘汰冷门缓存”的混合场景，用volatile-lru更适合。

3.4 持久化与淘汰策略的实战组合建议

我通常按业务类型分两套配置。

第一类：纯缓存数据。可以关闭持久化或仅开启RDB，目的是故障后快速加载热数据，丢失了能重新从数据库加载。淘汰策略直接allkeys-lfu，保证最热的key留在内存里。

第二类：带业务状态的短时数据，比如验证码、分布式锁、限流计数、交易幂等标记。开启AOF（everysec）+ RDB混合持久化，淘汰策略用noeviction或者volatile-lru但要给key设置足够合理的过期时间，防止意外丢写失败。

具体配置示例：

appendonly yes appendfsync everysec save 900 1 save 300 10 maxmemory 8gb maxmemory-policy allkeys-lfu

这套组合我实际用了很久，既能扛突发流量，又不会在重启后出现大面积缓存冷启动导致数据库被打爆。

4. 高并发三大坑：缓存穿透、缓存击穿、缓存雪崩

这三个词面试里总出现，但很多人背了概念，到线上真出事时依然手忙脚乱。我的经验是，每一个坑都有明确的形成路径和对应解法，你只要按图索骥就行。

4.1 缓存穿透：压根不存在的数据怎么挡

穿透的本质是：请求查询的数据在缓存和数据库里都不存在，导致每次请求都打到数据库。比如有人恶意遍历不存在的商品ID，或者前端传了一个被删除的历史ID，Redis里查不到，数据库里也没有，查询就一路穿过所有缓存防护。

最直接的解法是空值缓存：查不到数据时也在Redis里存一个空对象，并设置较短的过期时间，比如30到60秒。这样大量重复请求不会重复穿透到数据库。

更专业一点的解法是布隆过滤器。它用多个哈希函数把已存在的key映射到一个很长的bit数组里，查询时如果某个key映射的bit位中有任何一个为0，那这个key一定不存在；如果都为1，可能存在也可能误判。布隆过滤器适合“数据集合相对固定”的场景，比如判断用户ID是否存在、URL是否合法。

// 伪代码示意 if (!bloomFilter.mightContain(requestId)) { return "无效请求"; } Object cacheValue = redis.get(key); if (cacheValue == null) { Object dbValue = db.query(key); if (dbValue == null) { redis.set(key, "", 60); } else { redis.set(key, dbValue, 300); } }

布隆过滤器的缺点是难以删除元素，所以数据删除频繁的业务要对它做定期重建，或者使用带删除能力的计数布隆过滤器。

4.2 缓存击穿：热点key一瞬间被压垮

击穿和穿透很容易混。击穿指的是某个key非常热，比如秒杀商品的详情页、微博热搜榜，所有请求在极短时间内集中打到这个key上。如果这时候这个key刚好过期，Redis里查不到，请求就会同时打到数据库，数据库瞬间被大流量冲击。

两个主流解法：互斥锁和逻辑过期。

互斥锁的思路是，请求发现缓存过期后，不是每个人都去数据库查询，而是先尝试获取分布式锁，只有拿到锁的线程才能去查数据库并回填缓存，其他线程短暂等待后再次读取缓存。

逻辑过期更巧妙：value里不只存业务数据，还要拼一个过期时间字段。读请求发现逻辑时间已过期，立刻返回旧数据，同时异步开一个线程去更新缓存。这种方式不会阻塞请求，用户体验更好，但代价是数据会有一段时间不一致，适合能接受短暂脏读的业务。

实际工作中这两个方案不冲突：强一致、必须防穿透的场景优先用互斥锁；高并发、容忍短时旧数据的场景用逻辑过期更顺手。

4.3 缓存雪崩：大面积key同时失效的连锁反应

雪崩有两种触发方式：一是大量key的过期时间集中在同一时刻，缓存大面积失效，流量全部压到数据库；二是Redis实例宕机，所有缓存瞬间不可用，数据库被直接打穿。

对付第一种，办法是让过期时间随机化。不要都用3600秒，而是3600加一个300到600的随机数，让key的过期时间错开。这个改动成本极低，效果却非常明显。我接手的某电商项目之前每次整点活动开始时，MySQL连接数都会突然飙升到接近上限，查下来发现是因为所有活动banner的缓存都设了3600秒的整数倍时间，一到整点就整批过期。后来把所有缓存TTL都加了一个随机偏移，这个现象再没出现过。

对付第二种，就得靠多级缓存和高可用架构。在Redis前面加一层本地缓存，比如Caffeine或Guava Cache，即使Redis挂了，本地缓存还能挡一阵。同时Redis自身要部署主从加哨兵，避免单点故障。真实场景里还要配合熔断降级：当后端检测到缓存异常率过高，直接返回兜底数据或快速失败，而不是让雪崩继续放大。

4.4 预防三连坑的一揽子方案

我在项目里落地了一套组合方案，基本能把这三种问题一次性挡住：

• 接口层做参数校验，非法ID直接拒绝，挡掉一部分穿透。
• 访问热点数据前先查布隆过滤器，不存在就直接返回，持久挡住穿透。
• 所有缓存设置过期时间时加入随机因子，打散批量过期，防雪崩。
• 对单点热点key，用逻辑过期或互斥锁做防护，防击穿。
• Redis部署主从和哨兵，建立本地缓存兜底，防实例宕机引发的雪崩。

这套方案不需要每一条都上，但至少要做到：防穿透靠空值缩短TTL，防雪崩靠随机过期，防击穿靠热点保护。顺序是：先低成本做到位，再逐步加高成本方案。

5. 分布式锁与限流：高并发下的两个关键组件

当系统从单机部署变成多实例部署，原来用synchronized就能解决的并发问题就失效了，因为不同进程之间没法共享锁状态。这时候Redis分布式锁成了简单又高效的替代方案。但网上讲分布式锁的文章很多，版本也杂，我直接说生产环境里经过验证的正确写法。

5.1 分布式锁的正确写法与常见翻车现场

最早流行的写法是用SETNX加锁，再单独EXPIRE设置过期时间。这个写法有严重问题：SETNX和EXPIRE不是原子操作，如果SETNX成功之后，进程正好GC停顿或重启，锁就永远没有过期时间，其他线程全部死等。所以正确姿势是一条命令同时完成加锁和设置过期时间：

> SET lock:order:1001 unique_value NX PX 30000 OK

这个unique_value必须是每个线程唯一的标识，比如UUID或线程ID加随机数，不能只是简单的"1"。为什么？因为释放锁时要校验是不是自己的锁。假设线程A的锁因为执行时间过长自动过期了，线程B拿到了锁，这时A终于执行完并调用DEL释放锁，就会把B的锁误删掉。要避免这个翻车现场，释放锁必须用Lua脚本做“先比较、再删除”的原子操作：

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

还有一个生产上必须考虑的细节：锁过期时间到底设多长。设太短，业务没执行完锁就过期了；设太长，一旦持有锁的实例崩溃，其他线程要等很久。成熟的做法是用自动续期机制，比如Redisson客户端的看门狗，默认锁30秒，每隔10秒会自动续期，只要业务没结束锁就不会被提前释放。这个设计我强烈建议直接复用，不要自己写续期逻辑，自己写的续期脚本出错概率高得多。

5.2 Redis限流的两种实用方案

限流本质上就是控制单位时间内的请求数量。Redis做限流的第一个方案是固定窗口计数，核心就两条命令：INCR和EXPIRE。但这两条命令组合在一起也不是原子操作，所以直接用Lua脚本包一层：

local current = redis.call('INCR', KEYS[1]) if current == 1 then redis.call('EXPIRE', KEYS[1], ARGV[1]) end if current > tonumber(ARGV[2]) then return 0 end return 1

ARGV[1]是窗口大小秒数，ARGV[2]是最大数量。这个方案的缺点是固定窗口边界处可能涌进双倍流量，比如限制1分钟100次，第59秒来了100次，第61秒又能来100次。如果业务对流量平滑度要求高，要用滑动窗口。

滑动窗口的经典实现是ZSet。每个请求到来时把时间戳作为score写入ZSet，然后删除窗口之前的历史记录，最后统计剩余数量。命令是这样：

> ZADD rate:123 1680000000 "req1" > ZREMRANGEBYSCORE rate:123 0 1679999400 > ZCARD rate:123 (integer) 1

如果ZCARD超过阈值，就拒绝当前请求。这个方案精确度高，但每个请求都要写ZSet，写入量较大，不适合超高压场景。实际项目里我通常把固定窗口限流用于接口级粗粒度限流，滑动窗口用于核心接口的精细限流。

5.3 Lua脚本带来的原子性保证

为什么Redis限流、释放锁、扣减库存都要用Lua?因为Redis执行Lua脚本时是原子性的，脚本执行期间不会有其他命令插进来，也不会被其他客户端的命令打断。用多个普通命令组合实现同一功能，中间一旦被打断，数据就出问题。

举个最常见的库存扣减场景。伪代码如下：

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

检查库存、扣减库存、返回结果三步在一个脚本里完成，没有任何并发间隙。这是我在秒杀类接口里最常用的写法，简单可靠，还省掉了应用层事务的复杂度。

6. 集群架构：从单机到Redis Cluster的演进

单机Redis哪怕性能再好，也有两个天花板：一是容量，单机内存是有限的；二是可用性，一台机器宕机对于线上系统就是事故。我见过太多小团队一开始只用单机，等用户量涨起来后只能连夜迁移。与其被动，不如主动了解清楚演进路线。

6.1 主从复制与哨兵：先解决可用性

主从复制解决的是“数据备份和读写分离”问题。一个主节点负责写入，多个从节点复制主节点的数据并提供读服务。主节点挂了，人肉切一台从节点上来继续服务。

但人肉切换太慢。Redis 2.8版本之后有了哨兵机制，它能自动监控主节点状态，发现主节点挂了会从从节点中选举一个提升为新的主节点，并通知客户端更新连接地址。部署哨兵需要注意的是：哨兵自身也要高可用，一般部署3个或5个形成奇数集群，配合quorum配置才能正确判断故障，避免误切主节点。

主从复制的坑也不少，我踩过最典型的是复制中断和主从延迟。主从延迟会导致读取从节点时拿到旧数据，对一致性敏感的业务，写后读请求应该强制走主节点，或者短期缓存写操作的mark，规避延迟。

6.2 Redis Cluster：槽位路由与扩展性

主从加哨兵解决了单点问题，但数据总量仍然受制于单机内存。当数据量达到几十G甚至上百G时，就要考虑Redis Cluster了。

Cluster把整个Key空间分成16384个槽位，每个节点负责一部分槽位。写入或读取某个key时，客户端通过CRC16计算它的哈希值，再对16384取模，得到这个key应该落在哪个槽位上。比如现在有一个三主三从的集群，三个主节点大致各分管约5461个槽位。

有一个细节很有意思：为什么槽位数是16384而不是65536或者更大？Core团队考虑的是，每个节点在心跳包里要用bitmap形式传播自己的槽位信息，16384个槽位对应2KB的bitmap，传输开销小；而65536个槽位的bitmap要8KB，心跳包就太大了。这个设计是用传输带宽换路由精度，理解不了也没关系，知道这个数字背后有传输成本考量就够了。

集群部署后有几点要特别注意：客户端必须支持Cluster协议，遇到MOVED和ASK重定向要能正确处理，不然数据路由错了自己还不知道；多key操作时，如果key不在同一槽位上，会直接报错，需要用Hash Tag把相关key强制落到同一槽位。

6.3 大Key与热Key：集群时代的头号隐患

我把大Key和热Key放在集群章节讲，是因为它们在单机时代容易掩盖，一旦上集群会暴露得非常明显。

大Key是指单个value过大，比如一个Hash里有几百万个字段，或者一个Set里有上千万元素。它的危害是：读写耗时高，会阻塞Redis主线程；占用内存不均衡，导致集群节点间负载漂移；删除时如果直接DEL，瞬间阻塞所有请求。处理大Key的标准方式是拆分和压缩，但更重要的一点是提前发现。生产环境里我习惯用SCAN遍历所有key，配合检查每个key的value长度和容器元素数量，把超过阈值的大Key自动预警出来。

热Key是指某个key的访问量特别高，比如明星突然上了热搜，或者某件商品直播爆单。它会打爆单个节点。解决办法可以是：在应用层加本地缓存，用空间换时间；或者把热Key拆成多个副本key分散到不同节点，比如在原始key后面加1到N的后缀，读取时随机访问一个副本；也可以直接对热点key做多副本只读，写时同步到所有副本。

6.4 容量规划与部署排坑建议

容量规划的核心原则是：Redis内存不要用满顶点。如果你给实例分配了16GB物理内存，建议maxmemory设置在10到12GB左右，因为fork生成RDB快照、AOF重写都需要额外内存，操作系统页缓存也需要留余地。一旦内存被打到接近物理边界，系统开始使用swap，性能会断崖式下降。

部署时的几个排坑点，都是我用真实教训换来的：

• 生产环境禁用KEYS命令，它会全表扫描Redis并阻塞主线程；需要遍历用SCAN命令配合游标。
• 开启protected-mode时记得配置正确的访问白名单，否则客户端会被拒之门外。
• rename-command把高危命令重命名或禁用，防止被外部恶意执行。
• 集群节点数量、副本数量决定容错能力，三主三从是常见起步配置，但别只图省事建一个“伪集群”。

7. 线上问题排查实录与性能调优清单

Redis排障没有太多玄学，关键在快速定位方向和减少试错成本。我平时排查线上的顺序是：先看监控告警，再查日志，然后用Redis自身提供的诊断命令确认根因。这里把我用过最多、效率最高的几套方法整理成速查手册。

7.1 慢查询日志：定位延迟的起点

Redis提供了慢查询日志，记录超过指定耗时的命令。默认的slowlog-log-slower-than是10000微秒（10毫秒），生产环境这个阈值偏宽，我一般调成1000，也就是1毫秒。

> CONFIG SET slowlog-log-slower-than 1000 OK > SLOWLOG GET 20

看到慢查询命令后，重点分析是不是大Key引起的。比如HGETALL一个几万字段的Hash、ZRANGE一个几百万成员的有序集合、KEYS全表扫描，这些命令时间消耗高，要在业务层改掉。慢查询日志不是持久化的，Redis重启后会丢，所以建议配置完慢查询阈值后，定期把日志拉取到监控系统做分析。

7.2 INFO命令：内存与持久化的体检报告

INFO命令是Redis自带的“体检报告”，我最关注这几个指标：

mem_fragmentation_ratio如果超过1.5，说明内存碎片较多，可以选低谷期重启实例或执行MEMORY PURGE压缩碎片。instantaneous_ops_per_sec结合慢查询一起看，能快速判断当前是否处于高负载状态。我每次上线新版本Redis后都会第一时间看这份报告，确认配置生效、内存水位正常、连接数没有异常增长。

7.3 连接数被打满的应急处理

线上最老套也是最常见的故障是连接数打满。一个Redis实例默认maxclients是10000，当应用服务器连接池配置过大，或者业务代码有连接泄漏，很容易一夜之间把连接数打爆。现象是新的Redis客户端全部连接超时，服务大面积报错。

应急处理分两步：第一步，用CLIENT LIST查看当前连接来源，找到连接数最多的那台应用服务器，检查它的连接池配置；第二步，用CLIENT KILL杀掉疑似异常连接，快速恢复服务。

从根上解决问题，要在应用层做好三件事：使用连接池而不是每次请求新建连接；给连接池设置合理的maxTotal和maxIdle，避免无限制扩容；配置空闲连接回收时间，防止连接泄漏。

我在某个项目里遇到过连接数持续上涨的怪事，查了很久才发现是某个定时任务每次执行都没有归还连接。后来统一走连接池并在代码里加了异常归还的兜底逻辑，连接数稳定回落到几百。

7.4 一份可以直接抄走的性能调优参数表

这里列一份我在生产环境中验证过的常用参数配置，能覆盖大部分业务场景的基础调优：

千万不要看到参数就一堆改，一次只改一个关键配置，然后用监控数据验证效果。改多了，出了问题都不知道是哪一条导致的，这是我吃了不少亏之后最深的体会。

8. 最后分享几个实战中摸出来的经验

Redis的坑，网上文章说得再多，都不如自己亲手踩一次记得牢。这里分享几条我沉淀下来的小经验，也是我平时带人必讲的内容。

第一，新项目接入Redis之前，先用redis-benchmark在自己环境压一次。别轻信网上说的“单机十万QPS不解释”，不同机器、不同网络、不同数据大小，性能差异非常大。压测时看INFO stats里的instantaneous_ops_per_sec，那才是你当前环境的真实值。这个习惯帮我挡掉过好多次想当然的架构设计。

第二，监控要先于问题存在。不要等出故障了才去看数据。至少要把used_memory、connected_clients、rejected_connections、慢查询数量这几个指标接到监控系统里，设置合理的告警阈值。我自己见过太多线上事故，都有数分钟的黄金挽救期，监控到位就能避免后续的连锁反应。

第三，别把缓存一致性只停留在口头上。缓存和数据库的数据一致性，最稳妥的做法是更新数据库后删除缓存，也就是Cache Aside模式。高并发下还要配合延迟双删：先删缓存，更新数据库，再短延迟后删一次缓存，确保在极端并发下旧数据不会残留。如果想更严格，还可以订阅数据库binlog异步删除缓存，但这个方案工程复杂度高，一般业务用不上。

第四，不要神话Redis。它就是一把锋利的刀，可以切菜也可以伤人。没有慢查询排查习惯、没有容量规划、没有监控预警，Redis迟早会在某次高并发里给你一记重拳。真正的高手，不是Redis用得多花哨，而是知道什么时候该用、什么时候不该用，以及出了问题怎么快速恢复。

做技术就是这样，踩坑不可怕，怕的是踩完坑不去总结。希望这份实战记录能让你少走一些我走过的弯路，也希望你下次部署Redis时，心里多一份笃定，少几分忐忑。