引言
终于可以有时间继续看书，整理自己的见解， 写下2019年第一篇自己的随笔。从去年9月份跳槽到新公司后，几乎天天的加班让整个人都盲目了，原本计划好的事情总是会被打乱。都说坚持一件事情很难，特别是写博客。确实我由于自己的懒惰以及工作的事情，导致“放弃”了三个的月随笔博文习惯，希望2019年再接再厉吧；
由于Redis在公司的架构中使用很多，但是大部分人包括我也一开始只是停留在会部署的地步，并没有深入理解为什么那么部署，以及Redis的一些特性，今天参考了一些资料以后，做了关于Redis持久化的一个简单博文
一、什么是Redis持久化
简单来说，就是Redis通过将数据存储于内存或者虚拟内存（也是Redis常用的技术），通过某种技术手段将数据保存于可永久保存的存储设备或媒介中，以此来保证数据完整不丢失、高速访问数据、快速恢复。
二、Redis持久化的两种方式
Redis一般通过两种方式实现持久化：快照方式（RDB模式，默认方式），日志追加方式（AOF模式）
1. 快照方式（RDB方式）
这种方式有一下几个特点，显而易见RDB方式总结起来就是一种将数据以快照方式写入二进制文件中，在间隔时间内全量写入磁盘的一个过程。它的优缺点也在一下四个特点中体现，
缺点：第一是多少间隔时间的重要性，第二是数据量大的情况下，全量写入会影响性能
优点：对于恢复操作相对比较简单，因为全量写入只需要保证一个二进制文件的恢复即可；
（1） 将内存中数据以快照的方式写入二进制文件中，默认文件名为dump.rdb
（2） 客户端使用save/bgsave命令做一次快照持久化（save操作在主线程中保存快照，Redis是用一个主线程处理所有的客户端请求，所以可能会阻塞所有的客户端请求，不推荐使用）；
（4） 快照方式并不是增量数据，而是全量重新写入，数据量大的情况下会严重影响性能（主要是由于大量IO操作以及主进程不断fork()子进程去处理持久化工作）。
（5） 快照方式是间隔时间做一次，所以如果redis意外宕机的话，就会丢失最后一次快照的后的所有数据。
2. 日志追加方式(AOF持久化)
Redis会将每一个收到的写命令都通过write函数追加到文件中（默认为appendonly.aof），当redis重启时会通过重新执行文件中保存的写命令来在内存中重建整个数据库的内容。
缺点：相比较RDB而已AOF的文件相对较大（redis当AOF文件比较大时，可以重写），AOF的速度比RDB相对较慢；
优点：采用everysec配置，那么顶多损失前一秒的数据；不会像RDB那样损失很多（当然只是相对而言）；
AOF的文件没有被重写的话，比如当我们不小心FULASHALL，现在需要恢复。只需要AOF文件末尾中去掉该命令，重启Redis载入即可（即AOF文件比较容易读懂，恢复上一个状态简单）
（1） 由于OS会在内存中缓存write的修改，所以并不会立即写到磁盘上，这样可能会导致丢失部分修改，可以通过配置来实现强制OS写到磁盘时机。
a) appendonly yes //启用日志追加持久化方式
b) appendfsync always //每次收到写命令就立即强制写入磁盘，最慢的，但是保证完全的持久化，不推荐使用
c) appendfsync everysec //每秒钟强制写入磁盘一次，在性能和持久化方面做了很好的折中，推荐使用
d) #appendfsync no //完全依赖操作系统，性能最好,持久化没保证
（2）持久化的文件会越来越大，比如执行incr test命令100次，最后恢复使用set test 100就够了，但是这种方式保存了100条命令，其中99次是多余的；
（3） 为了（2）中提到的缺点，redis提供了bgrewriteaof命令：redis将内存中的数据以命令的方式保存到临时文件中，最后替换原来的持久化日志文件。
三、Redis持久化的配置
1. RDB默认方式配置：
# 时间策略：当满足每900s/300s/60s内至少1/10/10000次写操作，则会触发bgsave命令进行持久化，三个策略中只需要满足其中任何一条即可持久化 save 900 1 save 300 10 save 60 10000 # 文件名称 dbfilename dump.rdb # 文件保存路径 dir /home/redis/data/ # 如果持久化出错，主进程是否停止写入：是为了保证数据的一致性，工作进程（子进程）持久化出错后，主进程停止写入请求 stop-writes-on-bgsave-error yes # 是否压缩 rdbcompression yes # 导入时是否检查 rdbchecksum yes
2. AOF日志追加方式配置：
# 是否开启aof appendonly yes # 文件名称 appendfilename "appendonly.aof" # 同步方式，上文已提到 appendfsync everysec # aof重写操作是否同步，yes则不进行同步，no则同步 no-appendfsync-on-rewrite no # 重写触发配置 auto-aof-rewrite-percentage 100 # 当前AOF文件大小是上次日志重写时的AOF文件大小两倍时，发生BGREWRITEAOF操作。 auto-aof-rewrite-min-size 64mb # 当前AOF文件执行BGREWRITEAOF命令的最小值，避免刚开始启动Reids时由于文件尺寸较小导致频繁的BGREWRITEAOF。 # 加载aof时如果有错如何处理，忽略最后一条可能存在问题的指令 aof-load-truncated yes # Redis4.0新增RDB-AOF混合持久化格式。 aof-use-rdb-preamble no