经验首页 前端设计 程序设计 Java相关 移动开发 数据库/运维 软件/图像 大数据/云计算 其他经验
当前位置:技术经验 » 数据库/运维 » Redis » 查看文章
【数据库】Redis(4)--Redis进阶Redis配置与持久化
来源:cnblogs  作者:人无名,则可专心练剑  时间:2021/4/6 9:42:56  对本文有异议

1.Redis.conf配置文件说明

Redis的配置文件涉及Redis启动运行的一些重要参数,也是Redis哨兵和Redis集群配置相关依赖的重要文件。熟悉redis.config文件的配置是非常有必要的。

下面来简单说明一下redis.conf中的主要配置:

①include:包含

类似于Spring的配置文件,可以通过includes包含其它的配置文件,而redis.conf作为总的文件

 

②network:网络配置

 

常用的配置修改如下:

  1. bind 127.0.0.1 #修改绑定的ip
  2. protected-mode yes #是否受保护的模式,默认为是
  3. port 6379 #默认端口修改

 

③general:通用配置

 

 主要常用的配置修改如下:

  1. daemonize yes #以守护进程的方式运行,默认是no,需要手动修改为yes
  2. pidfile /var/run/redis_6379.pid #如果以后台方式运行,就需要指定一个pid文件

    #日志级别配置

# Specify the server verbosity level.
# This can be one of:
# debug (a lot of information, useful for development/testing)  #debug,测试开发阶段使用
# verbose (many rarely useful info, but not a mess like the debug level)
# notice (moderately verbose, what you want in production probably)  #notice,默认在生产环境使用
# warning (only very important / critical messages are logged)  #警告级别
loglevel notice

logfile ""  #配置生成的文件名,可以修改存放地址信息

databases 16  #配置数据库的数量,默认是16个

always-show-logo yes   #默认显示LOGO信息

 

④SNAPSHOTTING快照:

主要用于持久化操作,在规定的时间内,执行了多少次操作,则会持久化到.rdb文件或者.aof文件。

redis是内存数据库,如果没有持久化配置,则断点即失。

 

  1.  
  1. #如果900s以内至少有1个key进行了修改,那么就进行持久化操作
  1. save 900 1
  1. #如果300s以内至少有10个key进行了修改,那么就进行持久化操作
  1. save 300 10
  1. #如果60s以内至少有10000个key进行了修改,那么就进行持久化操作
  1. save 60 10000
    #如果持久化出错,是否还需要redis继续工作
    stop-writes-on-bgsave-error yes
    #是否压缩rdb文件,需要消耗一些cpu资源
    rdbcompression yes
    #保存rdb文件的时候进行错误的检验
    rdbchecksum yes
    #rdb文件保存的目录,默认在当前目录下
    dir ./

 

⑤security安全:

可以进行redis登陆的密码设置,一般使用命令行命令进行设置:

 

  1. 127.0.0.1:6379> config get requirepass #获取redis的密码
  2. 1) "requirepass"
  3. 2) ""
  4. 127.0.0.1:6379> config set requirepass "123456" #设置redis的密码
  5. OK
  6. 127.0.0.1:6379> config get requirepass
  7. (error) NOAUTH Authentication required.
  8. 127.0.0.1:6379> auth 123456 #登录验证密码
  9. OK

 

⑥限制CLIENTS、MEMORY MANAGEMENT

设置能连接上redis的最大客户端数量

 

  1. maxclients 10000 #设置能连接上redis的最大客户端的数量

  maxmemory <bytes>  #设置redis配置最大的内存容量

  maxmemory-policy noeviction   #内存到达上限之后的处理策略

  volatile-lru:只对设置了过期时间的key进行LRU(默认值) 
  allkeys-lru : 删除lru算法的key   
  volatile-random:随机删除即将过期key   
  allkeys-random:随机删除   
  volatile-ttl : 删除即将过期的   
  noeviction : 永不过期,返回错误 

 

⑦APPEND ONLY MODE模式,aof配置:

  1. appendonly no #默认是不开启aof模式的,默认是使用rdb持久化方式的,大部分情况下,rdb完全够用
    appendfilename "appendonly.aof" #持久化文件的名字

  # appendfsync always  #每次修改都会同步sync,消耗性能
  appendfsync everysec  #每秒执行一次sync,可能会丢失1s的数据
  # appendfsync no      #不执行同步,操作系统自己同步数据,性能最快

 

2.Redis持久化

Redis 是内存数据库,如果不将内存中的数据库状态保存到磁盘,那么一旦服务器进程退出,服务器中 的数据库状态也会消失。所以 Redis 提供了持久化功能!

Redis的持久化提供了两种持久化方式:RDB与AOF方式。

2.1.RDB(Redis DataBase)

RBD持久化方式会在指定的时间间隔内将内存中的数据集快照写入到磁盘,也就是Snapshot快照方式。它恢复时是将快照文件直接读到内存里。

Redis会单独创建(fork)一个子进程来进行持久化,会先将数据写入到一个临时文件中,待持久化过程 都结束了,再用这个临时文件替换上次持久化好的文件。整个过程中,主进程是不进行任何IO操作的。 这就确保了极高的性能。如果需要进行大规模数据的恢复,且对于数据恢复的完整性不是非常敏感,那 RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失(redis服务宕机)。

RDB是我们默认的持久化方式,一般情况下我们不需要修改这个配置。

 

 

 

RDB方式保存的文件是dump.rdb文件。

 

触发机制

1.save的规则满足的情况下,会自动触发rdb规则。

2.执行flushall命令,也会触发rdb规则。

3.退出redis,也会产生rdb文件。系统在备份时会自动生成一个dump.rdb文件。

 

恢复RDB文件数据:

1.将备份文件(dump.rdb)移动到redis安装目录并启动服务即可;

2.查看文件存放目录:

  1. 127.0.0.1:6379> config get dir
  2. 1) "dir"
  3. 2) "/usr/local/bin"

 

RDB持久化优缺点:

优点:

1.适合做大规模的数据恢复;

2.对数据完整性和一致性要求不高;

缺点:

1.在一定间隔时间做一次备份,所以如果redis以外宕机的话,就会丢失掉最后一次快照后的所有修改;

2.Fork父进程的时候,内存中的数据被克隆了一份,需要考虑内存空间被占用。

 

2.2.AOF(Append Only File)

Redis的AOF保存形式会以日志的形式来记录每个写操作,将Redis执行过的所有指令记录下来(读操作不记录),只许追加文件但不可以改写文件,redis启动之初会读取该文件重新构建数据,换言之,redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。

 

Redis配置AOF的方式:

默认是不开启AOF的,我们需要手动进行配置,将appendonly no改为yes就开启了aof,重启之后redis就生效了。

如果过程中aof有错位或者异常损坏,这时redis是启动不了的,我们需要修复aof这个文件。而redis给我们提供了一个工具:

redis-check-aof  --fix

  1. #切换到redis-conf目录:
  2. redis-check-aof --fix appendonly.aof

 

 

AOF文件相关配置项:

  1. appendonly no # 是否以append only模式作为持久化方式,默认使用的是rdb方式持久化(no),启用aof需要设置为yes
  2. appendfilename "appendonly.aof" # appendfilename AOF 文件名称
  3. appendfsync everysec # appendfsync aof持久化策略的配置
  4. # no表示不执行fsync,由操作系统保证数据同步到磁盘,速度最快。
  5. # always表示每次写入都执行fsync,以保证数据同步到磁盘。
  6. # everysec表示每秒执行一次fsync,可能会导致丢失这1s数据。
  7. No-appendfsync-on-rewrite #重写时是否可以运用Appendfsync,用默认no即可,保证数据安全性
  8. Auto-aof-rewrite-min-size # 设置重写的基准值
  9. Auto-aof-rewrite-percentage #设置重写的基准值

 

AOF优点和缺点:

优点:

1.每修改同步:appendfsync always 同步持久化,每次发生数据变更会被立即记录到磁盘,性能较差 但数据完整性比较好;

2.每秒同步:appendfsync everysec异步操作,每秒记录,如果一秒宕机,有数据丢失;

缺点:

1.相同数据集的数据而言,aof 文件要远大于 rdb文件,恢复速度慢于 rdb。

2.Aof 运行效率要慢于 rdb,每秒同步策略效率较好,不同步效率和rdb相同。

 

原文链接:http://www.cnblogs.com/yif0118/p/14573332.html

 友情链接:直通硅谷  点职佳  北美留学生论坛

本站QQ群:前端 618073944 | Java 606181507 | Python 626812652 | C/C++ 612253063 | 微信 634508462 | 苹果 692586424 | C#/.net 182808419 | PHP 305140648 | 运维 608723728

W3xue 的所有内容仅供测试,对任何法律问题及风险不承担任何责任。通过使用本站内容随之而来的风险与本站无关。
关于我们  |  意见建议  |  捐助我们  |  报错有奖  |  广告合作、友情链接(目前9元/月)请联系QQ:27243702 沸活量
皖ICP备17017327号-2 皖公网安备34020702000426号