这篇博客主要讲解的是在Redis中关于conf文件的详细作用。由于这个文件十分重要,学习这个文件的相关配置可以让我们在面对不同企业的一些特定的功能的时候如鱼得水,所以我觉得有必要抽出来一篇博客总结一下关于conf文件的相关知识。
由于这是Redis系列博客,看不太明白的可以看看我博客里关于Redis其他的博客串起来方便理解。
Redis.conf,是Redis开启时的必须文件,也是Redis的核心配置文件,本文将介绍Redis的核心配置文件的各个字段的作用
Redis.conf详解
单位
配置文件 unit单位 对大小写不敏感
# units are case insensitive so 1GB 1Gb 1gB are all the same.
包含
# include /path/to/local.conf
# include /path/to/other.conf
类似于Spring、Import、include
网络
bind 127.0.0.1 # 绑定的ip
protected-mode yes # 保护模式
port 6379 # 端口设置
通用设置 GENERAL
daemonize yes # 以守护进程的方式运行,默认是 no,需要改为yes
supervised no # 管理守护进程的,默认是no,一般不需要改动
pidfile /www/server/redis/redis.pid # 如果是以后台的模式运行,则需要指定一个pid文件
# 日志
# Specify the server verbosity level.
# This can be one of:
# debug (a lot of information, useful for development/testing)
# verbose (many rarely useful info, but not a mess like the debug level)
# notice (moderately verbose, what you want in production probably) 生产环境
# warning (only very important / critical messages are logged)
loglevel notice
logfile "" # 日志的文件位置名,如果是空则是标准的输出形式
databases 16 # 数据库的数量,默认是16数据库
always-show-log yes # 是否总是显示LOGO
快照 SNAPSHOTTING
持久化的时候使用,在规定的时间内,执行了多少次操作,则会持久化到文件.rdb.aof
redis是内存数据库,如果没有持久化,那么数据库断电即失
# 如果900s内,至少有1个key进行了修改,那么就进行持久化操作
save 900 1
# 如果300s内,至少有10个key进行了修改,那么就进行持久化操作
save 300 10
# 如果60s内,至少有10000个key进行了修改,那么就进行持久化操作
save 60 10000
# 这个是可以自定义进行持久化操作,但是注意,save命令会阻塞Redis服务器进程,知道RDB文件创建完毕位置,在此期间服务器不能处理任何命令的请求
stop-writes-on-bgsave-error yes #持久化出错,是否还需要继续工作
rdbcompression yes # 是否压缩 rdb 文件(持久化文件),需要消耗一些CPU的资源
rdbchecksum yes # 保存rdb文件的时候,进行错误检查校验
dbfilename dump.rdb #rdb保存的文件名
dir ./ # rdb文件保存的目录
主从复制 REPLICATION
replica-serve-stale-data yes #主从复制中,从服务器可以响应客户端请求
安全 SECURITY
requirepass 自己的密码 #用于连接时的密码验证
config get requirepass #获取redis密码
限制 CLIENTS
maxclients 10000 # 设置能连接上redis的最大客户端数量
maxmemory<bytes> # redis配置最大的内存容量
maxmemory-policy noeviction # 内存达到上限后的处理策略,例如移除一些过期的key
1、volatile-lru:只对设置了过期时间的key进行LRU(默认值)
2、allkeys-lru : 删除lru算法的key
3、volatile-random:随机删除即将过期key
4、allkeys-random:随机删除
5、volatile-ttl : 删除即将过期的
6、noeviction : 永不过期,返回错误
aof配置 APPEND ONLY
appendonly no #默认不开启aof模式,默认是使用rdb方式持久化的,大部分情况rdb完全够用appendfilename "appendonly.aof" #持久化的文件名称 .rdb# appendfsync always #每次修改都会sync,消耗性能appendfsync everysec #每秒执行一次 sync,可能会丢失这1s的数据# appendfsync no #不进行sync,这个时候操作系统自己进行sync,速度最快,一般不用auto-aof-rewrite-percentage 100 # 重写规则的比例是100auto-aof-rewrite-min-size 64mb # 重写规则的最小值是64mb
Reids持久化
Redis是内存数据库,如果不将内存中的数据库状态保存到磁盘,那么一旦服务器进程退出,服务器中的数据库状态也会消失。所以Redis提供了持久化功能
RDB(Redis DataBase)
什么是RDB
在主从复制中,rdb就是用来备用的
在指定的时间间隔内将内存中的数据集快照写入磁盘,也就是行话讲的Snapshot快照,它恢复时是将快照文件直接读到内存里。
Redis会单独创建(( fork )一个子进程来进行持久化,会先将数据写入到一个临时文件中,待持久化过程都结束了,再用这个临时文件替换上次持久化好的文件。整个过程中,主进程是不进行任何IO操作的。这就确保了极高的性能。如果需要进行大规模数据的恢复,且对于数据恢复的完整性不是非常敏感,那RDB方式要比AOF方式更加的高效。
RDB的缺点是最后一次持久化后的数据可能丢失。
默认使用的就是RDB方式,一般情况下不需要修改这个配置
rdb保存的文件是 dump.rdb
,都是在配置文件中快照进行配置的,有时候在生成环境中会将这个文件进行备份,因为这个文件极其重要。
dump.rdb的触发机制
- save的规则满足的情况下,会自动触发rdb规则
- 执行
flushall
命令,也会触发rdb规则 - 退出redis,也会生成rdb文件
备份就自动生成一个dump.rdb
恢复rdb文件
1、只需要将rdb文件放在redis启动目录就可以了,redis启动的时候会自动检查dumop.rdb恢复其中的数据
2、查看需要存在的位置
127.0.0.1:6379> config get dir1) "dir"2) "/usr/local/bin" #如果在这个目录下存在dump.rdb文件,启动就会自动恢复其中的数据
优点:
- 适合大规模的数据恢复 dump.rdb
- 对数据的完整性要求不高
缺点:
- 需要一定的时间间隔进程操作。如果redis意外宕机了,最后一次修改数据就没了
- fork进程的时候,会占用一定的内存空间
AOF(Append Only File)
说的通俗一点,就是用一个文件将所有的命令全部记录下来组成一个history,恢复的时候就把这个文件再执行一遍一样,类似SQL文件。
AOF是什么
以日志的形式来记录每个写操作,将Redis执行过的所有指令记录下来(读操作不记录),只许追加文件但不可以改写文件,redis启动之初会读取该文件重新构建数据,换言之,redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。
AOF保存的文件名是appendonly.aof
append
默认是不开启的,需要手动进行配置。
appendonly yes
重启,redis就可以生效了
如果aof文件出现错误,redis是启动不起来的,利用redis-check-aof
进行修复文件
redis-check-aof --fix appendonly.aof
优点:
- appendfsync always:每一次修改都同步,文件的完整会很好
- appendfsync always:每秒同步一次,可能会丢失一秒的数据
- appendfsync no:从不同步,效率最高
缺点:
- 相当于数据文件来说,aof的文件远远大于rdb文件大小,修复的速度也比rdb慢
- aof运行效率也比rdb慢,所以redis默认的配置就是rdb持久化
扩展
1、RDB持久化方式能够在指定的时间间隔内对你的数据进行快照存储
2、AOF 持久化方式记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据, AOF命令以Redis协议追加保存每次写的操作到文件末尾,Redis还能对AOF文件进行后台重写,使得AOF文件的体积不至于过大。
3、只做缓存,如果你只希望你的数据在服务器运行的时候存在,你也可以不使用任何持久化
4、同时开启两种持久化方式
- 在这种情况下,当redis重启的时候会优先载入AOF文件来恢复原始的数据,因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整。
- RDB的数据不实时,同时使用两者时服务器重启也只会找AOF文件,那要不要只使用AOF呢?作者建议不要,因为RDB更适合备份数据库(AOF在不断变化不好备份),快速重启,而且不会有AOF可能潜在的bug,留着作为万一的手段
5、性能建议
- 因为RDB文件只用作后备用途,建议只在Slave上持久化RDB文件,而且只要15分钟备份一次就够了,只保留save 9001这条
- 如果Enable AOF , 好处是在最恶劣情况下也只会丢失不超过两秒数据,启动脚本较简单只load自己的AOF文件就可以了,代价一是带来 了持续的I0 ,二是AOF rewrite的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。只要硬盘许可,应该尽量减少AOF rewrite的频率, AOF重写的基础大小默认值64M太小了,可以设到5G以上,默认超过原大小100%大小重写可以改到适当的数值。
- 如果不Enable AOF , 仅靠Master-Slave Repllcation实现高可用性也可以,能省掉一-大笔I0 ,也减少了rewrite时带来的系统波动。代价是如果Master/Slave 同时倒掉,会丢失十几分钟的数据,启动脚本也要比较两个Master/Slave中的RDB文件,载入较新的那个,微博就是这种架构。
如果你觉得这篇文章对您有帮助的话,麻烦帮我点个点个赞关注一下吧,创作不易,有你的支持才是我前进的动力~