核心内容摘要
娜娜台北nana洗衣机：让居家生活焕然一新，洗净烦恼的秘密武器！
在讲核心内容前先定一个前提Redis是纯内存数据库数据都存在内存里一旦Redis重启/服务器断电内存数据会直接消失。
持久化就是Redis把内存数据“存到硬盘文件里”的操作目的是重启后能恢复数据而AOF和RDB就是Redis实现持久化的两种核心方式就像我们平时保存文件的两种不同方法。
先搞懂Redis的RDB持久化快照式持久化
给内存数据“拍张完整照片”把Redis的内存想象成你的手机相册RDB就相当于定时给相册拍一张完整的截图把截图保存到硬盘里。
拍照的瞬间相册里有多少照片、每张照片在哪截图里都完整记录拍照后你再往相册里加/删照片不会影响之前的截图要是手机丢了Redis重启/断电用最近的那张截图RDB文件就能恢复出拍照瞬间的所有照片数据。
官方定义RDB是快照式持久化Redis会在指定的时间条件下将当前内存中的所有数据以二进制压缩格式生成一个单一的RDB文件恢复时直接加载这个文件到内存即可。
核心特点优点文件是二进制压缩的体积极小恢复数据时直接加载整文件速度极快不用执行命令直接读数据缺点只有“拍照瞬间”的数据拍照后到崩溃前的新数据会丢失比如5分钟拍一次照刚拍过照1分钟就崩了这1分钟的数据没了
再搞懂Redis的AOF持久化日志式持久化
通俗理解给所有写操作“记流水账”还是把Redis内存想象成手机相册AOF就相当于给你的每一次相册操作记流水账把“新增1张照片”“删除第3张照片”“修改照片名称”这些所有写操作按顺序一字不差地写到硬盘的日志文件里。
你做的每一个修改操作都会立刻/定时记到流水账里只记写操作查操作不记流水账是追加写只在文件末尾加内容从不改之前的记录不会丢历史要是手机丢了Redis重启后会从头执行流水账里的所有命令一步步还原出最新的相册状态数据。
官方定义通俗翻译AOF是日志式持久化Redis会把所有对数据的写命令set/hset/del等按执行顺序以明文文本格式追加到AOF文件中恢复时通过“重放”这些命令重建内存数据。
关键补充AOF重写解决流水账太长的问题如果一直记流水账文件会越来越大比如你反复修改一个key流水账会记几十次修改命令但其实只需要最后一次的结果。
Redis的AOF重写就是Redis会根据当前内存的最新数据重新生成一个最简的AOF文件只保留能还原当前数据的必要命令删掉冗余命令比如反复修改key的命令只留最后一次set相当于“把厚厚的流水账精简成一页核心账单”不丢失数据但大幅减小文件体积。
核心特点优点按命令记录数据丢失极少可配置每秒/每次操作记日志文件是明文命令能直接看懂、甚至手动修改比如删了错的del命令缺点明文文本格式文件体积比RDB大很多恢复时要逐行执行命令速度比RDB慢
实操修改Redis配置生成文件看直观区别Redis的配置文件默认叫redis.confLinux下默认在/etc/redis/Windows下和Redis启动文件同目录实操前先停掉Redis服务避免配置修改不生效Linux停服务命令systemctl stop redis。
前置Redis默认配置RDB默认开启不用改配置就能生成RDB文件AOF默认关闭需要手动改配置开启。
步骤1修改RDB核心配置redis.conf里找对应配置改完保存#
触发RDB的条件【时间窗口】内有【指定数量的写操作】可配多个注释掉就是关闭自动RDB # 意思900秒15分钟内至少1个写操作就自动生成RDB300秒5分钟内至少10个60秒内至少1000个 save 900 1 save 300 10 save 60 1000 #
RDB文件的名字默认dump.rdb可自定义后缀建议保留.rdb dbfilename dump.rdb #
RDB/AOF文件的存储目录所有持久化文件都放这里必须是绝对路径Linux默认./表示Redis启动目录 dir /var/lib/redis # 建议改绝对路径方便找Linux下这个目录是Redis默认数据目录步骤2修改AOF核心配置开启AOF配置关键参数#
开启AOF默认no改成yes就是开启这是AOF的核心开关 appendonly yes #
AOF文件的名字默认appendonly.aof可自定义后缀建议保留.aof appendfilename appendonly.aof #
【关键】AOF日志的刷盘策略决定数据丢失的多少选everysec就够了Redis默认 # 三个选项 # always每执行一个写命令立刻把日志写到硬盘数据几乎不丢但性能最差频繁写硬盘 # everysec每秒把日志写到硬盘一次折中方案最多丢1秒数据性能和安全性平衡 # no把日志交给操作系统管理操作系统什么时候写硬盘Redis不管性能最好丢数据最多 appendfsync everysec #
AOF重写的自动触发条件默认开启不用改 # 意思AOF文件体积比上次重写后增大100%且文件体积至少64M时自动触发重写 auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb步骤3重启Redis生成持久化文件重启Redis服务systemctl start redisLinuxWindows直接双击Redis启动文件连接Redis客户端redis-cli执行几个写操作触发RDB生成AOF日志set name 张三 hset user id 1 age 20 del test # 随便加个删操作看AOF会不会记录手动触发RDB生成不用等定时条件立刻生成在Redis客户端执行bgsave后台生成不阻塞Redis手动触发AOF重写可选看精简后的AOF在Redis客户端执行bgrewriteaof后台重写不阻塞Redis。
步骤4找到文件看直观区别先查Redis持久化文件的存储目录对应配置里的dir执行redis-cli config get dir就能看到绝对路径比如结果是/var/lib/redis进入这个目录cd /var/lib/redis然后用ls就能看到生成的文件dump.rdb和appendonly.aof。
用Linux命令看文件内容区别一眼看穿查看RDB文件cat dump.rdb结果全是乱码二进制压缩格式人类看不懂用ls -lh看体积极小比如执行了3个写操作文件大小可能只有几十字节。
查看AOF文件cat appendonly.aof结果明文Redis命令人类能直接看懂格式是Redis的协议格式核心命令能一眼识别比如能看到set name 张
hset user id
del test这些操作用ls -lh看体积比RDB大很多比如同样3个写操作AOF文件可能有几百字节。
核心文件区别
总结直观版特性RDB文件AOF文件格式二进制压缩明文文本Redis协议体积极小较大重写后会变小可读性人类完全看不懂人类能看懂、可手动修改记录内容某一时刻的全量数据所有写操作的顺序日志
和MySQL的binlog/redolog对比先明确一个前提MySQL是磁盘数据库数据默认存在硬盘但为了速度会把常用数据加载到内存所以MySQL的日志binlog/redolog和Redis的持久化文件设计目的不同但核心思想有相似之处先通俗讲清楚MySQL的binlog和redolog再对比。
先搞懂MySQL的binlog和redolog把MySQL的硬盘数据想象成公司的纸质账本内存想象成会计的电脑账本会计做账的规则是先改电脑账本再定期同步到纸质账本因为改电脑快改纸质慢。
redolog重做日志InnoDB引擎独有相当于会计的【临时便签】作用防止会计改了电脑账本还没同步到纸质账本突然停电MySQL崩溃电脑数据丢了纸质账本还是旧的。
会计每改一次电脑账本就立刻在便签上记一句“改了哪一页纸的哪一行”就算停电恢复后看便签就能把纸质账本改成最新的核心特点循环写便签纸就那么大写满了就从头覆盖旧的、物理日志记录“硬盘的哪个数据页改了什么”和硬盘物理存储关联、保证事务持久性MySQL的ACID中D的核心只记“修改操作”不记查询且只保留最近的修改循环覆盖。
binlog归档日志MySQL服务器层日志所有引擎都支持相当于公司的【正式记账流水】作用记录公司所有的“记账操作”不管是改、删、加都按顺序记下来永久保存不会自动覆盖用于数据恢复和主从复制从库跟着主库的binlog执行相同操作保持数据一致核心特点追加写只在流水本末尾加内容从不改之前的记录、逻辑日志记录“做了什么操作”比如update user set age20 where id1和硬盘物理存储无关、全量写操作记录核心对比Redis(AOF/RDB) vs MySQL(binlog/redolog)
最核心的对应关系记死这个永远不混Redis RDB ≈ MySQL的【全量备份】比如mysqldump/xtrabackup都不是日志是某一时刻的全量数据快照恢复快体积小丢数据多Redis AOF ≈ MySQL的binlog都是追加写的逻辑日志记录所有写操作用于数据恢复体积大恢复慢丢数据少
关键区别Redis没有“类似MySQL redolog”的东西原因很简单设计思想不同MySQL用的是WAL写前日志先写redolog便签再改内存最后定期同步到硬盘核心是保证崩溃后数据不丢即使内存数据丢了用redolog恢复Redis是内存优先先改内存操作立刻返回成功再异步把数据/命令写到硬盘RDB/AOF核心是保证性能Redis的核心优势就是快所以Redis不需要redolog这种“崩溃恢复临时日志”——就算持久化还没写内存数据丢了最多丢一点最新数据这是Redis为了性能做的取舍。
一张表讲清所有核心区别特性Redis RDBRedis AOFMySQL redologMySQL binlog设计目的全量数据备份记录所有写操作崩溃恢复归档/主从/恢复写入方式定时覆盖生成追加写循环写追加写日志类型非日志快照逻辑日志物理日志逻辑日志引擎依赖Redis通用Redis通用仅InnoDBMySQL所有引擎可读性无有明文无二进制有可解析数据丢失较多快照间隔极少秒级/实时几乎无极少
和Git的log文件对比Git是版本控制系统核心是记录项目的所有修改支持版本回滚、恢复历史这和Redis持久化“记录数据修改、恢复数据”的核心思想高度相似用Git做对比程序员能一秒懂AOF和RDB的本质区别。
先定一个通用比喻Redis内存 ≈ Git的工作区你正在修改的代码还没提交Redis持久化文件RDBAOF ≈ Git的本地仓库所有提交记录和文件快照存在硬盘不会丢Redis的写操作 ≈ Git的工作区修改增删改代码核心对应关系全程用Git操作比喻一看就会Redis RDB ≈ Git的【全量快照/打Tag/打包项目】Git打Tag比如你在项目v
0版本打一个tag就是给这个版本的所有代码拍了一张完整快照不管后续怎么改都能通过tag恢复到v
0Git打包把当前项目的所有文件打成一个zip包就是全量快照和RDB把内存所有数据打成二进制包完全一样特点快照文件体积小恢复快只记录某一时刻的状态没有历史修改记录。
Redis AOF ≈ Git的【commit log提交日志】你在Git里每执行一次git commit -m 修改了XX功能就是把工作区的修改按顺序记录到commit log里和AOF记录每一个写操作完全一样Git的git log能看到所有提交记录按时间顺序Redis的AOF文件能看到所有写操作记录按时间顺序Git支持git reset --hard 提交ID回滚到任意版本Redis支持修改AOF文件删去后续命令重放后恢复到任意时刻的数- 据核心逻辑完全一致特点追加写记录所有历史修改体积随时间增大能恢复到任意历史状态。
Redis AOF重写 ≈ Git的【合并提交git rebase -i】你在Git里可能会有很多次小提交比如“修复一个小bug”“改个变量名”用git rebase -i可以把这些小提交合并成一个大提交日志会变简洁体积变小Redis的AOF重写就是把多次冗余的写命令合并成最简命令AOF文件体积变小核心目的都是精简日志不丢失历史数据。
Git的reflog ≈ Redis AOF重写前的原文件Git的reflog会记录所有操作包括合并提交、回滚就算合并了提交也能通过reflog恢复到合并前的状态Redis的AOF重写时会先保留原AOF文件重写完成后再替换就算重写出错也能通过原文件恢复数据逻辑一致。
核心
总结Git和Redis持久化的相同思想两者的核心都是**“快照日志”的组合思路**Git用「tag/全量快照」做快速恢复用「commit log」做细粒度历史记录Redis用「RDB快照」做快速恢复用「AOF日志」做细粒度数据保护实际使用中Redis推荐AOFRDB同时开启Git推荐定期打Tag频繁commit本质都是“用快照保速度用日志保数据”。
六、