简介这份PPT面向希望系统掌握Redis的开发者与运维人员围绕内存数据结构存储的核心知识展开帮助读者建立从原理认知到配置实操的完整脉络。内容涵盖Redis的读写性能与原子性特点、string/hash/set/sorted set/list等数据结构、主从复制与读写分离机制并客观分析在线扩容困难、宕机影响部分读写等局限。配置部分逐项讲解redis.conf中端口、超时、守护进程、数据库数量等参数含义持久化部分对比RDB快照与AOF日志两种策略的核心配置、优缺点及适用场景命令部分梳理key管理与String操作的常用指令。资源包共1个pptx文件约1.59MB以幻灯片形式组织章节结构清晰便于课堂分享或自学翻阅。目前已有162人学习适合作为Redis入门梳理与团队内部分享的参考材料。1. 从一份 PPT 说起Redis 到底该在什么场景下用很多人第一次接触 Redis是从一份技术分享 PPT 开始的。我手头这份《Redis 分享.pptx》就是典型的一线分享材料——没有花哨的架构图堆砌而是把配置文件、持久化参数、五大数据结构的命令逐条列了出来。它解决的不是“Redis 是什么”这种科普问题而是“我拿到一台机器怎么把它配成能扛住生产流量的缓存服务”。适合谁适合已经会用redis-cli敲几个命令、但一遇到appendfsync该选everysec还是always就卡壳的开发者。这份材料的价值在于它把官方文档里散落在各页的参数按“配置—持久化—命令”三条线重新组织了一遍你照着改redis.conf就能跑起来。下面我按自己拆解这份 PPT 的顺序把能复现的部分和踩过的坑摊开讲。2. 配置文件与持久化redis.conf 里真正要动的就那几行2.1 先改这六个参数别一上来就调优拿到redis.conf别急着看几百行注释先定位这几个键。PPT 里列了port、timeout、daemonize、tcp-backlog、logfile、loglevel、databases我按实际部署顺序重新排一下优先级。# 只保留真正需要改的行其余用默认 port 6379 # 监听端口多实例部署时每个实例必须不同 daemonize yes # 后台运行生产环境必须开否则终端一关就挂 timeout 0 # 0 表示不断开空闲连接长连接场景保持 0 tcp-backlog 511 # 高并发下建议调到 1024配合 somaxconn 一起改 logfile /var/log/redis/redis.log # 空字符串会输出到 stdout后台运行时等于丢日志 loglevel notice # 生产用 notice排查问题临时切 verbose databases 16 # 默认 16 个库别指望用它做业务隔离逻辑说明daemonize yes和logfile必须成对出现。我见过有人只开了daemonize yes没配logfile结果进程起来了但日志全丢出问题只能靠redis-cli info猜。tcp-backlog单独调没用Linux 的net.core.somaxconn默认 128Redis 的 backlog 设再大也会被内核截断常见做法是两边一起调到 1024。databases 16这个参数要特别说一句很多人想用 0 号库放缓存、1 号库放 session但集群模式下只有 0 号库可用这个习惯趁早改掉。2.2 RDB 和 AOF 不是二选一是看你能丢多少数据PPT 把两种持久化的优缺点列得很清楚但落到配置上关键就一个问题宕机时你最多能接受丢几秒的数据。RDB 的核心配置是save策略AOF 的核心是appendfsync。# RDB 快照配置 save 60 1000 # 60 秒内 1000 次写就触发PPT 原值 stop-writes-on-bgsave-error no # 快照失败是否停止写入建议 no否则磁盘满会直接拒写 rdbcompression yes # 压缩快照CPU 换磁盘一般开 dbfilename dump.rdb # AOF 追加配置 appendonly yes appendfsync everysec # 每秒同步最多丢 1 秒生产首选 no-appendfsync-on-rewrite no auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb参数说明appendfsync三个值里always每条命令都刷盘性能掉得厉害除非你在做金融级对账否则别用no交给操作系统丢数据可能到几十秒everysec是折中也是 PPT 里默认推荐的。stop-writes-on-bgsave-error这个参数 PPT 写的是no我认同——设成yes时一旦bgsave因为磁盘满失败Redis 会直接拒绝所有写请求前端表现就是“缓存突然全挂”排查半天才发现是磁盘。auto-aof-rewrite-percentage 100配合min-size 64mb的意思是AOF 文件比上次重写后翻倍、且超过 64MB 才触发重写避免小文件频繁重写。提示RDB 的save策略和 AOF 可以同时开。常见做法是 RDB 做冷备比如每天凌晨的save 3600 1AOF 做实时兜底。但要注意fork子进程做快照时数据量大的实例会有明显卡顿PPT 里也提到了这点所以save的触发频率别设太密。2.3 用命令验证配置是否真的生效改完配置重启后别假设它生效了用CONFIG GET逐项核对。这一步很多人跳过结果线上跑的是旧配置。redis-cli CONFIG GET appendfsync redis-cli CONFIG GET save redis-cli CONFIG GET maxmemory redis-cli INFO persistence # 看 rdb_last_bgsave_status 和 aof_last_write_statusINFO persistence里的rdb_last_bgsave_status:ok和aof_last_write_status:ok是两个关键健康指标PPT 没展开但实际排查必看。如果rdb_last_bgsave_status是err基本就是磁盘权限或空间问题配合logfile里的报错能快速定位。3. 五大数据结构的命令选型别用错类型再谈性能3.1 String 和 Hash 的边界在哪PPT 把 String 和 Hash 的命令列得很全但没讲什么时候该用哪个。我的经验是单个对象字段少比如就一个计数、一个 token用 String对象字段多且需要单独读写某个字段用 Hash。# String计数器场景INCR 是原子操作 SET page:view:1001 0 INCR page:view:1001 INCRBY page:view:1001 10 GETRANGE page:view:1001 0 -1 # Hash用户信息只改某个字段不用整体覆盖 HSET user:1001 name A同学 age 24 HINCRBY user:1001 age 1 HMGET user:1001 name age HGETALL user:1001逻辑说明INCR的原子性是 Redis 单线程模型保证的PPT 里强调“所有操作都是原子性的”就是指这个多个客户端同时INCR不会丢计数。Hash 的HINCRBY同理适合做对象内某个数值字段的累加。这里有个坑HGETALL在字段很多时会阻塞字段超过几百个建议用HSCAN分批取PPT 在 Set 部分提了SSCANHash 的HSCAN是同一个道理。3.2 List 做队列、Set 做去重、Sorted Set 做排行这三个结构是面试高频但落到代码里选错的人不少。List 的LPUSHBRPOP是最简单的阻塞队列Set 的SADD天然去重Sorted Set 靠 score 排序做排行榜。# List简易任务队列BLPOP 阻塞等待 LPUSH task:queue job1 BLPOP task:queue 5 # 阻塞 5 秒取不到返回 nil # Set去重统计SADD 返回 1 表示新成员 SADD article:1001:likes user:1 SADD article:1001:likes user:1 # 返回 0已存在 SCARD article:1001:likes # Sorted Set排行榜ZADD 更新分数 ZADD rank:score 100 user:1 ZADD rank:score 200 user:2 ZREVRANGE rank:score 0 9 WITHSCORES参数说明BLPOP的 timeout 设 0 会永久阻塞生产环境建议设个几秒避免连接一直挂着。ZREVRANGE的0 9是取前 10 名WITHSCORES带上分数。PPT 里 Set 部分列了SDIFF、SINTER、SUNION做共同好友、标签交集很顺手但要注意大集合做交集运算会阻塞数据量大时用SINTERSTORE存结果再取。3.3 事务和发布订阅用之前先想清楚边界PPT 里MULTI/EXEC/WATCH这套事务命令和关系型数据库的事务不是一回事。Redis 事务只保证命令按顺序执行、不被其他客户端插队但某条命令失败不会回滚。MULTI SET balance:1001 100 INCR balance:1001 EXEC # 如果中间某条命令语法错误EXEC 时整批不执行 # 但如果是运行时错误比如对 String 做 LPUSH其他命令照样生效这个特性决定了 Redis 事务不能用来做“要么全成功要么全失败”的强一致场景。WATCH是乐观锁监视的 key 被改了就中断事务适合做简单的 CAS。发布订阅SUBSCRIBE/PUBLISH更要注意消息不持久化订阅者掉线期间的消息直接丢PPT 里说“可以用于简单的消息发送与订阅”关键词是“简单”别拿它当 Kafka 用。4. 避坑与排查这几处翻车我见过太多次4.1 现象缓存突然全部写入失败前端报错原因stop-writes-on-bgsave-error设成了yes默认值而bgsave因为磁盘满或权限问题失败Redis 进入拒写状态。解决先INFO persistence确认rdb_last_bgsave_status再看logfile里的具体报错临时恢复可以CONFIG SET stop-writes-on-bgsave-error no但根因是磁盘必须清理或扩容。4.2 现象AOF 文件越来越大重启恢复要十几分钟原因auto-aof-rewrite-percentage和min-size没配或者配得太大AOF 一直追加不重写。解决确认appendonly yes后把auto-aof-rewrite-min-size设到 64mb 左右percentage设 100让文件翻倍就重写同时检查no-appendfsync-on-rewrite重写期间如果还在同步刷盘会拖慢性能。4.3 现象KEYS *一执行整个实例卡住原因KEYS是 O(N) 全量扫描数据量大时阻塞单线程。PPT 里列了KEYS pattern但没强调风险。解决生产禁用KEYS改用SCAN cursor MATCH pattern COUNT 100分批迭代虽然不保证一次返回全部但不会阻塞。4.4 现象主从切换后从库数据比主库少一截原因主从复制是异步的PPT 里说“主机会自动将数据同步到从机”但同步有延迟主库宕机时未同步的写操作会丢。解决对一致性要求高的读走主库或者用WAIT命令等待指定数量的从库确认但WAIT会增加延迟按业务权衡。4.5 现象timeout 0配了连接还是被断开原因timeout 0只控制 Redis 服务端不主动断空闲连接但客户端连接池、中间层负载均衡、操作系统tcp_keepalive都可能断。解决检查客户端连接池的maxIdle和minEvictableIdleTime以及中间层的空闲超时别只盯着redis.conf。5. 进阶用 INFO 和慢查询日志把问题掐在萌芽期PPT 讲的是“怎么配、怎么用”但真正让 Redis 稳定跑下去的是持续观测。我一般会在实例上线后固定做两件事配慢查询日志、定期拉INFO关键指标。慢查询日志的配置在redis.conf里slowlog-log-slower-than 10000 # 超过 10ms 的命令记入慢查询单位微秒 slowlog-max-len 128 # 保留最近 128 条10000微秒就是 10 毫秒这个阈值对缓存服务来说已经偏宽松线上可以压到 5000。查的时候用SLOWLOG GET 10看最近 10 条重点看KEYS、HGETALL、大集合的SINTER这类命令有没有混进来。INFO里我固定看几个字段做成一张对照表字段含义异常信号used_memory_human已用内存接近maxmemory且频繁淘汰evicted_keys被淘汰的 key 数持续增长说明内存不够keyspace_hits/misses命中/未命中命中率骤降查缓存穿透connected_clients当前连接数接近maxclients要扩容instantaneous_ops_per_sec实时 QPS突增突降配合慢查询看这套组合拳的价值在于PPT 里给的读写性能数字读 110000 次/s、写 81000 次/s是理想压测值真实业务里 QPS 掉一半往往不是 Redis 本身的问题而是慢命令拖累了单线程。我习惯在每次改完redis.conf后先跑一轮redis-benchmark拿基线再挂上慢查询日志观察一天确认没有长尾命令才放心。从那以后我每次调整持久化参数或maxmemory策略都强制走一遍“改配置—CONFIG GET核对—INFO看指标—慢查询日志观察”这个流程省掉了很多半夜被叫起来排查的麻烦。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/28 11:33:59 · 阅读 1.2k Redis生产环境配置与持久化实战：从redis.conf到五大数据结构选型
简介这份PPT面向希望系统掌握Redis的开发者与运维人员围绕内存数据结构存储的核心知识展开帮助读者建立从原理认知到配置实操的完整脉络。内容涵盖Redis的读写性能与原子性特点、string/hash/set/sorted set/list等数据结构、主从复制与读写分离机制并客观分析在线扩容困难、宕机影响部分读写等局限。配置部分逐项讲解redis.conf中端口、超时、守护进程、数据库数量等参数含义持久化部分对比RDB快照与AOF日志两种策略的核心配置、优缺点及适用场景命令部分梳理key管理与String操作的常用指令。资源包共1个pptx文件约1.59MB以幻灯片形式组织章节结构清晰便于课堂分享或自学翻阅。目前已有162人学习适合作为Redis入门梳理与团队内部分享的参考材料。1. 从一份 PPT 说起Redis 到底该在什么场景下用很多人第一次接触 Redis是从一份技术分享 PPT 开始的。我手头这份《Redis 分享.pptx》就是典型的一线分享材料——没有花哨的架构图堆砌而是把配置文件、持久化参数、五大数据结构的命令逐条列了出来。它解决的不是“Redis 是什么”这种科普问题而是“我拿到一台机器怎么把它配成能扛住生产流量的缓存服务”。适合谁适合已经会用redis-cli敲几个命令、但一遇到appendfsync该选everysec还是always就卡壳的开发者。这份材料的价值在于它把官方文档里散落在各页的参数按“配置—持久化—命令”三条线重新组织了一遍你照着改redis.conf就能跑起来。下面我按自己拆解这份 PPT 的顺序把能复现的部分和踩过的坑摊开讲。2. 配置文件与持久化redis.conf 里真正要动的就那几行2.1 先改这六个参数别一上来就调优拿到redis.conf别急着看几百行注释先定位这几个键。PPT 里列了port、timeout、daemonize、tcp-backlog、logfile、loglevel、databases我按实际部署顺序重新排一下优先级。# 只保留真正需要改的行其余用默认 port 6379 # 监听端口多实例部署时每个实例必须不同 daemonize yes # 后台运行生产环境必须开否则终端一关就挂 timeout 0 # 0 表示不断开空闲连接长连接场景保持 0 tcp-backlog 511 # 高并发下建议调到 1024配合 somaxconn 一起改 logfile /var/log/redis/redis.log # 空字符串会输出到 stdout后台运行时等于丢日志 loglevel notice # 生产用 notice排查问题临时切 verbose databases 16 # 默认 16 个库别指望用它做业务隔离逻辑说明daemonize yes和logfile必须成对出现。我见过有人只开了daemonize yes没配logfile结果进程起来了但日志全丢出问题只能靠redis-cli info猜。tcp-backlog单独调没用Linux 的net.core.somaxconn默认 128Redis 的 backlog 设再大也会被内核截断常见做法是两边一起调到 1024。databases 16这个参数要特别说一句很多人想用 0 号库放缓存、1 号库放 session但集群模式下只有 0 号库可用这个习惯趁早改掉。2.2 RDB 和 AOF 不是二选一是看你能丢多少数据PPT 把两种持久化的优缺点列得很清楚但落到配置上关键就一个问题宕机时你最多能接受丢几秒的数据。RDB 的核心配置是save策略AOF 的核心是appendfsync。# RDB 快照配置 save 60 1000 # 60 秒内 1000 次写就触发PPT 原值 stop-writes-on-bgsave-error no # 快照失败是否停止写入建议 no否则磁盘满会直接拒写 rdbcompression yes # 压缩快照CPU 换磁盘一般开 dbfilename dump.rdb # AOF 追加配置 appendonly yes appendfsync everysec # 每秒同步最多丢 1 秒生产首选 no-appendfsync-on-rewrite no auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb参数说明appendfsync三个值里always每条命令都刷盘性能掉得厉害除非你在做金融级对账否则别用no交给操作系统丢数据可能到几十秒everysec是折中也是 PPT 里默认推荐的。stop-writes-on-bgsave-error这个参数 PPT 写的是no我认同——设成yes时一旦bgsave因为磁盘满失败Redis 会直接拒绝所有写请求前端表现就是“缓存突然全挂”排查半天才发现是磁盘。auto-aof-rewrite-percentage 100配合min-size 64mb的意思是AOF 文件比上次重写后翻倍、且超过 64MB 才触发重写避免小文件频繁重写。提示RDB 的save策略和 AOF 可以同时开。常见做法是 RDB 做冷备比如每天凌晨的save 3600 1AOF 做实时兜底。但要注意fork子进程做快照时数据量大的实例会有明显卡顿PPT 里也提到了这点所以save的触发频率别设太密。2.3 用命令验证配置是否真的生效改完配置重启后别假设它生效了用CONFIG GET逐项核对。这一步很多人跳过结果线上跑的是旧配置。redis-cli CONFIG GET appendfsync redis-cli CONFIG GET save redis-cli CONFIG GET maxmemory redis-cli INFO persistence # 看 rdb_last_bgsave_status 和 aof_last_write_statusINFO persistence里的rdb_last_bgsave_status:ok和aof_last_write_status:ok是两个关键健康指标PPT 没展开但实际排查必看。如果rdb_last_bgsave_status是err基本就是磁盘权限或空间问题配合logfile里的报错能快速定位。3. 五大数据结构的命令选型别用错类型再谈性能3.1 String 和 Hash 的边界在哪PPT 把 String 和 Hash 的命令列得很全但没讲什么时候该用哪个。我的经验是单个对象字段少比如就一个计数、一个 token用 String对象字段多且需要单独读写某个字段用 Hash。# String计数器场景INCR 是原子操作 SET page:view:1001 0 INCR page:view:1001 INCRBY page:view:1001 10 GETRANGE page:view:1001 0 -1 # Hash用户信息只改某个字段不用整体覆盖 HSET user:1001 name A同学 age 24 HINCRBY user:1001 age 1 HMGET user:1001 name age HGETALL user:1001逻辑说明INCR的原子性是 Redis 单线程模型保证的PPT 里强调“所有操作都是原子性的”就是指这个多个客户端同时INCR不会丢计数。Hash 的HINCRBY同理适合做对象内某个数值字段的累加。这里有个坑HGETALL在字段很多时会阻塞字段超过几百个建议用HSCAN分批取PPT 在 Set 部分提了SSCANHash 的HSCAN是同一个道理。3.2 List 做队列、Set 做去重、Sorted Set 做排行这三个结构是面试高频但落到代码里选错的人不少。List 的LPUSHBRPOP是最简单的阻塞队列Set 的SADD天然去重Sorted Set 靠 score 排序做排行榜。# List简易任务队列BLPOP 阻塞等待 LPUSH task:queue job1 BLPOP task:queue 5 # 阻塞 5 秒取不到返回 nil # Set去重统计SADD 返回 1 表示新成员 SADD article:1001:likes user:1 SADD article:1001:likes user:1 # 返回 0已存在 SCARD article:1001:likes # Sorted Set排行榜ZADD 更新分数 ZADD rank:score 100 user:1 ZADD rank:score 200 user:2 ZREVRANGE rank:score 0 9 WITHSCORES参数说明BLPOP的 timeout 设 0 会永久阻塞生产环境建议设个几秒避免连接一直挂着。ZREVRANGE的0 9是取前 10 名WITHSCORES带上分数。PPT 里 Set 部分列了SDIFF、SINTER、SUNION做共同好友、标签交集很顺手但要注意大集合做交集运算会阻塞数据量大时用SINTERSTORE存结果再取。3.3 事务和发布订阅用之前先想清楚边界PPT 里MULTI/EXEC/WATCH这套事务命令和关系型数据库的事务不是一回事。Redis 事务只保证命令按顺序执行、不被其他客户端插队但某条命令失败不会回滚。MULTI SET balance:1001 100 INCR balance:1001 EXEC # 如果中间某条命令语法错误EXEC 时整批不执行 # 但如果是运行时错误比如对 String 做 LPUSH其他命令照样生效这个特性决定了 Redis 事务不能用来做“要么全成功要么全失败”的强一致场景。WATCH是乐观锁监视的 key 被改了就中断事务适合做简单的 CAS。发布订阅SUBSCRIBE/PUBLISH更要注意消息不持久化订阅者掉线期间的消息直接丢PPT 里说“可以用于简单的消息发送与订阅”关键词是“简单”别拿它当 Kafka 用。4. 避坑与排查这几处翻车我见过太多次4.1 现象缓存突然全部写入失败前端报错原因stop-writes-on-bgsave-error设成了yes默认值而bgsave因为磁盘满或权限问题失败Redis 进入拒写状态。解决先INFO persistence确认rdb_last_bgsave_status再看logfile里的具体报错临时恢复可以CONFIG SET stop-writes-on-bgsave-error no但根因是磁盘必须清理或扩容。4.2 现象AOF 文件越来越大重启恢复要十几分钟原因auto-aof-rewrite-percentage和min-size没配或者配得太大AOF 一直追加不重写。解决确认appendonly yes后把auto-aof-rewrite-min-size设到 64mb 左右percentage设 100让文件翻倍就重写同时检查no-appendfsync-on-rewrite重写期间如果还在同步刷盘会拖慢性能。4.3 现象KEYS *一执行整个实例卡住原因KEYS是 O(N) 全量扫描数据量大时阻塞单线程。PPT 里列了KEYS pattern但没强调风险。解决生产禁用KEYS改用SCAN cursor MATCH pattern COUNT 100分批迭代虽然不保证一次返回全部但不会阻塞。4.4 现象主从切换后从库数据比主库少一截原因主从复制是异步的PPT 里说“主机会自动将数据同步到从机”但同步有延迟主库宕机时未同步的写操作会丢。解决对一致性要求高的读走主库或者用WAIT命令等待指定数量的从库确认但WAIT会增加延迟按业务权衡。4.5 现象timeout 0配了连接还是被断开原因timeout 0只控制 Redis 服务端不主动断空闲连接但客户端连接池、中间层负载均衡、操作系统tcp_keepalive都可能断。解决检查客户端连接池的maxIdle和minEvictableIdleTime以及中间层的空闲超时别只盯着redis.conf。5. 进阶用 INFO 和慢查询日志把问题掐在萌芽期PPT 讲的是“怎么配、怎么用”但真正让 Redis 稳定跑下去的是持续观测。我一般会在实例上线后固定做两件事配慢查询日志、定期拉INFO关键指标。慢查询日志的配置在redis.conf里slowlog-log-slower-than 10000 # 超过 10ms 的命令记入慢查询单位微秒 slowlog-max-len 128 # 保留最近 128 条10000微秒就是 10 毫秒这个阈值对缓存服务来说已经偏宽松线上可以压到 5000。查的时候用SLOWLOG GET 10看最近 10 条重点看KEYS、HGETALL、大集合的SINTER这类命令有没有混进来。INFO里我固定看几个字段做成一张对照表字段含义异常信号used_memory_human已用内存接近maxmemory且频繁淘汰evicted_keys被淘汰的 key 数持续增长说明内存不够keyspace_hits/misses命中/未命中命中率骤降查缓存穿透connected_clients当前连接数接近maxclients要扩容instantaneous_ops_per_sec实时 QPS突增突降配合慢查询看这套组合拳的价值在于PPT 里给的读写性能数字读 110000 次/s、写 81000 次/s是理想压测值真实业务里 QPS 掉一半往往不是 Redis 本身的问题而是慢命令拖累了单线程。我习惯在每次改完redis.conf后先跑一轮redis-benchmark拿基线再挂上慢查询日志观察一天确认没有长尾命令才放心。从那以后我每次调整持久化参数或maxmemory策略都强制走一遍“改配置—CONFIG GET核对—INFO看指标—慢查询日志观察”这个流程省掉了很多半夜被叫起来排查的麻烦。希望帮到你。本文还有配套的精品资源点击获取