简介这份PPT面向后端开发、运维及缓存技术学习者系统梳理Redis的核心知识体系帮助读者快速建立从原理到配置的完整认知。内容涵盖Redis高性能读写特性、string/hash/set/sorted set/list等数据结构、原子性操作与主从复制机制并客观分析在线扩容困难、宕机影响读写等局限。配置部分详解redis.conf中端口、超时、守护进程、数据库数量等关键参数持久化部分对比RDB快照与AOF日志两种策略的配置项、优缺点及适用场景命令部分整理key操作与String类型常用指令便于日常数据管理。资源包为1个pptx文件大小约1.59MB结构紧凑适合培训分享或自学参考。目前已有161人学习可作为Redis入门与知识梳理的轻量级资料。1. 从一份 Redis 分享 PPT 说起为什么我劝你先别急着敲命令很多人第一次搭 Redis 环境都是被一份技术分享 PPT 或者同事丢过来的一句“装个 Redis 就行”带进坑的。我见过太多人上来就yum install redis装完发现版本是 3.x配置文件路径找不到持久化策略默认 RDB结果重启机器数据全丢回头排查半天才发现是daemonize没开、appendonly没改。Redis 这东西看着简单一个二进制文件加一个redis.conf就能跑但真正要把它装到能稳定对外服务中间隔着版本选择、持久化取舍、主从同步配置这几道坎。这份《Redis 分享.pptx》把简介、配置、持久化、命令、事务、发布订阅都串了一遍我打算按它的脉络把“装什么版本、怎么改配置、坏了怎么救”这条线重新走一遍适合刚接手缓存服务、或者想把 Redis 从单机玩到主从的开发者照着落地。2. 装前定版本与目录Redis 6.x 还是 7.x路径怎么规划2.1 版本选择别用系统源里的老版本系统包管理器里的 Redis 版本普遍偏旧CentOS 默认源经常停在 3.2 或者 5.0而这份 PPT 里提到的appendfsync everysec、auto-aof-rewrite-percentage这些参数在 6.x 之后行为更稳定主从同步的replicaof指令也是 5.0 才正式替代slaveof。我一般会选 Redis 6.2 或者 7.0 的稳定版6.2 对多线程 IO 的支持已经成熟7.0 在 AOF 重写和集群管理上更顺手。如果你只是本地做 Demo6.2 足够如果要上生产直接 7.0 起步省得后面为了ACL或者shutdown-timeout再折腾升级。提示不要用apt install redis或yum install redis直接装版本不可控配置文件路径也和你预期的不一样。2.2 目录规划源码编译安装的固定套路我习惯把 Redis 装在/usr/local/redis下源码包放/usr/local/src数据目录单独挂一块盘或者放到/data/redis日志放/var/log/redis。这样做的原因是 Redis 的 RDB 和 AOF 文件会随着时间变大如果跟系统盘混在一起哪天磁盘写满Redis 直接拒绝写入前端缓存雪崩就来了。下面是我常用的编译安装步骤以 Redis 7.0.15 为例# 安装编译依赖gcc 和 make 是必须的 yum install -y gcc make jemalloc-devel # 下载源码包放到 /usr/local/src cd /usr/local/src wget https://download.redis.io/releases/redis-7.0.15.tar.gz # 解压并进入目录 tar -zxvf redis-7.0.15.tar.gz cd redis-7.0.15 # 编译并指定安装路径USE_SYSTEMDyes 方便后面用 systemctl 管理 make PREFIX/usr/local/redis USE_SYSTEMDyes install # 创建配置、数据和日志目录 mkdir -p /usr/local/redis/conf mkdir -p /data/redis/{data,logs}这段命令里PREFIX决定了redis-server、redis-cli这些可执行文件装到哪USE_SYSTEMDyes会生成 systemd 单元文件省得自己写启动脚本。jemalloc-devel是 Redis 默认的内存分配器不装的话编译会报错或者退回到 libc性能有差异。编译完成后/usr/local/redis/bin下会有redis-server、redis-cli、redis-benchmark等工具redis.conf需要从源码目录复制到/usr/local/redis/conf下再改。2.3 配置文件初始化从模板到可运行复制配置文件并做最小改动cp /usr/local/src/redis-7.0.15/redis.conf /usr/local/redis/conf/redis.conf # 编辑配置文件改这几个关键项 vim /usr/local/redis/conf/redis.conf需要改的项包括daemonize yes让 Redis 后台运行pidfile /var/run/redis_6379.pid指定 PID 文件logfile /data/redis/logs/redis.log把日志从标准输出挪到文件dir /data/redis/data指定 RDB 和 AOF 的落盘目录。这几项不改Redis 要么前台阻塞终端要么日志散落在启动目录出问题根本找不到线索。3. 配置持久化与主从RDB 和 AOF 到底怎么选3.1 RDB 配置快照的触发条件和压缩PPT 里列了 RDB 的核心配置我按生产习惯重新过一遍。save 60 1000表示 60 秒内有 1000 次写操作就触发一次快照这个值看业务写入量调写入频繁可以改成save 300 10000减少 fork 次数。stop-writes-on-bgsave-error no我一般设成no因为磁盘满导致快照失败时如果还继续写数据一致性更难保证不如让 Redis 停止写入等运维介入。rdbcompression yes开启压缩CPU 换磁盘空间数据量大时值得。dbfilename dump.rdb保持默认但dir一定要指到独立数据盘。# 在 redis.conf 中定位并修改 save 300 10000 stop-writes-on-bgsave-error no rdbcompression yes dbfilename dump.rdb dir /data/redis/data改完这些RDB 快照会写到/data/redis/data/dump.rdb恢复时只要把这个文件放到dir目录下启动 Redis 就会自动加载。注意stop-writes-on-bgsave-error设成no之后快照失败不会阻塞写入但你要有监控盯着rdb_last_bgsave_status这个指标否则数据丢了都不知道。3.2 AOF 配置追加策略和重写阈值AOF 是 PPT 里重点讲的另一种持久化方式appendonly yes开启后每条写命令都会追加到appendonly.aof文件。appendfsync everysec是折中方案每秒同步一次磁盘最多丢 1 秒数据always每条命令都同步性能差但最安全no交给操作系统决定不建议生产用。no-appendfsync-on-rewrite no表示在 AOF 重写期间仍然执行 fsync避免重写时数据丢失但可能引起阻塞。auto-aof-rewrite-percentage 100和auto-aof-rewrite-min-size 64mb配合使用当前 AOF 文件比上次重写后大一倍且超过 64MB 时才触发重写防止小文件频繁重写。appendonly yes appendfsync everysec no-appendfsync-on-rewrite no auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb我一般会同时开 RDB 和 AOFRDB 用于定期备份和快速恢复AOF 用于保证数据完整性。如果只能选一个缓存场景用 RDB数据不能丢的场景用 AOF。PPT 里也提到 AOF 文件体积通常大于 RDB恢复时间长所以定期做BGREWRITEAOF或者靠自动重写来控制体积。3.3 主从同步配置从slaveof到replicaofPPT 里提到 Redis 实现了 master-slave 同步可以读写分离。在 5.0 之后slaveof命令改成了replicaof配置文件里也建议用新写法。从节点配置# 在从节点的 redis.conf 中添加 replicaof 192.168.1.100 6379 masterauth your_master_password replica-read-only yesreplicaof指定主节点 IP 和端口masterauth是主节点密码replica-read-only yes让从节点只读防止误写导致主从数据不一致。主节点如果设了requirepass从节点必须配masterauth否则同步会报NOAUTH错误。同步建立后从节点会先做一次全量同步然后增量同步INFO replication里能看到master_link_status:up才算正常。注意主从同步第一次全量同步时主节点会 fork 子进程生成 RDB 并发送给从节点这段时间主节点内存占用会上升数据量大时要在低峰期操作。4. 避坑与排查装 Redis 时最容易翻车的五个点4.1 启动报错Creating Server TCP listening socket *:6379: bind: Address already in use现象是redis-server启动直接退出日志里提示端口被占用。原因通常是之前启动的 Redis 没关干净或者系统里已经有别的服务占了 6379。解决方法是lsof -i:6379或ss -lntp | grep 6379找到进程确认是旧 Redis 就kill掉再重新启动。如果确实需要换端口改redis.conf里的port项同时记得防火墙和客户端配置一起改。4.2 后台运行没生效终端一关 Redis 就停现象是daemonize明明设了yes但关闭 SSH 后 Redis 进程消失。原因多半是启动时没有指定配置文件redis-server默认读的是当前目录下的redis.conf如果你直接./redis-server而不带路径它用的是内置默认配置daemonize是no。解决方法是启动命令写全/usr/local/redis/bin/redis-server /usr/local/redis/conf/redis.conf或者用 systemd 管理。4.3 AOF 文件损坏导致启动失败现象是 Redis 启动日志里出现Bad file format reading the append only file然后进程退出。原因通常是机器突然断电或者磁盘写满AOF 文件最后一条命令写了一半。解决方法是先用redis-check-aof --fix appendonly.aof修复它会截断不完整的命令然后重新启动。如果修复后数据对不上只能从 RDB 备份恢复所以 RDB 和 AOF 同时开是有必要的。4.4 主从同步一直master_link_status:down现象是从节点INFO replication里看到主从连接断开日志报Unable to connect to MASTER或者NOAUTH。原因可能是主节点防火墙没放行 6379、masterauth密码不对、或者主节点bind只监听了 127.0.0.1。解决方法是检查主节点bind配置改成0.0.0.0或内网 IP确认requirepass和masterauth一致防火墙放行端口。如果主节点有多个从节点还要看repl-backlog-size是否够大太小会导致增量同步失败反复全量同步。4.5 内存满了导致写入失败现象是客户端报OOM command not allowed when used memory maxmemory。原因是 Redis 设了maxmemory但没设淘汰策略或者淘汰策略不适合业务。解决方法是根据业务选maxmemory-policy缓存场景用allkeys-lru持久化数据用noeviction并加监控。改完策略后CONFIG SET maxmemory-policy allkeys-lru可以热生效但最好写进配置文件重启不丢。5. 装完怎么验证从redis-cli到主从切换的完整检查装完 Redis 不是redis-cli ping返回PONG就完事了我一般会走一遍下面这套验证流程确保配置真正生效、持久化能恢复、主从能切换。5.1 基础连通性和配置核对先用redis-cli连上去确认端口、密码、数据库数量# 连接 Redis如果有密码加 -a redis-cli -h 127.0.0.1 -p 6379 # 在交互界面里执行 127.0.0.1:6379 PING PONG 127.0.0.1:6379 CONFIG GET daemonize 1) daemonize 2) yes 127.0.0.1:6379 CONFIG GET appendonly 1) appendonly 2) yes 127.0.0.1:6379 INFO server | grep redis_version redis_version:7.0.15CONFIG GET能直接读到运行时配置确认daemonize和appendonly是你改过的值。INFO server看版本确保不是系统源里的老版本。如果CONFIG GET返回空说明配置文件没加载对回去检查启动命令。5.2 持久化验证写数据、重启、读数据这一步是很多人忽略的。写一个 key然后重启 Redis看数据还在不在# 写入测试数据 127.0.0.1:6379 SET verify_key persistence_test OK 127.0.0.1:6379 BGSAVE Background saving started # 退出并重启 Redis 127.0.0.1:6379 SHUTDOWN # 重新启动 /usr/local/redis/bin/redis-server /usr/local/redis/conf/redis.conf # 再次连接读取 redis-cli -h 127.0.0.1 -p 6379 127.0.0.1:6379 GET verify_key persistence_test如果GET返回nil说明 RDB 或 AOF 没生效检查dir目录下有没有dump.rdb或appendonly.aof文件以及appendonly是否真的设成了yes。AOF 开启后BGSAVE不是必须的但重启前手动触发一次能确保 RDB 也是最新的。5.3 主从同步验证和手动切换在主节点写入从节点能读到说明同步正常# 主节点写入 127.0.0.1:6379 SET sync_test from_master OK # 从节点读取 127.0.0.1:6380 GET sync_test from_master # 查看从节点同步状态 127.0.0.1:6380 INFO replication role:slave master_host:192.168.1.100 master_port:6379 master_link_status:upmaster_link_status:up是关键down就回去查第 4.4 节的排查步骤。手动切换时在从节点执行REPLICAOF NO ONE提升为主节点然后改其他从节点的replicaof指向新主节点。生产环境建议用哨兵或者集群但单机主从先把这个流程走通后面上哨兵心里有底。5.4 性能基线用redis-benchmark跑一轮PPT 里提到读 110000 次/s、写 81000 次/s这个数字和机器配置强相关。装完后跑一轮 benchmark心里有个底# 50 个并发客户端每个发 10000 个请求只测 SET 和 GET redis-benchmark -h 127.0.0.1 -p 6379 -c 50 -n 10000 -t set,get -q输出里SET和GET的requests per second就是当前机器的实际吞吐。如果远低于 PPT 里的数字检查是不是开了 AOFalways、有没有其他进程抢 CPU、或者网络延迟高。这个基线数据记下来以后线上变慢时有个对比。从那以后我每次装完 Redis都会强制走一遍“写数据 → 重启 → 读数据 → 主从同步 → benchmark”这套流程少一步都可能在上线后还债。希望帮到你。本文还有配套的精品资源点击获取