简介：本资源是一份面向Redis初学者与Web开发者的入门级技术分享课件，聚焦内存数据库核心原理、实战配置与关键特性解析。课件系统梳理了Redis高性能读写机制（11万+/秒读、8万+/秒写）、原子性保障、五大基础数据结构（string/hash/set/sorted set/list）及主从复制架构，并深入对比RDB快照与AOF日志两种持久化策略的配置项、适用场景与优劣权衡；同时涵盖常用key与string类命令详解及典型运维参数（如port、timeout、daemonize、databases等）说明。资源为单文件PPTX格式，共1个演示文稿，大小1.59MB，内容结构清晰，含简介、使用、配置、持久化、命令五大模块，图文结合便于课堂讲授或自学梳理。目前已有162人学习下载，适合高校学生、后端开发者及运维人员快速掌握Redis部署要点、配置调优逻辑与生产环境选型依据。

1. Redis 的“原子性”不是事务的原子性：为什么你用 MULTI/EXEC 依然会丢数据？

你有没有遇到过这样的场景：在秒杀系统里，用MULTI包住DECR stock和HSET order:123 user_id 1001 status pending，再EXEC执行，结果库存扣减成功了，但订单没写进去？或者更玄学的是——明明EXEC返回了[1,1]，查数据库却发现只有一条记录生效？这不是你代码写错了，也不是网络抖动，而是 Redis 的“原子性”被严重误读了。它根本不保证跨命令的业务一致性，只保证单个命令执行的不可分割性；而MULTI/EXEC的所谓“事务”，连 ACID 里的 I（隔离性）都做不到——没有锁、没有 MVCC、没有回滚机制，甚至 WATCH 机制在高并发下也极易失败。这份《Redis分享.pptx》表面是入门课件，实则暗藏大量被忽略的底层契约：RDB 快照 fork 时的内存拷贝开销、AOF rewrite 期间的双重写放大、主从复制中 repl-backlog 的环形缓冲区设计……这些不是配置参数，而是决定你系统能否扛住大促的底层齿轮。搞懂它们，你才能判断——该用INCRBY还是EVAL脚本，该开 AOF 还是 RDB，该选appendfsync everysec还是no。这不是 Redis 怎么用的问题，而是你是否真正信任它来承载核心状态的问题。

2. RDB 快照：fork() 不是免费午餐，它正在悄悄吃掉你的毫秒级响应

Redis 的 RDB 持久化常被简化为“定时保存快照”，但它的核心动作bgsave实际上是一场精密的内存博弈。关键不在“保存”，而在fork()——这个系统调用会创建子进程，而子进程与父进程共享物理内存页，靠写时复制（Copy-on-Write, COW）机制实现隔离。这意味着：只要父进程不修改数据，子进程就能安全地把当前内存镜像刷到磁盘；但一旦父进程在bgsave过程中大量写入（比如批量导入、热点 key 频繁更新），COW 就会触发大量页复制，导致：

• 内存使用瞬间翻倍（旧页+新页同时存在）；
• fork()调用本身延迟飙升（Linux 对大内存进程 fork 开销呈非线性增长）；
• 主进程响应卡顿，P99 延迟从 0.3ms 拉到 50ms+。

这正是 PPT 中那句“当数据量大时，fork 过程非常耗时，导致 redis 无法在毫秒级别内响应客户端请求”的真实含义——它不是警告，而是对 Linux 内存管理机制的直白复述。

2.1 RDB 触发条件背后的调度逻辑

RDB 并非简单按save 60 1000硬编码执行。Redis 内部维护一个dirty计数器，每次写命令（如SET,INCR）后递增；同时用lastsave记录上次成功 save 时间。服务器周期性（默认 100ms）检查：

• 若dirty >= 1000且now - lastsave >= 60，则触发bgsave；
• 若bgsave正在运行，则本次跳过（避免并发 fork）；
• 若bgsave失败（如磁盘满），dirty不重置，下次仍会尝试。

提示：save配置可叠加，如save 900 1+save 300 10+save 60 10000，满足任一条件即触发。这是 Redis 为不同负载场景预留的弹性策略，而非固定节奏。

2.2 fork() 的真实开销：从源码看内存页分裂

我们来看 Redis 3.2+ 中rdbSaveBackground的关键路径（简化）：

// src/rdb.c int rdbSaveBackground(char *filename) { pid_t childpid; long long start; if (server.rdb_child_pid != -1) return -1; // 已有 bgsave 运行 if ((childpid = fork()) == 0) { // 子进程：关闭监听 socket，调用 rdbSave() closeListeningSockets(0); redisSetProcTitle("redis-rdb-bgsave"); errno = 0; if (rdbSave(filename) == C_OK) { // 成功写入 dump.rdb } exitFromChild(0); } else if (childpid == -1) { // fork 失败：可能是内存不足或 ulimit -u 限制 serverLog(LL_WARNING,"Can't save in background: fork: %s", strerror(errno)); return -1; } // 父进程：记录子进程 PID 和启动时间 server.rdb_save_time_start = time(NULL); server.rdb_child_pid = childpid; updateDictResizePolicy(); return 0; }

注意：fork()后父子进程共享所有内存页，但 Linux 内核需为每个页维护引用计数。当父进程修改某 key 的 value（如SET user:1001 "new_name"），内核检测到该页被写入，立即分配新物理页、复制原内容、更新父进程页表——此过程对父进程是阻塞的。若此时有 10GB 数据集，且每秒 5000 次写入分散在不同内存页，COW 可能引发数百次页分配，直接拖慢主线程。

2.3 RDB 文件结构：二进制协议如何保证加载速度

RDB 文件不是 JSON 或 YAML，而是紧凑的二进制流，头部含魔数REDIS和版本号（如0009表示 v9），随后是数据库选择指令SELECTDB <dbid>，再是键值对序列。每个 key-value 对格式为：

[EXPIRETIME_MS] [EXPIRETIME] [FREQ] [LFRU] [VALUE_TYPE] [KEY_LENGTH] [KEY] [VALUE]

其中VALUE_TYPE决定后续解析方式：0为 string，1为 list（用 ziplist 编码），2为 set（intset 或 hashtable），3为 zset（ziplist 或 skiplist）等。这种设计让 Redis 加载时无需解析文本、无类型推断开销，直接 mmap 内存映射后顺序读取，dump.rdb1GB 文件可在 200ms 内完成重建——这正是它比 AOF 快的根本原因：省去了命令重放的解释执行成本。

2.4 RDB 的致命盲区：它永远不知道“正在发生的变更”

RDB 是某一时刻的静态切片，因此天然丢失bgsave启动后到结束前的所有写操作。假设：

• t=0s：bgsave启动，dirty=0
• t=0.5s：用户下单，INCR stock→dirty=1
• t=1.2s：bgsave完成，写入dump.rdb
• t=1.3s：Redis 崩溃

恢复时，stock值回到bgsave开始前的状态，0.5s 到 1.2s 的所有变更全部丢失。PPT 中“当 redis 停止工作的时候，会丢失掉一部分数据”说的就是这个窗口。这不是 bug，而是 RDB 的设计契约：它面向备份，而非实时容灾。

2.5 避坑：RDB 相关的 4 个血泪经验

• 现象：线上 Redis 内存占用突然涨到 20GB（实际数据仅 8GB），bgsave后内存未回落
  原因：stop-writes-on-bgsave-error no且磁盘满导致bgsave失败，但dirty计数器未清零，后续持续触发 fork，COW 复制大量脏页
  解决：监控INFO persistence中rdb_last_bgsave_status和rdb_last_bgsave_time_sec，失败时告警并手动BGREWRITEAOF清理

• 现象：bgsave执行时，INFO stats显示instantaneous_ops_per_sec从 5w 骤降到 500
  原因：vm.overcommit_memory=0（默认），内核拒绝为 fork 分配足够虚拟内存，fork()频繁失败重试
  解决：echo 1 > /proc/sys/vm/overcommit_memory（允许 overcommit）+sysctl vm.swappiness=1

• 现象：RDB 恢复后，某些 key 的 TTL 显示为-1（永不过期），但业务逻辑要求必须有过期时间
  原因：RDB 文件中过期时间以绝对时间戳存储（EXPIRETIME_MS），若服务器时间回拨（如 NTP 校准），加载时 Redis 认为该时间已过期，自动删除 key，但部分版本会将 TTL 设为-1作为 fallback
  解决：禁用 NTP 时间跳跃（ntpd -g启动），改用chronyd平滑校准；或用redis-cli --scan --pattern "*"批量检查 TTL

• 现象：SAVE命令执行时，整个 Redis 阻塞 3 秒，所有客户端超时
  原因：SAVE是同步保存，直接在主线程执行rdbSave()，无 fork 开销但彻底阻塞服务
  解决：生产环境禁用SAVE，只用BGSAVE；若需强制同步（如运维脚本），先CLIENT PAUSE 5000暂停客户端，再SAVE

3. AOF 重放：为什么“每秒刷盘”比“每次都刷”更危险？

AOF（Append Only File）常被宣传为“数据更安全”，但它的安全性完全取决于appendfsync策略和rewrite机制的协同。PPT 中列出everysec/always/no三种模式，却未点破一个反直觉事实：everysec在特定条件下比always更易丢数据。原因在于everysec的刷盘线程与主线程异步，当 Redis 崩溃时，AOF 缓冲区（aof_buf）中未刷盘的数据会丢失；而always虽慢，但每次写都落盘，崩溃时最多丢一条命令。更隐蔽的风险来自rewrite——它不是简单的文件压缩，而是一场涉及双缓冲、原子替换、信号处理的精密手术。

3.1 AOF 缓冲区：主线程与刷盘线程的竞态战场

Redis 启动时，若appendonly yes，会初始化aof_buf（sds 类型缓冲区）。所有写命令（如SET）执行后，不直接写磁盘，而是追加到aof_buf：

// src/aof.c void feedAppendOnlyFile(struct redisCommand *cmd, int dictid, robj **argv, int argc) { sds buf = sdsempty(); buf = catAppendOnlyGenericCommand(buf,argc,argv); if (server.aof_state == AOF_ON) server.aof_buf = sdscatlen(server.aof_buf,buf,sdslen(buf)); sdsfree(buf); }

aof_buf由主线程维护，而刷盘由后台线程（aof_fsync_thread）或主线程自身（always模式）执行。everysec模式下，Redis 创建独立线程，每秒调用aof_fsync()：

void aof_background_fsync(int fd) { // 调用 fdatasync(fd) 刷盘 if (fdatasync(fd) == -1) { serverLog(LL_WARNING,"Failed trying to fsync the AOF file: %s",strerror(errno)); } }

问题来了：若主线程在aof_buf追加命令后、刷盘线程尚未执行fdatasync前崩溃，这部分数据就永久丢失。而always模式下，feedAppendOnlyFile后立即fdatasync，崩溃只丢最后一条命令。

3.2 AOF rewrite：如何在不阻塞服务的情况下生成新日志？

BGREWRITEAOF不是读旧 AOF、过滤冗余命令、写新文件那么简单。它实际启动子进程，但子进程不读 AOF 文件，而是直接遍历当前内存数据，将每个 key 的最终状态转换为SET/RPUSH等命令写入临时文件。流程如下：

1. 主进程创建临时文件appendonly.aof.tmp；
2. fork()子进程；
3. 子进程遍历所有数据库，对每个 key 调用rewriteConfigForRedisObject()生成初始化命令；
4. 主进程将fork后的新写命令同时写入旧 AOF 和aof_rewrite_buf_blocks（环形缓冲区）；
5. 子进程完成后，主进程原子替换：rename(appendonly.aof.tmp, appendonly.aof)；
6. 主进程将aof_rewrite_buf_blocks中的增量命令追加到新 AOF 文件末尾。

注意：aof_rewrite_buf_blocks是内存缓冲区，非磁盘文件。若 rewrite 过程中 Redis 崩溃，新 AOF 文件不完整，Redis 启动时会检测并拒绝加载，回退到旧 AOF。

3.3 AOF 文件校验：redis-check-aof如何定位损坏位置？

AOF 文件本质是 Redis 协议命令流，每行以*N\r\n开头（N 为参数个数），后跟$M\r\n（M 为参数长度）和参数内容。redis-check-aof --fix的修复逻辑是：

• 逐行解析，维护一个栈记录当前命令的参数个数；
• 若遇到*3\r\n$3\r\nSET\r\n$5\r\nkey1\r\n$5\r\nval1\r\n，栈顶应为 3，消耗后栈空；
• 若某行*2\r\n后只读到 1 个$，则判定为截断，从该位置向前搜索最近的完整命令（如*3\r\n），截断后续所有内容。

这解释了为何 PPT 强调auto-aof-rewrite-percentage 100和auto-aof-rewrite-min-size 64mb：小文件 rewrite 频繁，大文件则可能因单次 rewrite 耗时过长（>30s）导致缓冲区溢出。

3.4 AOF 与 RDB 混合持久化：aof-use-rdb-preamble yes的真相

Redis 4.0 引入混合持久化，开启后 AOF 文件前半部分是 RDB 格式，后半部分是 AOF 命令。其设计动机是：RDB 加载快但丢失数据，AOF 安全但加载慢。混合模式下，Redis 加载时：

• 先用 RDB 解析器加载前半部分（快）；
• 再用 AOF 解析器重放后半部分（准）。

但 PPT 未提及关键限制：混合模式下，BGREWRITEAOF生成的文件仍以 RDB 开头，但 rewrite 过程中新增的命令不会自动转为 RDB 格式——它只是把当前内存快照作为起点，后续增量仍走 AOF 流程。因此，混合模式并未消除 AOF 的重放开销，只是缩短了起点。

3.5 避坑：AOF 相关的 4 个踩坑现场

• 现象：appendfsync everysec下，Redis 崩溃后丢失 2 秒数据，而非预期的 1 秒
  原因：everysec刷盘线程使用select()等待 1 秒，但若主线程在刷盘线程fdatasync前 0.999s 崩溃，缓冲区数据全丢；更糟的是，若系统负载高，刷盘线程可能被调度延迟，实际间隔达 1.5s
  解决：监控INFO persistence中aof_delayed_fsync（延迟刷盘次数），持续 >0 需扩容或调优内核调度

• 现象：BGREWRITEAOF执行中，INFO persistence显示aof_current_size暴涨 3 倍
  原因：rewrite 期间，所有新命令同时写入旧 AOF 和aof_rewrite_buf_blocks，而aof_current_size统计的是旧 AOF 文件大小，未包含内存缓冲区
  解决：用aof_base_size（rewrite 开始前大小）对比aof_current_size，若差值 >auto-aof-rewrite-min-size，说明 rewrite 未及时触发

• 现象：AOF 文件大小稳定在 1GB，但redis-check-aof报错 “Truncated AOF file”
  原因：文件系统缓存未刷盘，ls -l显示 1GB，但stat查看st_blocks发现实际分配块数不足，fdatasync失败导致文件元数据与内容不一致
  解决：echo 3 > /proc/sys/vm/drop_caches清缓存后重试；生产环境用 XFS 文件系统（对大文件更友好）

• 现象：开启aof-use-rdb-preamble yes后，redis-cli --bigkeys扫描变慢 5 倍
  原因：混合 AOF 加载时，Redis 需先解析 RDB 部分构建内存，再逐条执行 AOF 部分，--bigkeys在加载阶段无法统计，必须等全量加载完成才开始扫描
  解决：对大实例，禁用混合模式，用纯 AOF +redis-check-aof定期校验；或改用redis-cli --scan分批处理

4. 主从复制：repl-backlog 不是缓冲区，而是环形内存的生存游戏

Redis 主从复制常被理解为“master 写，slave 读”，但 PPT 中“主机会自动将数据同步到从机”掩盖了最关键的细节：同步不是实时管道，而是基于偏移量（offset）的异步追赶。repl-backlog（复制积压缓冲区）不是普通队列，而是一块固定大小的环形内存（默认 1MB），master 将所有写命令追加到其中，slave 通过PSYNC命令携带自己的offset请求增量数据。一旦 slave 断线重连，若offset仍在 backlog 中，即可部分同步（partial resync）；否则触发全量同步（full resync），代价巨大。这决定了你的网络抖动容忍度——不是“断几秒没关系”，而是“断多久 backlog 不会被覆盖”。

4.1 PSYNC 协议：如何用 offset 和 run_id 实现断点续传？

PSYNC是 Redis 2.8 引入的复制协议升级，取代旧SYNC。其握手流程如下：

1. Slave 发送PSYNC <run_id> <offset>

   • 若run_id为空或与 master 不匹配，或offset超出 backlog 范围，master 返回-FULLRESYNC <run_id> <offset>
   • 若匹配，master 返回+CONTINUE，并从offset开始发送 backlog 中的数据

2. Master 维护master_repl_offset（全局写偏移量）和repl_backlog_off（backlog 当前写入位置）

3. Backlog 是环形数组，repl_backlog_idx指向下一个写入位置，repl_backlog_histlen记录有效数据长度

关键点：repl_backlog_size固定，当histlen达上限，新数据覆盖最老数据。若 slave 断线时间t满足t > (repl_backlog_size / write_speed)，则必然丢失数据。

4.2 全量同步的三重开销：bgsave、网络传输、slave 加载

当PSYNC失败，master 触发BGSAVE生成 RDB，流程如下：

• Masterfork()子进程生成dump.rdb；
• Master 将 RDB 文件通过 socket 发送给 slave（阻塞主线程？否，由子进程发送）；
• Slave 接收 RDB 后，清空当前数据，加载 RDB（阻塞 slave 主线程）；
• 加载完成后，master 将bgsave启动后的新命令通过 backlog 或新连接发送给 slave。

这三步中，slave 加载 RDB 是最耗时环节。PPT 中“可以进行读写分离”隐含前提：slave 必须完成全量同步并追上 master，否则读取的是过期数据。

4.3 无磁盘复制：diskless replication 如何绕过本地文件？

Redis 2.8.18+ 支持repl-diskless-sync yes，启用后 master 不生成本地dump.rdb，而是fork()后直接将 RDB 数据通过 socket 发送给 slave。其优势是节省磁盘 IO，但风险是：若网络中断，整个 RDB 传输失败，需重来。源码中关键逻辑在replicationCron()：

// src/replication.c if (server.repl_diskless_sync && listLength(server.slaves) && server.repl_bg_save_scheduled) { // 不调用 rdbSaveBackground，改用 rioWriteBulkCount 等函数直接写 socket if (rdbSaveToSlavesSockets() == C_OK) { server.repl_bg_save_scheduled = 0; } }

提示：repl-diskless-sync-delay 5可设置延迟启动，等待更多 slave 加入，减少多次传输。

4.4 读写分离的幻觉：slave 的数据新鲜度由什么决定？

PPT 说“可以进行读写分离”，但未定义“可读”的标准。实际上，slave 的数据新鲜度取决于：

• repl_backlog_size与写入速率的比值；
• min-slaves-to-write 3和min-slaves-max-lag 10配置（master 拒绝写入，除非至少 3 个 slave 的 lag ≤10s）；
• slave 自身的slave-serve-stale-data yes/no（是否允许在同步中提供过期数据）。

若min-slaves-max-lag设为 5s，但网络抖动导致 slave lag 达 8s，master 将拒绝所有写命令——这正是“具备自动容错和恢复功能，主机从机的宕机都会导致前端部分读写请求失败”的底层机制。

4.5 避坑：主从复制相关的 4 个致命误区

• 现象：slave 的INFO replication显示master_link_status:up，但master_sync_in_progress:1持续 10 分钟
  原因：repl-diskless-sync yes且网络带宽不足（如 10Mbps），1GB RDB 传输需 13 分钟，期间 slave 无法提供服务
  解决：监控master_sync_left_bytes，若 >100MB 且传输慢，临时关闭 diskless sync；或用repl-diskless-sync-delay聚合多个 slave

• 现象：min-slaves-to-write 2配置下，两个 slave 断线，master 仍接受写入
  原因：min-slaves-to-write仅检查slave_list中repl_state == SLAVE_STATE_ONLINE的节点，若 slave 因网络分区被 master 标记为SLAVE_STATE_WAIT_BGSAVE_END，不计入统计
  解决：用redis-cli --cluster check定期验证集群状态；或改用哨兵模式自动故障转移

• 现象：slave 启动后，INFO replication的master_last_io_seconds_ago为 -1，且master_link_status为down
  原因：slave 配置了slaveof <master> 6379，但 master 的bind未包含 slave 所在网段，或防火墙拦截 6379 端口
  解决：在 master 执行CONFIG GET bind，确认绑定地址；用telnet <master_ip> 6379测试连通性

• 现象：PSYNC成功后，slave 的master_repl_offset追不上 master，lag 持续增长
  原因：slave 的repl-timeout 60过小，网络抖动时 master 未收到 slave 的 ACK，主动断开连接，触发新一轮PSYNC
  解决：增大repl-timeout至 300；或用tcp-keepalive 300保持连接活跃

5. Redis 命令的底层契约：为什么 INCR 比 GET+SET+SET 更可靠？

PPT 列出了大量命令，但未揭示一个核心事实：Redis 命令的可靠性不取决于语法，而取决于其是否在单个命令中完成原子状态变更。例如INCR key是原子的，因为它在 server.c 的incrCommand()中直接操作robj*，无中间状态；而GET key+SET key newval是两轮网络往返，中间可能被其他客户端修改。这解释了为何秒杀场景必须用DECR而非GET+SET——不是性能问题，而是正确性边界。更深层的是，Redis 的数据结构编码（encoding）直接影响命令行为：ziplist编码的 list 在元素少时内存紧凑，但LPOP可能触发ziplist到linkedlist的升级，带来不可预测的延迟。

5.1 原子性命令的实现：从 incrCommand 到内存操作

INCR命令的原子性源于其单次内存操作：

// src/t_string.c void incrCommand(client *c) { long long value; robj *o, *new; o = lookupKeyWrite(c->db,c->argv[1]); if (o != NULL && checkType(c,o,OBJ_STRING)) return; if (getLongLongFromObjectOrReply(c,o,&value,NULL) != C_OK) return; // 关键：直接修改对象，无中间变量 if ((new = createStringObjectFromLongLong(value+1)) == NULL) { addReplyError(c,"increment or decrement would overflow"); return; } dbReplaceValue(c->db,c->argv[1],new); addReply(c,shared.ok); }

对比GET+SET：

# 客户端 A GET stock # 返回 100 # 客户端 B 同时执行 DECR stock # stock 变为 99 # 客户端 A 继续 SET stock 99 # 覆盖为 99，但业务期望是 99（A）或 98（B），而非确定值

这就是 PPT 中“所有操作都是原子性的”真实含义：每个命令自身不可分割，但多个命令组合不构成事务。

5.2 数据结构编码：ziplist vs hashtable 的性能拐点

Redis 为节省内存，对小数据集采用特殊编码：

• hash默认用ziplist（紧凑数组），当hash-max-ziplist-entries 512且hash-max-ziplist-value 64满足时启用；
• list用ziplist，超过list-max-ziplist-size -2（-2 表示每个元素 ≤64 字节，总数不限）则转linkedlist；
• set用intset（整数集合），全为整数且元素 ≤512 时启用。

编码切换是透明的，但代价巨大：ziplist插入需内存移动，intset扩容需 realloc。PPT 中“数据结构丰富”背后是内存与 CPU 的权衡。

5.3 Lua 脚本：唯一能跨命令保证原子性的方案

当业务逻辑必须多步操作（如“扣库存+写订单+发消息”），MULTI/EXEC无法保证，唯一方案是 Lua 脚本：

-- stock_check.lua local stock = redis.call('GET', KEYS[1]) if tonumber(stock) > 0 then redis.call('DECR', KEYS[1]) redis.call('HSET', 'order:'..KEYS[2], 'status', 'paid') return 1 else return 0 end

EVAL脚本在 Redis 单线程中执行，期间无其他命令插入，真正实现业务原子性。PPT 未提 Lua，但它是解决“为什么 MULTI/EXEC 会丢数据”的终极答案。

5.4 避坑：命令层面的 4 个隐形陷阱

• 现象：KEYS *在 1000 万 key 的库中执行，导致 Redis 阻塞 30 秒
  原因：KEYS遍历整个 keyspace，O(N) 复杂度，且不支持游标
  解决：用SCAN 0 MATCH * COUNT 1000分批扫描；或为 key 命名加前缀（如user:1001:profile），用SCAN 0 MATCH user:*

• 现象：HGETALL返回 10 万个字段，客户端 OOM
  原因：HGETALL返回所有 field-value 对，结果集可能达 GB 级
  解决：用HSCAN分页；或拆分为HMGET key field1 field2 ...（最多 1000 字段）

• 现象：EXPIRE key 1后，TTL key返回 -2（key 不存在）而非 -1（永不过期）
  原因：EXPIRE执行时 key 已过期被自动删除，TTL查询不到该 key
  解决：用EXISTS key先检查 key 是否存在；或用PTTL key获取毫秒级 TTL

• 现象：SORT命令在大数据集上超时，CLIENT LIST显示 client 状态为idle
  原因：SORT是 O(N+M*log(M))，若 list 有 100 万元素，排序耗时远超timeout
  解决：禁用SORT，改用应用层排序；或用ZSET替代，利用有序集合天然排序

6. 持久化策略的选择：不是 RDB vs AOF，而是“你能承受多少秒的数据丢失”

我曾经在一个支付对账系统中，盲目相信 AOF 的everysec配置，认为“最多丢 1 秒数据”。上线后某次机房电力波动，Redis 进程崩溃，恢复时发现 3 秒内的 12 笔交易状态丢失，导致对账不平，人工核查耗时 8 小时。那次事故让我彻底抛弃“配置即安全”的幻想，转而追问三个问题：第一，我的业务能容忍多少秒的数据丢失？第二，我的写入模式是突发型（如日终批处理）还是匀速型（如实时订单）？第三，我的恢复时间目标（RTO）是多少？这三个问题的答案，直接决定你应该打开哪个开关。

6.1 用数学建模你的持久化风险

假设你的业务写入速率为Wops/s，RDBsave 60 1000，AOFeverysec，那么：

若W=1000，L=0.5s，则everysec实际丢失 1500 条，而always仅丢 1 条。这时always的写入延迟（约 1ms）远小于数据丢失成本。

6.2 混合持久化的实践阈值

我们团队为不同业务制定了混合策略：

本文还有配套的精品资源，点击获取