目录
前言：
redis为了保证高可用引入了持久化机制，目的就是为了redis服务器重启时可以恢复原有的数据。redis提供了RDB，AOF和混合持久化三种机制，开发者可在不同的业务场景具体选择使用哪一个持久化机制。
持久化机制
RDB（Redis DataBase）
定期备份，每隔一段时间将内存中的数据刷新到硬盘中，生成一个快照rdb文件（用来恢复数据）。
手动触发
save
执行save的时候，redis会全力以赴的进行“快照生成”的操作，此时就会阻塞其他客户端的命令，因为redis是单线程模型。（一般不建议）
bgsave
1）不会影响redis处理其他客户端的命令。redis在后台采用多进程方式生成rdb文件。
2）redis将内存中的数据以压缩的方式保存到二进制文件中（镜像文件，rdb文件）。
3）redis服务器重启时，需要加载这个快照文件，如果快照文件格式不对，redis服务可能会启动失败。同时redis提供了rdb文件检查工具，可以手动执行进行rdb文件校验。
执行流程
当生成rdb镜像文件时，首先会保存在一个临时文件中，当快照生成完毕后。然后删除原来的rdb文件，将临时文件替换为新的rdb文件。（始终rdb文件只有一个）
多进程处理bgsave。当触发bgsave命令时，redis首先会判断是否有其他进程在执行rdb文件操作，如果有其他正在运行的进程则直接返回。
redis会fork一个和当前进程一模一样的子进程（文件描述符表，虚拟内存地址等等进程信息都是一致的）。并且也是共用同一块内存空间（防止内存数据量太大fork时就比较消耗资源），只有当父进程修改了内存中的数据时，此时子进程就会复制内存中的数据，不在和父进程共享同一块内存了。当子进程处理完rdb文件时，使用信号通知父进程，父进程就可以销毁这个子进程了。
redis生成快照操作触发时机：
1）配置文件中M时间内修改N次，自动触发。
2）通过shutdown命令正常停止redis服务。
3）redis进行主从复制的时候，主节点会自动生成rdb快照，然后把rdb快照传输给从节点。
自动触发
在redis配置文件中，设置每隔多长时间/数据修改多少次就触发。
RDB特点
1）RDB是一个紧凑压缩的二进制文件，代表redis在某个时间点上的数据快照。非常适用于备份，全量复制等场景。
2）redis加载RDB文件恢复数据远远快于AOF的方式。（主要由于RDB是二进制文件）
3）RDB方式数据没办法做到实时持久化/秒级持久化。因为bgsave每次运行都要fork子进程，属于重量级操作，频繁执行成本过高。
4）RDB用特定的二进制文件保存，redis是有多个版本的，存在兼容性问题。
注意：
rdb持久化机制不能做到实时持久化，每次持久化操作之间都会存在时间间隔。那么在时间间隔内，如果redis服务器宕机了，这段间隔时间内数据还没有生成rdb文件，那么服务器重启就会丢失数据。
AOF（append only file）
AOF是一个文本文件，每次进行redis操作，都会被追加到文件末尾（直接追加操作redis命令）
注意：
redis首先将内存中的数据写入内存中的缓冲区，积累一波后，再统一写入到硬盘中。（大大降低了写硬盘的次数）
AOF每次将新的操作追加到文件末尾，属于顺序写入，效率相对较高。
缓冲区刷新策略
| 可配置值 | 说明 |
| always | 命令写入aof_buf 后调用fsync同步，完成后返回 |
| everysec | 命令写入aof_buf 后只执行write操作，不进行fsync，每秒由同步线程进行fsync |
| no | 命令写入aof_buf 后只执行write操作，由操作系统控制fsync频率 |
注意：
上述缓冲区刷新策略由快到慢，那么数据可靠性由高到低，性能由低到高。配置文件中都是可修改的。
重写机制
aof文件中存在一些冗余的记录（一些命令的中间状态也都保存了），redis重写机制针对aof文件进行整理，达到瘦身的效果。
aof文件中数据只关注内存中最终状态，因此只需要将内存中的数据状态写入新aof文件，替换掉原来的就可以。
触发时机：
手动触发：bgrewriteaof命令。
自动触发：配置文件中进行配置（触发时aof最小文件大小，aof相比于上次文件大小增加的比例）
aof重写流程
父进程会fork一个子进程，子进程将此刻内存数据按照aof格式写入到新aof文件。同时父进程继续处理命令，同时也写入到aof_rewrite_buf和旧aof文件中。
当子进程将新aof文件写入完毕，使用信号通知父进程，然后将父进程写入的aof_rewrite_buf合并到新aof文件，然后替换掉旧aof文件。
问：为什么父进程需要写旧aof文件，不是最后要替换掉吗？
如果子进程写新aof文件，突然进程挂了，那么aof文件就是不完整的。如果没有旧aof文件，数据就丢失了。
注意：
重写只关注内存中的最终状态，不关注aof文件中原来有啥。
如果，在执行bgrewriteaof的时候，已经在执行aof重写了，此时不会再次执行aof重写，直接返回了。
如果，在执行bgrewriteaof的时候，redis正在生成rdb快照，此时redis的aof重写就会等待，等待rdb文件生成完毕，再执行aof重写。
混合持久化
结合了aof和rdb机制的特点。
按照aof的方式将每一步操作都记录到文件中。在触发aof重写机制后，就会把当前内存的状态按照rdb的二进制格式写入到文件中，后续再操作仍然是按照aof文本追加的方式写入文件。
注意：
当redis上同时存在aof和rdb文件时，以aof为主，rdb就被忽略了。
事务
把多个操作打包到一起，要么全都执行，要么全都不执行。如果执行若干条命令，失败了，那就失败了，没有任何处理。（由于和mysql相比这里没有回滚操作，那么认为redis事务没有原子性）。
不具备一致性：redis没有约束，也没有回滚机制。事务执行过程中如果某个修改操作失败，就会导致不一致的情况。
不具备持久性：redis是内存数据库，数据存储在内存中的。虽然有持久化机制，但也是为了redis恢复数据，和这里没有关系。
不涉及隔离性：redis是单线程处理请求命令，所有请求都是串行执行的，不涉及并发。
redis事务主要意义：
就是为了打包命令，防止其他客户端命令插队。
注意：
redis实现事务引入了队列（每个客户端都有一个）。开启事务的时候，客户端请求命令就会进入到这个队列，而不会立即执行，当提交事务的时候，redis才会打包一起按照顺序执行这些命令。主线程会把这些命令处理完，再处理其他客户端请求。
redis如果按照集群模式部署，不支持事务。
事务操作命令
开启事务：MULTI
提交事务：EXEC
放弃当前事务：DISCARD
注意：
当开启事务，并且客户端发送若干条命令后，如果redis服务重启，那么就会放弃当前的事务（DISCARD）。
WATCH
监控某个key，是否在事务执行之前发生了改变。
如果在事务执行时发现了某个key被其他客户端修改了，那么事务提交时就不会真正执行这条修改命令。
WATCH实现原理
基于版本号机制实现类似“乐观锁”。预测锁竞争不是很激烈，即其他客户端在事务提交之前修改相同数据概率不是很大。
当使用watch监控某个key时，会给这个key分配一个版本号，如果有其他客户端修改了这个key，则版本号会变大。当exec提交事务的时候就会判断，这个key版本号是否和之前watch记录的版本号一致。
如果一致则说明key没有被修改过，就会正常执行事务中的命令。如果不一致则说明key被其他客户端修改过，就会直接丢弃事务中的操作，exec返回nil。
6万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
