当前位置:必发365电子游戏 > 操作系统 > 效率相对RDB方式低很多,实际中使用的配置(在redis.conf)
效率相对RDB方式低很多,实际中使用的配置(在redis.conf)
2019-12-19

注:本文首要仿照效法自《Redis设计与完成》

原文:

1、Redis二种长久化方式

AOF方式:将以日记,记录每两个操作

 

 

优势:安全性相对EvoqueDB情势高非常多;

2、RDB

劣势:功能相对凯雷德DB方式低相当多;

实在中利用的配备(在redis.conf)

 

#发生以下三种的任何一种都会将数据库的缓存内容写入到rdb文件中去(写入的方式是bgsave)
#若将下述的三条命令都注释掉,则禁止使用rdb
save 900 1      #900s后至少有一个key发生了变化
save 300 10      #300s后至少有10个key发生了变化
save 60 10000    #60s后至少有10000个key发生了变化

#当后台RDB进程导出快照(一部分的key-value)到rdb文件这个过程出错时(即最后一次的后台保存失败时),
#redis主进程是否还接受向数据库写数据
#该种方式会让用户知道在数据持久化到硬盘时出错了(相当于一种监控);
#如果安装了很好的redis持久化监控,可设置为"no"
stop-writes-on-bgsave-error yes

#使用LZF压缩字符串,然后写到rdb文件中去
#如果希望RDB进程节省一点CPU时间,设置为no,但是可能最后的rdb文件会很大
rdbcompression yes

#在redis重启后,从rdb文件向内存写数据之前,是否先检测该rdb文件是否损坏(根据rdb文件中的校验和check_sum)
rdbchecksum yes

#设置rdb文件名
dbfilename dump.rdb

#设置rdb文件的存储目录
dir ./

配置:

说明

[root@localhost redis]# vi redis.conf 

 

注意

编辑redis.conf

 

 

往下拉 找到:

3、AOF

图片 2

实际上中运用的布署(在redis.conf)

 

# 是否打开aof日志功能(appendonly yes)
appendonly no

# aof文件的存放路径与文件名称
# appendfilename appendonly.aof

#每一个命令,都立即同步到aof文件中去(很安全,但是速度慢,因为每一个命令都会进行一次磁盘操作)
# appendfsync always
#每秒将数据写一次到aof文件
appendfsync everysec
#将写入工作交给操作系统,由操作系统来判断缓冲区大小,统一写到aof文件(速度快,但是同步频率低,容易丢数据) 
# appendfsync no

# 在RDB持久化数据的时候,此时的aof操作是否停止,若为yes则停止
# 在停止的这段时间内,执行的命令会写入内存队列,等RDB持久化完成后,统一将这些命令写入aof文件
# 该参数的配置是考虑到RDB持久化执行的频率低,但是执行的时间长,而AOF执行的频率高,执行的时间短,
# 若同时执行两个子进程(RDB子进程、AOF子进程)效率会低(两个子进程都是磁盘读写)
# 但是若改为yes可能造成的后果是,由于RDB持久化执行时间长,在这段时间内有很多命令写入了内存队列,
# 最后导致队列放不下,这样AOF写入到AOF文件中的命令可能就少了很多
# 在恢复数据的时候,根据aof文件恢复就会丢很多数据
# 所以,选择no就好
no-appendfsync-on-rewrite no

# AOF重写:把内存中的数据逆化成命令,然后将这些命令重新写入aof文件
# 重写的目的:假设在我们在内存中对同一个key进行了100次操作,最后该key的value是100,
# 那么在aof中就会存在100条命令日志,这样的话,有两个缺点:
# 1)AOF文件过大,占据硬盘空间 2)根据AOF文件恢复数据极慢(需要执行100条命令)
# 如果我们将内存中的该key逆化成"set key 100",然后写入aof文件,
# 那么aof文件的大小会大幅度减少,而且根据aof文件恢复数据很快(只需要执行1条命令)
# 注意:下边两个约束都要满足的条件下,才会发生aof重写;
# 假设没有第二个,那么在aof的前期,只要稍微添加一些数据,就发生aof重写
# 当aof的增长的百分比是原来的100%(即是原来大小的2倍,例如原来是100m,下一次重写是当aof文件是200m的时候),AOF重写
auto-aof-rewrite-percentage 100  
auto-aof-rewrite-min-size 64mb   #AOF重写仅发生在当aof文件大于64m时

appendonly no暗中同意关闭aof方式 大家更改成yes 就拉开

说明:

上面那多少个是暗许的aof文件名

 

注意:

再往下拉:

图片 3

总结:

 

那边是三种协同战略:

always 是 只要产生改善,马上同步 (推荐实用 安全性最高)

everysec 是 每秒同步叁遍

no是分裂步 

 

大家改善成always

 

接下来保存 退出;

 

大家再次起动redis,然后随意加几个key

 

图片 4

 

此处就有三个appendonly.aof文件;

 

aof情势恢复生机数据

 

咱俩先重新初始化数据

[root@localhost redis]# rm -rf dump.rdb 

[root@localhost redis]# ll

总用量 48

drwxr-xr-x. 2 root root   134 7月  18 11:05 bin

-rw-r--r--. 1 root root 46698 7月  18 12:14 redis.conf

 

启动redis

[root@localhost redis]# ./bin/redis-server ./redis.conf 

[root@localhost redis]# ./bin/redis-cli

127.0.0.1:6379> keys *

(empty list or set)

近日数据库是空

 

加上数据

127.0.0.1:6379> set n1 1

OK

127.0.0.1:6379> set n2 2

OK

127.0.0.1:6379> set n3 3

OK

127.0.0.1:6379> shutdown nosave

not connected> exit

[root@localhost redis]# ll

总用量 52

-rw-r--r--. 1 root root   107 7月  18 12:17 appendonly.aof

drwxr-xr-x. 2 root root   134 7月  18 11:05 bin

-rw-r--r--. 1 root root 46698 7月  18 12:14 redis.conf

[root@localhost redis]# 

 

大家把aof文件剪切到另各州点去 然后开发银行试下

[root@localhost redis]# mv appendonly.aof /root/

[root@localhost redis]# ll

总用量 48

drwxr-xr-x. 2 root root   134 7月  18 11:05 bin

-rw-r--r--. 1 root root 46698 7月  18 12:14 redis.conf

[效率相对RDB方式低很多,实际中使用的配置(在redis.conf)。root@localhost redis]# ./bin/redis-server ./redis.conf 

[root@localhost redis]# ./bin/redis-cli

127.0.0.1:6379> keys *

(empty list or set)

没数据;

 

大家再把aof文件复制回来;

[root@localhost redis]# cp /root/appendonly.aof /usr/local/redis/

cp:是还是不是覆盖"/usr/local/redis/appendonly.aof"? y

[root@localhost redis]# ll

总用量 52

-rw-r--r--. 1 root root   107 7月  18 12:22 appendonly.aof

drwxr-xr-x. 2 root root   134 7月  18 11:05 bin

-rw-r--r--. 1 root root 46698 7月  18 12:14 redis.conf

[root@localhost redis]# ./bin/redis-server ./redis.conf 

[root@localhost redis]# ./bin/redis-cli

127.0.0.1:6379> keys *

1) "n1"

2) "n3"

3) "n2"

 

大家开掘 以致有多少了

 

小结: 大家一向得以把aof文件准期备份 然后需求的时候 拷贝到redis下 重启就可以;

下一篇:没有了