招式修炼-redis持久化和管道

1.快照

快照是一次全量备份，顾名思义可以理解为拍照一样，把整个内存数据映射到硬盘中，保存一份到硬盘，因此恢复数据起来比较快，把数据映射回去即可，不像AOF，一条条的执行操作命令。

1.1.快照流程

• 执行bgsave命令(此时redis会fork一个子进程,子进程负责生成硬盘文件,父进程负责继续接受命令)
• 或执行save命令(和bgsave命令不同,发送save命令后,到系统创建快照完成之前系统不会再接收新的命令,换句话说save命令会阻塞后面的命令,而bgsave不会)
• 用户在配置文件了配置了类似这样的命令: save 900 1 // 900内,有1条写入,则产生快照 save 300 1000 // 如果300秒内有1000次写入,则产生快照 save 60 10000 // 如果60秒内有10000次写入,则产生快照 (这3个选项都屏蔽,则rdb禁用)
• 用户发送shutdown,系统会先通过save命令阻塞客户端,然后关闭服务器
• 当有主从架构时,从服务器向主服务器发送sync命令来执行复制操作时,只有主服务器当时没有进行bgsave操作,那么主服务器就会执行bgsave操作。

1.2.快照优点

• 通过合理的配置，可以让Redis每隔一段时间就保存一次数据库副本，也可以很方便地将数据还原到特定的时间点。
• RDB文件相比AOF占用的空间更小，恢复数据的速度也更快。
• 如果创建RDB文件时出现了错误，Redis不会将它用于替换原来的文件，所以出错时不会影响到之前保存的版本。

1.3.快照缺点

• 如果硬件、系统、Redis三者其中之一出现问题而崩溃，Redis会丢失全部数据，保留下来的数据只有上一个时间点创建的快照。如果数据对于应用程序来说非常重要，那么出现错误时的损失会非常大。
• fork子进程占用的内存随着数据库中数据的增加而增加，耗费的时间也会越来越多

2.AOF 日志

AOF 日志存储的是 Redis 服务器的顺序指令序列，AOF 日志只记录对内存进行修改的指令记录。

它的出现是为了弥补RDB的不足（数据的不一致性），所以它采用日志的形式来记录每个写操作，并追加到文件中。Redis 重启的会根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。

2.1.AOF配置文件

打开 redis.conf 文件，找到 APPEND ONLY MODE 对应内容

# redis 默认关闭，开启需要手动把no改为yes
appendonly yes
# 指定本地数据库文件名，默认值为 appendonly.aof
appendfilename "appendonly.aof"
# 指定更新日志条件
# appendfsync always
appendfsync everysec
# appendfsync no

• always：同步持久化，每次发生数据变化会立刻写入到磁盘中。性能较差当数据完整性比较好（慢，安全）
• everysec：出厂默认推荐，每秒异步记录一次（默认值）
• no：不同步

2.2.AOF优缺点

优点：数据的完整性和一致性更高 缺点：因为AOF记录的内容多，文件会越来越大，数据恢复也会越来越慢。

3.总结

• Redis 默认开启RDB持久化方式，在指定的时间间隔内，执行指定次数的写操作，则将内存中的数据写入到磁盘中。
• RDB 持久化适合大规模的数据恢复但它的数据一致性和完整性较差。
• Redis 需要手动开启AOF持久化方式，默认是每秒将写操作日志追加到AOF文件中。
• AOF 的数据完整性比RDB高，但记录内容多了，会影响数据恢复的效率。
• Redis 针对 AOF文件大的问题，提供重写的瘦身机制。
• 若只打算用Redis 做缓存，可以关闭持久化。
• 若打算使用Redis 的持久化。建议RDB和AOF都开启。其实RDB更适合做数据的备份，留一后手。AOF出问题了，还有RDB。

02redis管道

什么是管道？？

Redis 管道 (Pipeline) 本身并不是 Redis 服务器直接提供的技术，这个技术本质上是由客户端提供的，跟服务器没有什么直接的关系。

管道（Pipeline）就是为了改善这个情况的，利用管道，客户端可以一次性发送多个请求而不用等待服务器的响应，待所有命令都发送完后再一次性读取服务的响应，这样可以极大的降低RTT时间从而提升性能。需要注意到是用pipeline方式打包命令发送，redis必须在处理完所有命令前先缓存起所有命令的处理结果。打包的命令越多，缓存消耗内存也越多。所以并不是打包的命令越多越好。

管道使用场景

适用一些命令之间没有相互依赖的，命令数量比较多的场景，可以像批处理一样对其进行处理。

管道总结

打包的redis的管道可以将多个命令打包，一次性的发送给服务器端处理，当命令之间不存在依赖关系时，相比于一条命令一次请求的普通操作方式，管道的操作几乎是对使用者透明的。

和redis的事务类似，redis管道能完成的操作也能够被更加灵活的redis脚本实现，但是脚本的可读性不强、可维护性差。个人认为，如果批量处理的命令之间不存在依赖关系时，优先使用管道；反之，则只能使用脚本了。