开发者学堂课程【Redis 数据库入门： Redis_AOF_RDB 持久化_3】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/15/detail/57
Redis_AOF_RDB 持久化_3
内容介绍：
一、AOF持久化文件配置
二、文件路径与内容配置实操
一、AOF 持久化文件配置
1、AOF 持久化阻塞服务
AOF 持久化的默认操作其实是阻塞服务的，但是这种阻塞造成的影响并不大，因为其实际上是追加一条命令的行为，造成的阻塞的时间很短，尤其是相较于RDB持久化过程中需要传输所有的数据，AOF 持久化较快。
默认情况下 append only 值是“no”，也就是说默认情况没有开启机制。如果开启机制，append file name 就会落到 append only.aof 文件，也就是落在 AOF 文件中。配置文件中“APPEND ONLY MOOD”部分包含“By default Redis asynchrononously dumps dataset on disk.This mode is good enough in many applications”的一段信息，表明默认情况下把 append only 这种模式加上，大部分应用其实就可以被满足了，因为它丢失的是一秒内的数据，而很多应用是用它来做缓存，一秒的数据的丢失可以被许多应用接受。
2、默认值
上节课中提到，AOF 持久化有三种策略，即a lways，everysec 和 no。在默认配置文件中显示 appendfaync everysec，说明 everysec 是默认值。
3、AOF 文件中的冗余命令
配置文件中还包括两个条件，即“auto-aof-rewrite-percentage 100”和“auto-aof-rewrite-min-size 64mb”,即 AOF 文件中的冗余命令。
（1）冗余命令
冗余命令是指随着服务器不断的运行，为了记录数据库发生的变化，服务器会将越来越多的命令写到 AOF 文件里，AOF 文件的容量不断的增大。为了让 AOF 文件大小控制在合理范围内，避免其胡乱增长，Redis 提供了一些重写 AOF 文件的机制。
（2）AOF 重写实例
下图为重写前后的 AOF 文件对比：
当原有的 AOF 文件如果达到了配置文件里面的条件，它就会进行重写，重写之后的AOF 文件短了很多。
①“SELECT 0”选择某个数据库，命令十分简短，没有重写的必要；
②在该数据库中，进行了连续的4个 SADD 操作“SADD fruits apple”“SADD fruits banana”“SADD fruits cherry”“SADD fruits apple”，等价于批量同时添加多个元素。此时，就可以把4条命令整合为一个命令“SADD fruits ‘apple’‘banana’‘cherry’”。
③“INCR counter”、“INCR counter”与“DEL counter”
写入可两个counter之后又删除了 counter，所以重写之后的AOF文件中就没有再出现counter。
④SET msg“hello world”与SET msg“hello wold again！”
重写后直接保留 SET msg“hello wold again！”。
⑤RPUSH Ist 1 3 5、RPUSH Ist 7与LPOP Ist
前两个命令是依次写入1 3 5 7，后最后一个命令“LPOP Ist”的含义是从最左侧弹出一个值，也就是弹出了“1”，所以重写后的命令就是依次写入3 5 7，即RPUSH Ist 3 5 7。
通过将多个命令合并的方式使得AOF更加简洁，进而达到重写的效果
（3）触发重写的方法
①客户端向服务器发送 BGPREWRITEAOF 命令，也就是background rewrite AOF，即可触发 AOF 文件的重写。
②通过设置配置选项让服务器自动执行 BGPREWRITEAOF 命令。自动执行命令的配置选项为：
a.auto-aof-rewrite-min-size <size> ，触发 AOF 重写的所需的最小的体积。只有AOF 文件体积大于等于 size 时，服务器才会考虑是否要进行 AOF 重写，避免体积过小的 AOF 也进行重写。在自动情况下，服务器会考虑条件。
而在默认情况下，默认值中显示“auto-aof-rewrite-min-size 64mb”，即默认值是 64MB，在实际情况中这是一个较难达到的大小。在默认条件下，文件达到 64MB 后自动重写。但 AOF 文件体积达到64 MB仅是出发文件重写的条件之一。假设，一个原本体积为 64MB 的文件经过重写体积缩小至 32MB；然后又不断对该文件追加，再次达到 64MB，再次重写，缩小至 62MB；继续追加，达到 64MB 又一次重写经过多次重写之后，即使再重写，也不可能比 64MB 更小，就会陷入循环的环境，因此需要另外的条件约束。
b.auto-aof-rewrite-percentage 100，意思是累计值达100%。通过两个条件综合，文件的体积达到64MB，且累积的大小达到了100%，即已经扩展了一倍，即会进行重写。简单来说，只有文件大小达到 64MB，然后又新增了 64MB，才触发重写，而不是每次达 64MB 都进行重写。
以此类推，若经过重写累计至 128MB，若文件大小再到64MB时，此时的累计值没有达到100%，而只达到了50%，此时不会重写。只有下一次文件达到 128MB/新增128MB 时才会进行再次重写。也就是说只有两个条件同时满足时才会触发重写。当然触发条件可以自行配置。
4.复习
（1）创建 RDB 文件需要将服务器所有数据库的数据全部写到硬盘里，是一个非常耗时的操作，服务器需要隔一段时间才创建文件，可能会导致数据丢失。
（2）AOF 持久化会默认将每秒/每个修改的命令都追加到文件末尾。
（3）当写入到缓存区时，AOF 持久化会根据个人配置进行追加文件（默认是每个隔一秒写入一次）。
（4）RDB 持久化与 AOF 持久化
①RDB 持久化为全量备份，一次保存整个数据库，而 AOF 持久化是在间隔之内增量备份，一次保存修改数据库的命令；
②RDB 持久化的保存间隔较长，AOF 持久化默认情况下间隔一秒；
③RDB 持久化的数据还原速度很快，直接加载数据即可，而 AOF 持久化的数据还原速度一般，如果冗余命令越多，还原速度越慢；
④RDB 持久化执行 SAVE 命令时会阻塞，执行 BGSAVE 命令时会 fork 子进程，不会阻塞服务器，而 AOF 持久化无论是平时还是进行 AOF 重写时都不会阻塞服务器。
因为其执行的命令是 BGREWRITEAOF 命令，不管是主动操作，还是默认状态都使用该条命令执行，其实是在后台进行操作，不会阻塞服务器；
⑤RDB持久化更适合数据的备份，AOF 持久化则更适合用来保存数据，通常意义上是数据持久化。在 appendfsync always 情况下，Redis 的持久化方式和一般的 SQL 数据库的持久化方式相同。
在 SQL 数据库中，比如 MySQL，它里面有 beenlog，主要用来写操作日志，其工作机制类似于此处的 always 这种机制，即每写一个操作，都会记录在日志中。而且 Redis 持久化默认是一秒记录一次。
如果要使用 Redis 来存真正的数据，且每一条数据都不允许丢失，就要将其改成always。但是实际情况下，有的数据只需要缓存，如果将仅需缓存的数据也按照always机制保存，效率可能会比较低，在这种情况下就可以开多个 Redis 服务，不同的业务可以对应不同的 Redis 服务。
比如一个端口是6379，另一个端口的是6380或者是在另外的服务器上的6379，对于不同的业务，缓存级别不同，持久化的级别也不同。
如新浪，每台服务器上面有4个 Redis 服务，整个业务里有上千个 Redi 服务，每个持久化的级别都是不同的，每个吃的话级别都是不一样的。
⑥两种持久化可以同时使用，可以保证数据的安全性。因此 Redis 数据库安全性地域SQL 数据库的安全性是个误解。
如果将其调成在 always 模式下运行，两者的持久化模式完全相同，都很严格，速度也都较慢。如果说 Redis 服务器不安全，其实是因为没有调整好配置。
二、文件路径及内容配置实操
appendonly 仍保持为“no”，进行 redis-cli 操作，手动输入“BGREWRITEAOF”命令，显示“Background append only file rewriting started”。
当然也可以不重新服务，而是手动写入一个文件 ll/Var/lib/redia/6379，结果显示新建了一个 AOF 文件 appendonly.aof。
输入 vim/var/lib/redia/6379/appendonly.a
of 进行查询，即可查看 AOF 文件中保存到所有命令。
如果该文件用来应急查询，如有人写了 flashdb 将它追加到 AOF 里，但事后不想让其保存在记录里，就可以把该命令从 AOF 文件里面清除。
因为 AOF 文件保存的即是命令，如果要删除保存的命令，直接将命令语句删除即可。而如果 flashdb 命令正好触发了 dump 的条件的话，RDB 数据发生了改变，就无法撤回该命令了。
