* ### 一、RDB （RedisDataBase）简介 ``` 意思就是将整个Reids的数据（通过二进制格式），持久化到磁盘里，注意 —— RDB是Redis默认的持久化机制 ``` 工作原理： ``` 这里是引用fork子进程（默认bgwrite模式下是这个，这样的话就不会阻塞请求了，因为还有主线程在工作）进行当前数 据的二进制文件写入磁盘工作。每次都是对当前所有的数据进行二进制文件写入，然后会替换掉之前老的二进制文件。 （这就有个风险，如果不做定时备份的话，那么如果在替换过程中如果宕机了，整个二进制持久化数据就会全部丢失） ``` 优点： * 直接存储二进制数据的文件，大数据场景下恢复速度快 * 整个库Redis只有一个文件 —— 如果做了文件备份方案，比如每天归档一次数据，同时归档最近30天的数据，那这样的备份策略就很清晰明了，出现灾难性故障也好恢复。 * fork子进程，性能最大化 缺点： * 只有一个文件在不备份的情况下同样也算是缺点，因为要替换，会造成宕机时文件的丢失风险 * fork子线程，如果数据量巨大，可能导致fork的过程阻塞几百毫秒到一秒 #### RDB 配置关注点(Redis.conf文件）： ``` # 持久化数据到磁盘之 —— 频率，格式如下: # save 900 1 900秒内至少有1个key被改变（那就会在900秒的时候执行rdb同步） # save 300 10 300秒内至少有300个key被改变（那就会在900秒的时候执行rdb同步） # save 60 10000 60秒内至少有10000个key被改变 （那就会在60秒的时候执行rdb同步） # save "" 如果要禁用RDB模式就把下面这三行注释掉，并打开 save "" 的注释 save 900 1 save 300 10 save 60 10000 # 存储至本地数据库时（持久化到rdb文件）是否对这个二进制文件进行压缩数据，默认为yes rdbcompression yes # RDB后，本地持久化数据库文件名，默认值为dump.rdb（持久化的数据都会保存在这个文件里然后准备刷盘，可自定义文件名，特别是配置集群的话要改成对应机器的名字，另一个也是好区分） dbfilename dump.rdb # 工作目录 # 数据库镜像备份的文件放置的路径。 # 这里的路径跟文件名要分开配置是因为redis在进行备份时，先会将当前数据库的状态写入到一个临时文件中，等备份完成时， # 再把该该临时文件替换为上面所指定的文件，而这里的临时文件和上面所配置的备份文件都会放在这个指定的路径当中 # # AOF文件也会存放在这个目录下面 # # 注意这里必须制定一个目录而不是文件,是因为redis容器中存放快照文件的路径就是/data dir /data ``` 再次说明：如果要禁用RDB模式就注释掉三行持久化频率，并打开save “” 注释，如下 ``` save "" # save 900 1 # save 300 10 # save 60 10000 ``` ### 二、AOF（AppendOnlyFile）简介 ``` 顾名思义，（通过原操作语句）追加的方式，增量追加到一个日志文件里。 ``` #### **工作原理：** ``` 根据配置执行原操作语句追加（每次写入都进行追加/每秒追加一次/永不追加），如果追加满了（默认64M）则会启动rewrite机制，老的日志会写入磁盘，与此同时新开一个临时日志写新来的语句，等老的写完磁盘后，重新开始到老的写。 ``` #### **优点：** * 更高的安全性，如果数据被篡改了，还可以根据redis-check-aof工具来帮助数据恢复（这个也是参数设置是否开启的）。 * 数据更完整 * 因为是追加语句的形式，所以相对来说宕机风险小 * 另外如果配置的是每次写入都进行追加使得持久化数据完整 #### 缺点 * 因为保存的是原始操作语句，在大数据恢复场景下全部要重新执行一遍，所以相对很慢 * 根据同步策略的不同，开启AOF后的运行效率也会相对慢于RDB（当然尽管这样每秒同步策略还是比较高效的） #### AOF 配置关注点(Redis.conf文件): # AOF开关 —— 设置为yes则开启，如果AOF开启则优先使用AOF ``` appendonly no # AOF文件名称 (默认: "appendonly.aof") # appendfilename appendonly.aof # Redis支持三种同步AOF文件的策略: # # no: 不进行同步，系统去操作 . Faster. # always: always表示每次有写操作都进行同步. Slow, Safest. # everysec: 表示对写操作进行累积，每秒同步一次. Compromise. # # 默认是"everysec"，按照速度和安全折中这是最好的。 # 如果想让Redis能更高效的运行，你也可以设置为"no"，让操作系统决定什么时候去执行 # 或者相反想让数据更安全你也可以设置为"always" # # 如果不确定就用 "everysec". # appendfsync always appendfsync everysec # appendfsync no # AOF策略设置为always或者everysec时，后台处理进程(后台保存或者AOF日志重写)会执行大量的I/O操作 # 在某些Linux配置中会阻止过长的fsync()请求。注意现在没有任何修复，即使fsync在另外一个线程进行处理 # # 为了减缓这个问题，可以设置下面这个参数no-appendfsync-on-rewrite no-appendfsync-on-rewrite no # Automatic rewrite of the append only file. # AOF 自动重写机制 # 这个机制类似于RDB的二进制压缩机制，是用来缩小文件大小的 —— 比如对相同key的多次操作则只会保存最后一次操作，对多次操作，可以用一条语句完成的则改成一条语句.... 具体是会新建一个临时AOF文件，然后读取Redis中的数据（不是老的AOF哦），然后进行重写，写完后替换老的AOF文件 #关于主从部分，AOF机制是这样的，如果从在重写，主进来了新的追加，那么主会写自己AOF的同时，再写一份相同的在缓存区，子重写完后会通知主，那这个时候主会把缓存区的再追加到子AOF文件中 #【重写的触发条件】 #1.无rdb、aof的持久化操作 #2.无BGREWRITEAOF进行（手动进行aof重写操作） #3.AOF文件大小超过阈值，默认1M #4.AOF文件增长率超过阈值，默认100% # 设置 percentage 为0就关闭这个特性 auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb ```