Redis - redis.conf配置文件及数据持久化方案

最新推荐文章于 2025-04-19 13:58:39 发布

九月清晨柳成荫

最新推荐文章于 2025-04-19 13:58:39 发布

阅读量1w

点赞数 3

分类专栏： Redis 文章标签： Redis RDB AOF Redis持久化

本文链接：https://blog.csdn.net/qq_40885085/article/details/104090345

版权

Redis 专栏收录该内容

14 篇文章

订阅专栏

本文深入解析Redis的配置文件redis.conf，详细介绍了Redis的持久化策略，包括RDB快照和AOF日志模式。RDB在指定时间间隔保存数据集快照，适合备份；AOF记录所有写操作，保证数据完整性，但可能增加性能开销。文章还讨论了混合持久化以及如何权衡两者以优化性能。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

redis.conf配置文件

1、单位

配置文件在unit单位上对大小写不敏感。

2、包含

redis.conf可以包含其他的redis.conf文件来组合成一个redis.conf，类似于Spring配置文件中的import。

3、网络

bind：绑定的ip，默认的127.0.0.1表示只有本机能访问，如果要配置多个ip，可以使用空格隔开，如果所有ip都能访问，则配置为*即可。

bind 127.0.0.1      # 绑定ip
protected-mode yes  # 保护模式是否开启
port 6379           # 启动端口

4、通用 GENERAL

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

5、快照

快照，即持久化。在规定的时间内执行了多少次操作，就会持久化到文件.rdb或.aof（根据持久化规则来说）。

Redis是内存数据库，如果没有持久化，则断电数据就会丢失。

具体配置请见下面的RDB持久化部分。

6、REPLICATION 复制

这里不谈，后面主从复制的文章再写。

7、SECURITY 安全

可以在这里设置redis的密码，默认是没有密码，但是一般不会修改配置文件，而是通过命令。

127.0.0.1:6379> ping 
PONG 
127.0.0.1:6379> config get requirepass   # 获取redis的密码 
1) "requirepass" 
2) "" 
127.0.0.1:6379> config set requirepass "123456"   # 设置redis的密码 
OK 
127.0.0.1:6379> config get requirepass   # 发现所有的命令都没有权限了 
(error) NOAUTH Authentication required. 
127.0.0.1:6379> ping 
(error) NOAUTH Authentication required. 
127.0.0.1:6379> auth 123456  # 使用密码进行登录！ 
OK 
127.0.0.1:6379> config get requirepass 
1) "requirepass" 
2) "123456"

8、APPEND ONLY 模式 - AOF配置

appendonly no    # 默认是不开启aof模式的，默认是使用rdb方式持久化的，在大部分所有的情况下， rdb完全够用！ 
appendfilename "appendonly.aof"  # 持久化的文件的名字
# appendfsync always   # 每次修改都会 sync。消耗性能 
appendfsync everysec   # 每秒执行一次 sync，可能会丢失这1s的数据 
# appendfsync no       # 不执行sync，这个时候操作系统自己同步数据，速度快

数据持久化

Redis的高性能是由于其将所有数据都存储在了内存中，为了使Redis在重启之后仍能保证数据不丢失，需要将数据从内存中同步到硬盘中，这一过程就是持久化。

Redis支持两种方式的持久化,可以单独使用其中一种或将二者结合使用。

RDB持久化（默认支持，无需配置）

该机制是指在指定的时间间隔内将内存中的数据集快照写入磁盘。

AOF持久化

该机制将以日志的形式记录服务器所处理的每一个写操作，在Redis服务器启动之初会读取该文件来重新构建数据库，以保证启动后数据库中的数据是完整的。

无持久化

我们可以通过配置的方式禁用Redis服务器的持久化功能，这样我们就可以将Redis视为一个功能加强版的Memcached(一个自由开源的，高性能，分布式内存对象缓存系统)了。

RDB持久化机制

RDB持久化机制优点

一旦采用该方式，那么你的整个Redis数据库将只包含一个文件，这对于文件备份而言是非常完美的。

RDB持久化机制缺点

1.如果想保证数据的高可用性，即最大限度的避免数据丢失，那么RDB将不是一个很好的选择。因为系统一旦在定时持久化之前出现宕机现象，此前没有来得及写入磁盘的数据都将丢失。
2.由于RDB是通过fork子进程来协助完成数据持久化工作的，因此，如果当数据集较大时，可能会导致整个服务器停止服务几百毫秒，甚至是1秒钟。

快照与备份

快照是数据存储的某一时刻的状态记录。

备份则是数据存储的某一个时刻的副本。

快照触发条件

1.客户端执行命令save和bgsave会生成快照；
2.根据配置文件save m n规则进行自动快照；
3.主从复制时，从库全量复制同步主库数据，此时主库会执行bgsave命令进行快照；
4.客户端执行数据库清空命令FLUSHALL时候，触发快照；
5.客户端执行shutdown关闭redis时，触发快照；

RDB持久化机制的配置

# 如果900s内，如果至少有一个1个key进行了修改，就进行持久化操作 
save 900 1 
# 如果300s内，如果至少10个key进行了修改，就进行持久化操作 
save 300 10 
# 如果60s内，如果至少10000个key进行了修改，就进行持久化操作 
save 60 10000 
# 关闭该规则使用save “ ” 

# yes代表当使用bgsave命令持久化出错时候停止写RDB快照文件,no表明忽略错误继续写文件。
stop-writes-on-bgsave-error yes   
# # 是否压缩 rdb 文件，需要消耗一些cpu资源，该功能可以节约磁盘空间。
rdbcompression yes                
# 在写入文件和读取文件时是否开启rdb文件检查，检查是否有无损坏，如果在启动是检查发现损坏，则停止启动
rdbchecksum yes
# 持久化文件名
dbfilename dump.rdb       
# 数据文件存放目录，rdb快照文件和aof文件都会存放至该目录，请确保有写权限        
dir ./

AOF持久化机制

当redis存储非临时数据时，为了降低redis故障而引起的数据丢失，redis提供了AOF(Append Only File)持久化，从单词意思讲，将命令追加到文件。AOF可以将Redis执行的每一条写命令追加到磁盘文件(appendonly.aof)中
在redis启动时候优先选择从AOF文件恢复数据。由于每一次的写操作，redis都会记录到文件中，所以开启AOF持久化会对性能有一定的影响。

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

AOF持久化数据丢失更少，其消耗内存更少(RDB方式执行bgsave会有内存拷贝)

开启AOF持久化

默认情况下，redis是关闭了AOF持久化，开启AOF通过配置appendonly为yes开启。将appendonly修改为yes，开启aof持久化机制，默认会在目录下产生一个appendonly.aof文件。修改配置文件或者在命令行直接使用config set修改，再用config rewrite同步到配置文件。通过客户端修改好处是不用重启redis，AOF持久化直接生效。
config get appendonly 查询配置状态
config set appendonly yes 修改配置，命令生效了，但配置文件里没有生效

config rewrite 写入到redis.conf中，配置文件生效

AOF配置

appendonly no   # 默认是不开启aof模式的，默认使用rdb方式进行持久化，大部分情况rdb够用
appendfsync always       # 每执行一次更新命令，持久化一次
appendfsync everysec     # 每秒钟持久化一次
appendfsync no           # 不持久化

AOF文件错误

如果这个 aof 文件有错误，这时候 redis 是启动不起来的，我们需要修复这个aof文件 redis 给我们提供了一个工具 redis-check-aof --fix 。

redis-check-aof --fix appendonly.aof

这个工具可以修复错误，但是可能会造成一部分数据丢失(出现错误的那部分数据)。

AOF重写规则

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

如果 aof 文件大于 64m，太大了。 fork一个新的进程来将我们的文件进行重写。

优点

每一次修改都同步，文件的完整会更加好

缺点

1、相对于数据文件来说，aof远远大于 rdb，修复的速度也比 rdb慢。

2、Aof 运行效率也要比 rdb 慢，所以我们redis默认的配置就是rdb持久化。

RDB-AOF混合持久化

通过aof-use-rdb-preamble配置参数控制，yes则表示开启，no表示禁用，默认是禁用的，可通过config set修改。

持久化扩展

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 900 1 这条规则。

如果Enable AOF ，好处是在恶劣情况下也只会丢失不超过两秒数据，启动脚本较简单只load自己的AOF文件就可以了，代价一是带来了持续的IO，二是AOF rewrite 的后将 rewrite 过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。只要硬盘许可，应该尽量减少AOF rewrite 的频率，AOF重写的基础大小默认值64M太小了，可以设到5G以上，默认超过原大小100%大小重写可以改到适当的数值。

如果不Enable AOF ，仅靠 Master-Slave Repllcation 实现高可用性也可以，能省掉一大笔IO，也减少了rewrite时带来的系统波动。代价是如果Master/Slave 同时倒掉，会丢失十几分钟的数据，启动脚本也要比较两个 Master/Slave 中的 RDB文件，载入较新的那个，微博就是这种架构。