↓跳到主要内容
  1. 所有文章/
  2. Redis相关笔记/

Redis配置文件和持久化

·📄 3156 字·🍵 7 分钟
技术探索 Redis
目录

Redis配置文件 #

文件位置 #

windows：安装目录下：redis.windows.conf

Linux：安装目录下：config/redis.conf

一般配置 #

可以设置单位大小，且大小写不敏感

image-20220305140046763.png

可以使用多个配置文件，组合成一个

image-20220305140635511.png

网络配置 #

bind 127.0.0.1   # 绑定的ip，默认只能在本机访问
protected-mode yes # 保护模式，默认开启
port 6379    # 端口设置

通用配置 #

daemonize yes  # 以守护进程的方式运行，默认是no，需要自己开启为yes
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)
# 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-logo yes # 开启redis服务端时是否显示logo

密码配置 #

可以在配置文件中配置密码，也可以在这里设置Redis的密码，默认是没有密码的

requirepass  "123456"

127.0.0.1:6379> config get requirepass  # 获取redis的密码
1) "requirepass"
2) ""
127.0.0.1:6379> config set requirepass "123456"  # 设置redis密码
OK 
auth 123456 # 输入密码后才可以登录

客户端配置 #

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

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

maxmemory-policy noeviction  # 内存达到上限的处理策略
  
#noeviction: 不删除策略, 达到最大内存限制时, 如果需要更多内存, 直接返回错误信息。（默认值）
#allkeys-lru: 所有key通用; 优先删除最近最少使用(less recently used ,LRU) 的 key。
#volatile-lru: 只限于设置了 expire 的部分; 优先删除最近最少使用(less recently used ,LRU) 的 key。
#allkeys-random: 所有key通用; 随机删除一部分 key。
#volatile-random: 只限于设置了 expire 的部分; 随机删除一部分 key。
#volatile-ttl: 只限于设置了 expire 的部分; 优先删除剩余时间(time to live,TTL) 短的key。

#redis中并不会准确的删除所有键中最近最少使用的键，而是随机抽取maxmeory-samples个键，删除这三个键中最近最少使用的键。

Redis持久化机制 #

为了能够重用Redis数据，或者防止系统故障，我们需要将Redis中的数据写入到磁盘空间中，即持久化。

Redis提供了两种不同的持久化方法可以将数据存储在磁盘中，一种叫快照RDB，另一种叫只追加文件AOF。

选择合适的持久化方式 #

  • 如果是数据不那么敏感，且可以从其他地方重新生成补回的，那么可以关闭持久化。
  • 如果是数据比较重要，不想再从其他地方获取，且可以承受数分钟的数据丢失，比如缓存等，那么可以只使用RDB。
  • 如果是用做内存数据库，要使用Redis的持久化，建议是RDB和AOF都开启，或者定期执行bgsave做快照备份，RDB方式更适合做数据的备份，AOF可以保证数据的不丢失。

补充：Redis4.0 对于持久化机制的优化

Redis4.0相对与3.X版本其中一个比较大的变化是4.0添加了新的混合持久化方式。

简单的说：新的AOF文件前半段是RDB格式的全量数据后半段是AOF格式的增量数据，如下图：

1075473-20180726181756270-1907770368.png

优势：混合持久化结合了RDB持久化 和 AOF 持久化的优点， 由于绝大部分都是RDB格式，加载速度快，同时结合AOF，增量的数据以AOF方式保存了，数据更少的丢失。

劣势：兼容性差，一旦开启了混合持久化，在4.0之前版本都不识别该aof文件，同时由于前部分是RDB格式，阅读性较差。

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

RDB(Redis Database)方式 #

在指定的时间间隔内将内存中的数据集快照写入磁盘(Snapshot)，它恢复时是将快照文件直接读到内存里。

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

image-20220305143320464.png

RDB配置 #

持久化，在规定的时间内，执行了多少次操作，则会持久化到文件 .rdb .aof

Redis是内存数据库，如果没有持久化，那么数据断电即失去。

# Save the DB on disk:
#   save <seconds> <changes>
#   Will save the DB if both the given number of seconds and the given
#   number of write operations against the DB occurred.
#   In the example below the behaviour will be to save:
#   after 900 sec (15 min) if at least 1 key changed
#   after 300 sec (5 min) if at least 10 keys changed
#   after 60 sec if at least 10000 keys changed
# 如果900秒内至少有一个key进行了修改，我们就进行持久化操作
save 900 1
save 300 10
save 60 10000
stop-writes-on-bgsave-error yes # 持久化出错后是否继续工作
rdbcompression yes # 是否压缩rdb文件，需要消耗一些cpu的资源
rdbchecksum yes  # 报错rdb文件时候进行错误的检查校验
dir ./ # rdb文件保存的目录，默认为当前目录
dbfilename dump.rdb #保存的rdb文件名

触发机制 #

  1. save规则满足的情况下，会自动触发rdb规则
  2. 执行flushall命令也会触发rdb规则
  3. 退出Redis，也会产生rdb

触发后生成一个 dump.rdb 文件保存（文件名可以自己配置）

如何恢复rdb文件 #

只需要将rdb文件放在Redis的启动目录下就可以了，Redis启动的时候会自动检查dump.rdb文件恢复

#查看我们的 dump.rdb 文件放在什么位置
127.0.0.1:6379> config get dir
1) "dir"
2) "/usr/local/redis-6.0.6/bin"  #如果在这个目录下存在dump.rdb文件，启动就会自动恢复其中的数据

优劣势 #

一般情况下，Redis默认就是使用RDB来持久化。

优势：适合大规模的数据恢复；对数据完整性和一致性要求不高

劣势：在一定间隔时间做一次备份，所以如果Redis意外down掉的话，就会丢失最后一次快照后的所有修改。

AOF(Append Only File)方式 #

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

AOF采用文件追加方式，文件会越来越大，为避免出现此种情况，新增了重写机制，当AOF文件的大小超过所设定的阈值时， Redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集.。

3eb0e5a9501dfa3228e646cb18d34e44.png

AOF保存的是appendonly.aof文件。默认是不开启的，我们需要手动进行配置，我们只需要将appendonly改为yes即可。重启Redis就可以生效了。

AOF配置 #

appendonly no  # 默认不开启aof模式，默认使用rdb方式持久化，几乎在所有情况下rdb够用

appendfilename "appendonly.aof" # 持久化文件的名字

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

修复文件 #

如果这个aof文件有错误，这时候Redis是启动不起来的，我们需要修复这个aof文件

Redis给我们提供了redis-check-aof --fix appendonly.aof来进行appendonly.aof的修复

如果文件正常，重启就可以直接恢复了。

0d004c953c67eb5e72b536d4229866ff.png

优劣势 #

优势

  • 每修改同步：appendfsync always 同步持久化，每次发生数据变更会被立即记录到磁盘，性能较差但数据完整性比较好
  • 每秒同步：appendfsync everysec 异步操作，每秒记录，如果一秒内宕机，有数据丢失
  • 不同步：appendfsync no 从不同步

劣势

  • 相同数据集的数据而言aof文件要远大于rdb文件，恢复速度慢于rdb
  • aof运行效率要慢于rdb，每秒同步策略效率较好，不同步效率和rdb相同

重写规则说明 #

如果aof文件大于64MB，那么Redis就会fork一个新的进程来将我们文件进行重写。

aof默认就是文件的无限追加，文件会越来越大。

no-appendfsync-on-rewrite no #默认不重写

# Automatic rewrite of the append only file.
# Redis is able to automatically rewrite the log file implicitly calling
# BGREWRITEAOF when the AOF log size grows by the specified percentage.
#
# This is how it works: Redis remembers the size of the AOF file after the
# latest rewrite (if no rewrite has happened since the restart, the size of
# the AOF at startup is used).
#
# This base size is compared to the current size. If the current size is
# bigger than the specified percentage, the rewrite is triggered. Also
# you need to specify a minimal size for the AOF file to be rewritten, this
# is useful to avoid rewriting the AOF file even if the percentage increase
# is reached but it is still pretty small.
#
# Specify a percentage of zero in order to disable the automatic AOF
# rewrite feature.

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
↑ ↓