Redis会单独fork（创建）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程结束了，在用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能。
如果需要进行大规模数据的恢复。且对于数据恢复的完整性不是非常敏感，那RDB方案要比AOF方案更加的高效，RDB的缺点是最后一次持久化后的数据可能丢失。
fork
fork的作用是复制一个与当前进程一样的进程，新进程的所有数据（变量、环境变量、程序计数器等）数值都和原进程一致。但是是一个全新的进程，并作为原进程的子进程。
缺点：复制进程消耗大
Redis的两种持久化方式：
一、RDB（Redis DataBase）
在指定的时间间隔内将内存中的数据集快照写入磁盘。也就是行话讲的Snapshot快照，它回复时是将快照文件直接读到内存里。
在一定条件下，将内存中的数据保存到磁盘上（比如说60秒内10次修改、100秒内10次修改，可以自己配置）。
保存的是dump.rdb文件
优点：适合大规模的数据恢复
对数据完整性和以执行要求不高
缺点：redis意外挂了，最后一次会丢失
fork，占内存
停止rdb备份：redis-cli config set save ""
二、AOF（Append Only File）
以日志的方式记录每个写操作，将redis执行过的所有写操作记录下来，只需追加但不可以改写文件，redis启动之初会读取该文件重新构建数据。换言之，redis重启的话就根据日志文件的内容将写操作从前到后执行一次。以完成数据的恢复工作。
redis默认dump.rdb和appendonly.aof可以同时存在，在同时存在的情况下默认先加载appendonly.aof，若appedonly.aof文件损坏，则redis会启动失败。
appendonly.aof文件损坏时，可以使用redis安装目录下的bin目录下的redis-check-aof修复appendonly.aof文件。命令：redis-check-aof --fix appendonly.aof。
aof配置策略：
Appendfsync：
Always：同步持久化，每次发生数据变更会被立即记录到磁盘。性能差但数据完整性好。
Everysec：出厂默认，异步操作，每秒记录。如果一秒内宕机，会有数据丢失
No：不同步
Rewrite
AOF采用文件追加方式，文件会越来越大为避免出现此种情况，新增了重写机制，当AOF问价的大小超过锁设定的阈值时，Redis就会启动AOF文件的内容压缩。之保留可以恢复数据据的最小指令集。可以使用命令bgrewriteaof。
重写原理：
AOF文件持续增长而过大时，会fork出一条新进程来讲文件重写（也是险些临时文件最后再rename），遍历新进程的内存中数据，每条记录有一条set语句。重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似。
触发机制：
Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。
No-appendfsync-on-rewrite：重写时是否可以运用Appendfsync.用默认no即可，保证数据安全性。
Auto-aof-rewrite-min-size：设置重写的基准值。
Auto-aof-rewrite-percentage：设置重写的基准值
Redis的事务
可以一次执行多个命令，本质是一组命令的集合。一个事务中的所有命令都会序列化，按顺序串行化执行。
一个队列中，一次性、顺序性、排他性的执行一系列命令。
Redis事务命令：
DISCARD：取消事务，放弃执行事务块中的所有命令。
EXEC：执行所有事务块内的命令。
MUTIL：标记一个事务块的开始
UNWATCH：取消WATCH命令对所有key的监视。
WATCH key：监视一个（或多个）key，如果在事务执行之前这个key被其他命令锁改动，那么事务将被打断。
Redis对事务部分支持：
除去事务的正常执行和放弃事务之外。还有两种对事务的支持，一种是一个事务出错，同一个事务块中的所有事务全部失败。另一种是一个事务失败，同一个事务块中的其他事务正常执行。这两者之间的区别是，在插入队列的时候报错是第一种情况，在事务执行exec的时候报错是第二种情况。这就有一点类似于java中的编译时错误和运行时错误。第一种情况类似于编译时错误，第二种类似运行时报错。
watch监控：
监控一个或多个key，类似于乐观锁，事务提交时，如果key的值被别的客户端改变，那么整个书屋队列都不会被执行。
通过WATCH命令在事务执行之前监控了多个keys，倘若在WATCH之后有任何key的值发生了变化，EXEC命令执行的事务都将被放弃，同时返回Nullmulti-bulk应答以通知调用者事务执行失败。
Redis事务的三个阶段
- 开启：以MULTI开始一个事务
- 入队：将多个命令入队列到事务中，街道这些命令并不会立即执行，而是放到等待执行的事务队列里面
- 执行：由EXEC命令触发事务。
Redis事务的三特性
- 单独的隔离操作：事务中的所有命令都会序列化、按顺序执行。事务在执行的过程中，不会被其他客户端发送来的命令请求锁打断。
- 没有隔离级别的概念：队列中的命令没有提交之前都不会实际的被执行，因为事务提交前任何执行都不会被实际执行，也就不存在“事务内的查询要看到事务里的更新，在事务外查询不能看到”这个让人万分头痛的问题。
- 不保证原子性：redis同一个事务中如果由一条命令执行失败，其后的命令仍然会被执行，没有回滚。
Redis的发布订阅
进程间的一种消息通信模式：发送者（pub）发送消息，订阅者（sub）接收消息。
订阅：SUBSCRIBE c1 c2 c3：订阅c1 c2 c3
消息发布：PUBLISH c2 hellowolrd
这时订阅了c2的客户端就会接收到hellowolrd这条消息。
订阅多个，通配符*：SUBSCRIBE new*，发布消息：PUBLISH new12 hello，这时new*就会接收到消息。
持续更新~~