redis中持久化机制(九)

redis虽然不是关系型数据库，但是它也应该有持久化，要不虽然它是直接在内存里进行操作，但是如果出现宕机，或者其他错误想把数据恢复不就废了吗？

https://www.cnblogs.com/qlqwjy/p/7800526.html
上面这个博客详细的写了redis实现持久化的两个AOF和RDB，我就不再多说一遍了，不过请详细的看，对你的益处会非常大的
但是因为我是用的windows下面的会有点不一样，所以持久化进程的实施我没看他的

持久化过程的实施(windows)

其实和windows和Linux系统之间redis没什么太大的区别(有的linux用命令操作在windows里不行，因为那时linux命令，)，你下载的时候都看到redis有windows和linux两个版本，关于内部的肯定都一样的，要不这并不就成重大失误了吗，有区别的也就是操作redis配置文件的过程区别，配置文件的别名的区别，最终的目的和实现的结果是一样的

第一个不同的就是配置文件，我看到很多网上的redis.conf是配置持久化的文件，我是没找到(可能我下的是windows版本，他们下的是Linux版本),在windows里是redis.windows.conf配置文件里配置持久化
根据上面那个博客的前提下改改

0.编辑redis.windows.conf(在你安装的文件夹下)将redis的启动设置为后台启动(守护进程)（windows不支持）

看到黄色的了，，翻译过来就是windows系统不支持守护进程，所以就别想了
守护进程https://www.cnblogs.com/burningleaf/p/9736911.html

1.RDB(快照)持久化测试

在redis里，默认使用RDB模式。因为RDB模式重建数据库比较快。

(1)修改配置文件RDB持久化频率

黄色染料里的三行写的是RDB持久化里
指定在多长时间内，有多少次更新操作，就将数据同步到数据文件，可以多个条件配合

save         规定时间（秒）内             进行至少多少次更改就写入RDB
save           900 									1            	//900秒内至少进行一次更改写入RDB

(２)将rdb文件的生成目录改为/var/redis目录下(var目录用于存放系统经常变化的文件)

第一个基本上是现成的，第二个自己改,特别提醒/var前的那个 点 一定要有

(3)重启redis服务进行测试:

重启：（由于缺少/var/redis目录而报错）

 redis-server  redis.windows.conf  //redis.windows.conf  需要在应用的当前文件夹下写命令

在用户写这条命令会出现

C:\Users\lenovo>redis-server redis.windows.conf
Invalid argument during startup: Failed to open the .conf file: redis.windows.conf CWD=C:\Users\lenovo

不成功，我就切到redis文件夹下，就成功了，但是还是报错这是另外一个错误

因为刚刚修改的redis.windows.conf光修改没有添加/var/redis目录所以有问题，这也说明了不是redis自己创建，而是必须手动创建var文件夹和redis文件夹,并把dump.rdb移动到 var/redis/ 下

D:\redis>redis-benchmark -n 2000    //redis性能检测工具执行2000次命令
D:\redis>redis-cli
127.0.0.1:6379> keys *    //测试客户端是否有key
1) "counter:__rand_int__"
2) "mylist"
3) "key:__rand_int__"

关闭服务器重启
直接把cmd.exe给关闭了，服务器也就关闭了
客户端查看是否有数据(服务器重启之后仍然有数据证明被持久化)

2.AOF持久化测试

首先清空数据库

127.0.0.1:6379> flushall
OK
127.0.0.1:6379> keys *
(empty list or set)
127.0.0.1:6379>

在Redis的配置文件中存在三种同步方式，它们分别是：

appendfsync always #每次有数据修改发生时都会写入AOF文件。
appendfsync everysec #每秒钟同步一次，该策略为AOF的缺省策略。
appendfsync no #从不同步。高效但是数据不会被持久化。

(1)开启AOF持久化

修改配置开启AOF

(2)修改同步方式(默认就是每秒记一次)

(3) 重写机制:(也就是将aof文件重新整理一下) 达到64M之后每增长百分之百重写一次

(4)测试AOF持久化操作

1.重启redis服务并查看/var/redis目录(aof文件的生成位置与上面RDB持久化的文件生成位置一个目录)
重启大家肯定会了
在启动时要这么启动，不要直接redis-server，因为此时aof文件还不存在(因为是第一次)

D:\redis>redis-server redis.windows.conf

看到上面的就应该知道怎么启动了吧，这样再去var/redis文件夹下去看，此时appendonly.aof文件生成了，虽然里面是空
2.客户端执行两次redis操作

3.打开appendonly.aof文件查看

解释: *2 *3 * 5分别代表这条命令占据的行数
*2: select 0 使用默认的redis数据库

*3: set a test

5 lpush lkey1 aaa bbb ccc
也就是redis会根据上面的aof文件重新执行脚本进行数据的恢复。
断开连接，关闭redis，再打开查看所有的key

在这遇到了个问题，在重新打开redis-server时没有跟着加上redis.windows.conf,
所以在keys *时根本没有旧的数据，相当于你打开redis-server中没有读取RDB或者AOF中历史的记录，所以是空的
(5)测试AOF文件的重写(对AOF文件进行压缩，对数据进行处理)

int
$1
1
*3
$6
incrby
$3
int
$1
1
*3
$6
incrby
$3
int
$1
1
*3
$6
incrby
$3
int
$1
1
*3
$6
incrby
$3
int
$1
1
*3
$6

查看appendonly.aof文件的大小

（6）客户端重写AOF文件:(整理AOF文件，只保留AOF的结果，多次increby 变为结果)


内容:(操作已经进行合并)

所以在AOF日志文件里会有很多经常对一个key的操作，会使aof文件越来越大，所以经常和bgrewriteaof用，可以缩小AOF的文件大小，把对一个key的操作合并成一条命令，每天用bgrewriteaof定期重新整理数据
注意:

如果需要将redis数据库从一台服务器复制到另一台服务器，可以将aof文件和rdb文件进行拷贝，复制到另一台机器的redis工作目录下面，默认优先加载aof文件。
　　　　
Redis中AOF执行的细节
https://zhengdl126.iteye.com/blog/2191834
特别需要注意的是上面博客上的运维上的建议:为了保证高性能，数据没有做dump，也没有用aof。因为不做dump发生的故障远远低于做dump的时候，即使数据丢失了，自动修复脚本可以马上数据恢复。毕竟对海量数据redis只能做数据分片，那么落到每个节点上的数据量也不会很多，
用redis本来就是为了达到变态的性能，虚拟内存、aof看起来都有些鸡肋。