想象你是一家高档餐厅的后厨总管。Redis 就是你的备料台和传菜系统——所有食材都放在伸手可及的地方，保证出菜速度快到让客人忘记等待。可有一天客人多了起来，你发现问题接踵而至：同样的备料台，有人乱用储物柜导致空间不够用；传菜员跑一趟只端一盘菜，忙得脚不沾地；厨房角落还堆着几个没人要的巨大高压锅，死死堵住通道；菜谱记录方式要么太啰嗦要么太偷懒，打烊复盘总要花半小时；就连储物柜也因反复塞取出现许多塞不进东西的碎空格。 这篇文章就是教你当一名“后厨优化大师”。一共六招：选对储物容器（数据结构选型）、揪出上菜慢的环节（慢查询排查）、一次端好多盘菜（管道与批量）、用聪明的记账方式平衡性能与安全（持久化调优）、整理厨房碎空间（内存碎片治理）、搬走巨型高压锅（大Key治理）。六招落地，你的“Redis之厨”在高并发人潮中也能稳如泰山、出菜如飞。

岗位关联

对 AI 从业者的价值：Redis 是互联网后端的事实标准缓存层，掌握高性能调优等于握住了高并发系统的命脉——这是后端工程师、SRE 和架构师面试与实战中的硬通货能力。

目录
  1. 可视化演示
  2. 数据结构选型——选对容器，省下空间
  3. 慢查询排查——揪出上菜慢的环节
  4. 管道与批量——一次端十盘菜
  5. 持久化调优——账本与快照的平衡
  6. 内存碎片治理——厨房空间整理术
  7. 大Key治理——搬走压箱底的高压锅
  8. AI 应用场景
  9. Python 演示
  10. 常见误区
  11. 面试题

可视化演示

展示Redis数据结构内存优化、Pipeline管道吞吐提升，以及RDB/AOF持久化策略调优，帮助理解Redis性能优化核心技巧。

本节配有交互动效（进入视口后自动加载，约 3KB）。

'+_captions.memory+'

数据结构选型——选对容器，省下空间

后厨里的储物柜形形色色：密封罐、保鲜盒、冰格、挂钩各有用途。Redis 也一样，提供了五种基础数据结构，各有各的脾气。用对了寸土寸金，用错了空间爆炸。最常见的浪费，就是把一个对象的每个字段都单独存成一个 String key——就像把一罐调味料的每一种配料都拆成独立的小瓶，柜子被塞得满满当当，取用还麻烦。

假设一个用户对象有 name、age、email 三个字段。用 String 存，就是三个独立的 key，每个 key 都要背负一份元数据：类型指针、引用计数、LRU 时钟、过期时间……动辄几十字节。而用 Hash 存，只需要一个 key 下挂三个 field，这些元数据只付一次。当你有几千万用户时，这一来一回就是几十 GB 内存的差距。

除了 Hash 省内存的绝活，List 适合做消息队列（LPUSH 进、BRPOP 出）、Set 适合做去重和集合运算（求共同关注）、ZSet 适合做排行榜（分数+成员）。选型心法一句话：别让每个小字段都当“独立 key”来养，能聚合就聚合，能用 Hash 就用 Hash。

把散装糖果倒进分格收纳盒，一个盒子管所有口味——Hash 就是那个收纳盒。选对容器，储物柜不仅装得更多，取用还更快。

内存String=n×Kkey开销,内存Hash=Kkey开销+n×Ffield开销\text{内存}_{\text{String}} = n \times K_{\text{key开销}}, \qquad \text{内存}_{\text{Hash}} = K_{\text{key开销}} + n \times F_{\text{field开销}}
Hash 方式只有一个 key 的固定开销，String 方式要为每个字段付一份独立的 key 开销，n 越大省得越多。
  1. n 为字段数量用户对象有 name、age、email 三个字段，n 就是 3，String 方式会创建 3 个独立 key。
    n=3n = 3
  2. K_key开销 为每个 key 的元数据成本类型信息、指针、LRU 时钟等，约数十字节，String 有几个字段就要付几次。
    Kkey开销≈数十字节K_{\text{key开销}} \approx \text{数十字节}
  3. F_field开销 为 Hash 的字段成本field 只是哈希表里的一条槽位，元数据被整个 key 共享，远小于独立 key 的开销。
    Ffield开销≪Kkey开销F_{\text{field开销}} \ll K_{\text{key开销}}

慢查询排查——揪出上菜慢的环节

后厨总管最怕的是一桌客人同时催菜，却不知道哪儿卡住了。Redis 里有一块“计时码表”——慢查询日志（slowlog）。每条命令执行完，它都掐表记录，超过你设的时间线就写进“黑名单小本本”，供你事后复盘。

可默认的时间线是 10 毫秒（10000 微秒），这太松了。一个本该 0.1 毫秒完成的 SET 命令，如果排队排了 9 毫秒，不会被记录，但它确实拖慢了整个请求链路。生产上一般把 slowlog-log-slower-than 调低到 1 毫秒甚至 500 微秒，同时把 slowlog-max-len 调到 512 以上，让日志存得住、搜得到。

慢查询日志抓到“罪菜”后，还要认得“坏食材”：KEYS *、HGETALL、LRANGE 这类 O(N) 命令，数据量一大必然变慢。它们是单线程 Redis 的大胃王——一条命令吃满 CPU，后面所有请求都在队伍里干瞪眼。记住：Redis 是单线程侍者，一个慢动作，全场等。

就像在每个工位放一个计时器，超过 1 分钟就亮红灯，总管才能第一时间冲过去处理。慢查询日志就是那盏红灯，调低阈值、调大容量，才能让红灯亮得更及时。

t阻塞=max⁡j(tj),其中  tj≥T阈值t_{\text{阻塞}} = \max_j \left( t_j \right), \qquad \text{其中}\; t_j \ge T_{\text{阈值}}
最坏情况下，一条慢命令的执行耗时就是后面所有命令的排队时间；Redis 是单线程，没有谁能在它卡住时“插队”。
  1. t_j 为第 j 条命令的执行耗时Redis 单线程同一时刻只能执行一条命令，所以每条命令的耗时都是可被 slowlog 掐表记录的公开数据。
    tj=第 j 条命令的执行耗时t_j = \text{第 } j \text{ 条命令的执行耗时}
  2. T_threshold 为慢查询阈值由 slowlog-log-slower-than 决定，超过它才会记入日志，单位是微秒。
    T阈值=slowlog-log-slower-than 的值T_{\text{阈值}} = \text{slowlog-log-slower-than 的值}
  3. 取最大值就是最坏卡顿只要有一条命令超时，排在它后面的所有请求都得等它跑完，所以一次最坏阻塞时长等于所有超时命令中耗时最大的那一条。
    t阻塞=max⁡j(tj),tj≥T阈值t_{\text{阻塞}} = \max_j(t_j), \quad t_j \ge T_{\text{阈值}}

管道与批量——一次端十盘菜

后厨的传菜员要是端一盘菜跑一趟，客人点 100 道菜他就得跑 100 趟。Pipeline 就是传菜电梯——你在轿厢里码好 100 盘菜，按一次按钮全部送达。Redis 的“传菜距离”是网络往返（RTT），逐条发命令就像传菜员一趟趟跑，浪费的时间全在路上。

网络往返是 Redis 性能最大的隐形杀手。局域网下一次 RTT 约 0.5 毫秒，看起来不起眼，但 1 万条命令逐条发，光往返时间就要 5 秒。如果用 Pipeline 打包成一批，这 5 秒瞬间变成 0.5 毫秒加上命令本身的总执行时间——快了几乎一个数量级。

批量操作有几招常用姿势：MSet 一次性写入多个 key；Pipeline 发送任意命令组合；Lua 脚本在服务端一次性执行多步逻辑。注意 Pipeline 不是事务——它只优化网络打包，命令依然逐条执行，中途某条失败不影响其他条。还要控制每批大小，几百到几千条为宜，免得客户端内存和网络带宽被超大请求包撑爆。

传菜电梯按一次按钮，100 盘菜一次性到位。客人惊叹“怎么这么快”，大厨心里偷笑：不过是按了一次钮。

T逐条=N×TRTT+N×t执行,T管道=TRTT+N×t执行T_{\text{逐条}} = N \times T_{\text{RTT}} + N \times t_{\text{执行}}, \qquad T_{\text{管道}} = T_{\text{RTT}} + N \times t_{\text{执行}}
逐条方式把网络往返付了 N 次，管道方式只付 1 次；N 越大，管道优势越夸张。
  1. N 为命令条数比如一次批处理写入 10000 条数据，N 就是 10000。
    N=10000N = 10000
  2. T_RTT 为网络往返耗时客户端到 Redis 一来一回的时间，局域网约 0.1~1 毫秒。
    TRTT=网络一来一回的时间T_{\text{RTT}} = \text{网络一来一回的时间}
  3. t_exec 为单条命令执行耗时Redis 内部执行非常快，通常在微秒到几十微秒级别。
    t执行≈微秒级t_{\text{执行}} \approx \text{微秒级}
  4. 对比总公式逐条方式有 N 个 RTT，管道方式只有 1 个 RTT。当 N 很大时，管道方式的总耗时约等于 N 个命令的执行时间，比逐条方式小一两个数量级。
    T管道≈N×t执行≪T逐条T_{\text{管道}} \approx N \times t_{\text{执行}} \ll T_{\text{逐条}}

持久化调优——账本与快照的平衡

后厨每天打烊要“记账”。RDB 是拍集体照：每隔一段时间咔嚓一张，把当前所有菜的状态定格成一张照片；AOF 是写流水账：每做一道菜，就在账本上补一行。拍照恢复快，但只能回到上一张照片的时刻；流水账详细，但写起来啰嗦、重放也慢。

如果只开 RDB，默认策略（save 900 1 / 300 10 / 60 10000）下最坏情况可能丢失 60 秒的写入——大促期间 60 秒的数据可能就是几百万个订单。如果只开 AOF，把 appendfsync 设成 always 每条命令都刷盘，安全是安全了，吞吐量却可能被磁盘 I/O 拖垮，Redis 的“快”就名存实亡。

工程上的黄金平衡是混合持久化：RDB 做底子，恢复时直接加载快照秒级启动；AOF 只记录快照之后的新增量，丢失窗口最小化。AOF 刷盘选 everysec，每秒把缓冲区写入磁盘一次，性能损耗可忽略，极端故障最多丢 1 秒数据。再配合主从复制，主节点磁盘彻底报废，从节点也能立刻顶上。

聪明的后厨既拍集体照又写流水账：照片用来快速恢复全貌，流水账用来补上照片之后的细节。数据安全与性能，这本账就算明白了。

丢失窗口=min⁡(TRDB间隔,1ffsync)\text{丢失窗口} = \min\left(T_{\text{RDB间隔}}, \frac{1}{f_{\text{fsync}}}\right)
哪个策略的丢失窗口小，整体就按它算：RDB 按分钟丢，AOF everysec 最多丢 1 秒，混合后乐观估计丢 1 秒。
  1. T_RDB间隔 为两次快照的最大间隔默认配置下最坏约 60 秒，意味着宕机可能丢失最近 60 秒的写入。
    TRDB间隔=60 sT_{\text{RDB间隔}} = 60\,\text{s}
  2. f_fsync 为 AOF 刷盘频率appendfsync everysec 表示每秒刷 1 次盘，always 表示每条命令都刷盘。
    ffsync=1 次/sf_{\text{fsync}} = 1\,\text{次/s}
  3. min 取较小值工程上乐观估计——两种策略同时在工作，丢失窗口约等于较小者，混合持久化后就是约 1 秒。
    min⁡(60 s,1 s)=1 s\min(60\,\text{s}, 1\,\text{s}) = 1\,\text{s}

内存碎片治理——厨房空间整理术

厨房的储物柜被反复塞进取出各种尺寸的食材后，柜子里出现许多巴掌大的碎空格：看着明明还有空间，可就是塞不进一条完整的鱼。Redis 的内存碎片就是这么来的：频繁的写入、更新、删除，让内存分配器给你划出一块块“碎格子”。

用 info memory 能看到两个关键数字：mem_allocator 是操作系统分配给 Redis 的总内存，mem_used 是 Redis 真正放数据用掉的内存。碎片率 = 前者 ÷ 后者。高于 1.5 说明碎片已经很严重：数据只占 2GB，系统却塞给 Redis 4GB，剩下的 2GB 既不能放数据，也不能还给系统，甚至可能触发 OOM——明明 mem_used 没满，新写入却失败了。

Redis 4.0 起支持热碎片整理：开启 activedefrag yes，后台线程会在碎片率超过阈值时自动搬运合并小碎片，全程不阻塞主线程。同时配合 maxmemory 设上限 + maxmemory-policy 指定淘汰策略，内存打到上限时按 LRU/LFU 优雅淘汰冷数据，而不是直接报错崩溃。这就好比给储物柜做断舍离：碎空间并成大空间，陈年旧货该扔就扔。

大扫除之后，储物柜又能多放好几层新菜，取东西也利索了。内存碎片治理的意义就在于此：花最少的力气，拿回被白白浪费的空间。

碎片率=mem_allocatormem_used\text{碎片率} = \frac{\text{mem\_allocator}}{\text{mem\_used}}
碎片率等于 1 最理想；大于 1.5 要处理；小于 1 意味着分配的内存比实际用的还少，可能在换页，是危险信号。
  1. mem_allocator 为分配器分配的内存操作系统层面给 Redis 的总空间，包含了碎片、缓冲区和备用空间。
    mem_allocator=OS 分配的总内存\text{mem\_allocator} = \text{OS 分配的总内存}
  2. mem_used 为 Redis 实际使用数据真正占用的字节数，排除了碎片等开销。
    mem_used=数据实际占用的内存\text{mem\_used} = \text{数据实际占用的内存}
  3. 比值含义大于 1.5 时碎片严重，需要开启整理或重启；越接近 1 越健康；小于 1 说明 used 比 allocator 还大，内存不够，可能在 swap。
    碎片率{>1.5需要整理≈1健康<1内存不足\text{碎片率} \begin{cases} > 1.5 & \text{需要整理} \\ \approx 1 & \text{健康} \\ < 1 & \text{内存不足} \end{cases}

大Key治理——搬走压箱底的高压锅

厨房角落里那口超大的高压锅，平时用不上，但每次搬它都要惊动全厨房：通道被堵，其他菜上不了桌，想把它扔出去还得几个人抬半天。Redis 里的大 Key 就是这样一件“巨型厨具”。

大 Key 通常指单个 String 值超过 10KB，或集合类型元素超过一万个。它的危害是连锁的：删除时主线程被卡住（DEL 是同步的）、读取时网络带宽被占满、集群模式下还会造成数据倾斜——别的节点都在休息，就它那台节点内存爆表。更可怕的是它平时安安静静，一到清理和迁移时就爆发，成为线上事故的定时炸弹。

治理大 Key 分三步走。第一步发现：redis-cli --bigkeys 全库扫描、DEBUG OBJECT 查看某个 key 的序列化长度、从慢查询日志里反推哪些 key 频繁制造慢命令。第二步拆分：大 Hash 用哈希取模拆成多个小 Hash，大 List 按时间段分段成多个 List。第三步删除：用 UNLINK 替换 DEL——UNLINK 是异步删除，主线程只把 key 从字典里摘除，内存释放交给后台线程，删除耗时从秒级降到毫秒级。

把超重的高压锅换成一排轻便的小砂锅，搬运、清洗都省事，厨房通道再也不堵了。大 Key 治理的哲学就是：别让任何一道菜变成整个厨房的瓶颈。

TDEL=O(sizekey),TUNLINK=O(1)+异步释放T_{\text{DEL}} = O(\text{size}_{\text{key}}), \qquad T_{\text{UNLINK}} = O(1) + \text{异步释放}
DEL 的耗时与 key 大小成正比，所以大 Key 一删就卡；UNLINK 主线程只做 O(1) 的摘除操作，真正的重活在后台慢慢干。
  1. size_key 为 key 的大小元素个数或字符串字节数，大 Key 的 size 特别大。
    sizekey=元素数量或字节数\text{size}_{\text{key}} = \text{元素数量或字节数}
  2. DEL 的复杂度为 O(size)DEL 同步删除，百万元素的 List 删除耗时是万级 List 的百倍，期间 Redis 主线程被完全占用。
    TDEL=O(sizekey)T_{\text{DEL}} = O(\text{size}_{\text{key}})
  3. UNLINK 的复杂度为 O(1)UNLINK 只把 key 从字典中摘除，实际内存释放交给后台线程异步完成，主线程立即返回。
    TUNLINK=O(1)T_{\text{UNLINK}} = O(1)

AI 应用场景

电商大促秒杀——用 Hash 和 Pipeline 扛住峰值流量

阶段：系统性能优化阶段（缓存层调优）

解决的问题：大促前商品详情接口每秒数万次访问，每个商品的多个属性如果拆成多个 String key 存储，内存和网络开销成倍增长；秒杀下单流程要多次读写 Redis 库存和订单号，逐条命令的网络往返时间累加起来，直接把 P99 延迟拖到不可接受。

具体案例：某电商平台把热门商品信息从 5 个 String key 合并为 1 个 Hash key，内存占用下降 38%；下单链路改用 Pipeline 批量写入库存扣减和流水记录，峰值 QPS 从 8 万提升到 15 万，P99 延迟从 52ms 降到 18ms。

金融支付系统——用持久化策略守住数据安全底线

阶段：数据安全配置阶段（持久化调优）

解决的问题：分布式锁和交易状态存放在 Redis，如果持久化策略不当，进程崩溃或机器宕机时丢失最近写入的数据，会导致重复支付或交易状态错乱；但 AOF 每次都刷盘又会让性能暴跌，无法支撑每秒上万笔的交易流水。

具体案例：某支付团队采用 AOF everysec + 定期 RDB 快照的混合持久化方案，并调优 RDB 触发条件（缩短快照间隔），在实测断电故障中丢失窗口控制在 1 秒内，实例恢复时间从原来的分钟级降到 30 秒以内，业务连续性得到保障。

Python 演示

python41 行
import random  def mock_rtt():    """模拟一次网络往返耗时, 单位毫秒"""    return random.uniform(0.8, 1.2)  def mock_exec():    """模拟一条命令在 Redis 内的执行耗时, 单位毫秒"""    return random.uniform(0.05, 0.2)  def send_one_by_one(n):    """逐条发送: 每条命令都等一次网络往返"""    total = 0.0    for _ in range(n):        total += mock_rtt()        total += mock_exec()    return total  def send_pipeline(n):    """管道发送: 只等一次网络往返, 执行耗时累加"""    total = mock_rtt()    total += sum(mock_exec() for _ in range(n))    return total  def main():    random.seed(42)    n = 5000    t1 = send_one_by_one(n)    t2 = send_pipeline(n)    print(f"逐条发送 {n} 条命令耗时: {t1:.1f} ms")    print(f"管道批量 {n} 条命令耗时: {t2:.1f} ms")    print(f"吞吐量提升约 {t1 / t2:.1f} 倍")  if __name__ == "__main__":    main()
目的：用随机耗时模拟逐条发送与管道批量发送 5000 条命令的总耗时，直观展示 Pipeline 减少网络往返带来的性能提升。
  1. return random.uniform(0.8, 1.2)模拟一次网络往返 RTT，结果在 0.8~1.2 毫秒之间随机浮动。
  2. total += mock_rtt()逐条模式下每条命令都单独付一次“网络费”，累积起来非常可观。
  3. total = mock_rtt()管道模式只付一次“网络费”，这就是节省的核心。
  4. total += sum(mock_exec() for _ in range(n))命令本身的执行时间省不掉，只能靠减少往返来优化。
  5. t2 = send_pipeline(n)对比实验组的耗时，通常只有逐条方式的几十分之一。
  6. print(f"吞吐量提升约 {t1 / t2:.1f} 倍")两者相除得到性能提升倍数，直观感受管道的威力。

常见误区

误区Redis 数据放内存里，速度就是快，不用像磁盘数据库那样精打细算内存。反正机器内存不够了，加内存条不就完了？

正解内存是 Redis 最贵的资源，数据量一旦上亿，选错数据结构的浪费是以 GB 计算的。比如几千万个用户对象拆成多个 String key，元数据开销翻好几倍，白白吃掉几十 GB 内存。更糟的是内存满后触发 maxmemory-policy 淘汰，可能误杀热点数据引发雪崩。选对 Hash/List 等结构，内存占用能直接减半。

为何常见：磁盘时代养成了“空间够大随便用”的惯性，而且小数据量下用错结构和用对结构看不出差别，只有量大时才爆雷。

误区Redis 自带 slowlog，不用特地配置。反正我开着它，也没发现什么慢命令，说明系统很健康。

正解默认的 slowlog-log-slower-than 是 10000 微秒（10 毫秒），对小命令来说 10 毫秒已经是地狱级延迟，而且 slowlog-max-len 只有 128 条，日志很快被冲掉。要把阈值调到 1 毫秒左右，存储条数调到 512 以上，再配上监控告警，才能真正捕捉到事故元凶。

为何常见：默认值在官方文档里看起来合理，实际生产压力一大就原形毕露。很多人开着 slowlog 但从没调过参数，等于没开。

误区既然管道能减少网络往返，那把一万条甚至十万条命令一次性打成一个包发出去，速度不就能提升一万倍吗？

正解一次 Pipeline 塞太多命令会带来三个问题：客户端要攒满内存构建大请求、Redis 单线程处理完所有命令需要时间、网络包太大会触发 TCP 分片导致额外延迟。合理做法是分批，每批几百到几千条，边发边收。吞吐量提升的核心是减少 RTT 次数，不是追求单批的绝对大小。

为何常见：直觉上“批量越大=往返越少=越快”，忽略了内存占用和单线程处理能力的物理上限。

误区数据安全第一，AOF 的 appendfsync 一定要设置成 always，每条命令都立刻写入磁盘，这样才能保证零丢失。

正解always 模式在每次写命令后都同步 fsync，磁盘 I/O 成为瓶颈，吞吐量会暴跌数倍甚至一个数量级。Redis 本身定位是高性能缓存，工程上几乎都用 everysec——每秒刷盘，最多丢 1 秒数据，性能损耗可忽略。追求零丢失应该靠主从复制加多副本，而不是牺牲性能去硬刷盘。

为何常见：人的天性是把安全放到第一位，尤其数据相关。但忘了性能也是可用性的一部分，缓存层的存在意义就是快。

误区Redis 删 key 不是一句话的事嘛，DEL user:10001 不就删掉了？管它多大，删完就干净了。

正解DEL 是同步删除，会阻塞 Redis 主线程。一个包含上百万元素的 List 或 Hash，DEL 操作可能卡住 Redis 几秒，期间所有读写请求全部排队。正确做法是：用 UNLINK 异步删除（主线程只需 O(1) 摘除引用），或者用 SCAN 分批删除，把大 Key 拆成小批次慢慢清。

为何常见：平时删的都是小 key，毫秒级完成，形成了“DEL 很快”的思维定式，完全没意识到删除耗时跟 key 大小成正比。

面试题

Q1. Redis 中存储一个含多个字段的对象（如用户信息），哪种结构最省内存？

单选题 · easy

  • A.每字段存为一个String
  • B.用Hash保存所有字段← 正确答案
  • C.序列化ZIP后存String
  • D.每字段存为独立Set

答案：B。A 每个字段都是独立 key，元数据开销大；C 省了 key 但无法单独读写字段（改一个字段要整个反序列化）；D 用 Set 存字段完全不对路。Hash 用一个 key 挂多个 field，元数据只付一次，是这类场景的标准答案。

Q2. Redis 慢查询日志默认的命令耗时阈值是多少？

单选题 · easy

  • A.默认阈值是100微秒
  • B.默认阈值是1000微秒
  • C.默认阈值是10000微秒← 正确答案
  • D.默认阈值是100000微秒

答案：C。默认 slowlog-log-slower-than 为 10000 微秒，即 10 毫秒。对高并发系统来说，10 毫秒的命令已经严重拖慢链路，所以生产环境必须主动调低阈值，否则慢查询日志形同虚设。

Q3. 以下哪种方式能最有效地减少 Redis 网络往返次数？

单选题 · mid

  • A.调大slowlog阈值
  • B.使用Pipeline批量发送← 正确答案
  • C.开启RDB后台持久化
  • D.增加maxmemory上限

答案：B。Pipeline 把 N 条命令打包成一次请求，网络往返从 N 次降到 1 次，这是质的飞跃。slowlog 阈值只管记录不影响执行；RDB 持久化与网络无关；maxmemory 只限内存，都跟 RTT 没有直接关系。

Q4. RDB 持久化的主要缺点是什么？

单选题 · mid

  • A.每次恢复慢且耗时长
  • B.快照间隔内数据易丢失← 正确答案
  • C.会生成超大二进制日志
  • D.只能搭配哨兵模式使用

答案：B。RDB 是定时快照，两次快照之间发生的写入在宕机时全部丢失，默认配置最坏丢 60 秒数据。恢复速度其实很快（直接加载二进制快照）；日志大小与 AOF 相当也非致命；D 选项与哨兵无关。所以主要缺点是 B。

Q5. 以下哪些命令在数据量较大时可能阻塞 Redis 主线程？

多选题 · hard

  • A.KEYS遍历全库键← 正确答案
  • B.LRANGE取长列表全量← 正确答案
  • C.SET写入短字符串
  • D.HGETALL取大哈希← 正确答案

答案：ABD。KEYS * 要遍历全库、LRANGE 取长列表全量、HGETALL 取大哈希全量，都是 O(N) 且 N 可能很大的操作，会长时间占用单线程。SET 是 O(1) 写入，不会阻塞。生产上这类 O(N) 命令要加 LIMIT 或用 SCAN 替代。

Q6. AOF 的 appendfsync 设置为 everysec 时，极端故障最多丢失多少数据？

单选题 · mid

  • A.最多丢失1毫秒的数据
  • B.最多丢失1秒的数据← 正确答案
  • C.最多丢失1分钟的数据
  • D.完全不会丢失任何数据

答案：B。everysec 每秒把缓冲区 fsync 到磁盘一次，极端崩溃最多丢 1 秒内未刷盘的写入。always 才是零丢失但性能极差；no 模式的丢失窗口取决于内核刷盘时机，可能超过 1 秒。

Q7. 以下哪些手段可以用于发现 Redis 中的大 Key？

多选题 · mid

  • A.用--bigkeys扫描大键← 正确答案
  • B.用DEBUG OBJECT查看← 正确答案
  • C.从慢查询日志中排查← 正确答案
  • D.直接看RDB文件大小

答案：ABC。--bigkeys 直接遍历估算 key 大小；DEBUG OBJECT 可以查具体 key 的序列化长度；大 Key 经常制造慢查询，所以 slowlog 能佐证。RDB 文件大小是整体指标，无法定位到具体 key，只能作为辅助怀疑线索。

Q8. Redis 设置了 maxmemory 上限后，还必须配置什么才能避免 OOM 报错？

单选题 · easy

  • A.配置save持久化频率
  • B.配置maxmemory-policy← 正确答案
  • C.配置主从复制模式
  • D.配置日志输出等级

答案：B。maxmemory 只设置上限，不设淘汰策略时 Redis 在内存打满后会拒绝写入并报 OOM 错误。maxmemory-policy 指定淘汰算法（如 allkeys-lru），让 Redis 优雅地淘汰冷数据。save、主从复制、日志等级都与此无关。

Q9. 关于 Redis 内存碎片率，下列说法正确的有哪些？

多选题 · mid

  • A.碎片率大于1.5需要关注整理← 正确答案
  • B.碎片率小于1可能正在换页← 正确答案
  • C.重启实例可以临时清理碎片← 正确答案
  • D.碎片率大于2必定引发崩溃

答案：ABC。碎片率 = allocator / used，大于 1.5 说明碎片严重需要整理；小于 1 说明 used 比 allocator 还大，内存不够正在 swap，是危险信号；重启会重新分配内存所以能清碎片。D 太绝对，碎片高只是增加 OOM 概率，不一定会立刻崩溃。

Q10. 某 Redis 实例运行一周后碎片率高达 3.0，used_memory 仅 1.2GB，业务请求变慢，以下哪个是最佳处理方案？

单选题 · extreme

  • A.立即重启实例清理碎片
  • B.开启activedefrag自动整理← 正确答案
  • C.降低maxmemory触发淘汰
  • D.清空所有数据重新加载

答案：B。activedefrag 是官方推荐的在线碎片整理，后台逐步搬移内存页，不阻塞服务。重启会中断服务，且碎片会随后续写入再次产生；降低 maxmemory 可能误删热点 key；清空数据动静太大且同样要阻塞。所以最佳方案是 B。