redis 配置文件路径 redis配置文件在哪

目录标题

• 一、Redis的配置文件

• 1、redis.conf的存放位置
• 2、网络相关的配置

• （1）bind
• （2）protected-mode
• （3）tcp-backlog
• （4）timeout
• （5）tcp-keepalive

• 3、常规设置

• （1）daemonize
• （2）pidfile
• （3）loglevel
• （4）logfile
• （5）databases

• 4、安全配置

• （1）requirepass

• 5、限制设置

• （1）maxclients
• （2）maxmemory
• （3)maxmemory-policy

• 6、RDB设置

• （1）save
• （2）rdbcompression
• （3)rdbchecksum
• （4）dbfilename
• （5）dir

• 7、AOF设置

• （1）appendonly
• （2）appendfilename
• （3）appendfsync

• 二、Redis持久化

• 1、RDB

• （1）RDB原理
• （2）RDB 保存的文件
• （3）配置RDB 持久化策略
• （4）RDB备份
• （5）优缺点
• （6）小结

• 2、AOF

• （1）AOF原理
• （2）AOF执行流程
• （3）AOF保存的文件
• （4）AOF数据恢复
• （5）优缺点
• （6）小结

一、Redis的配置文件

1、redis.conf的存放位置

redis在启动的时候会加载这个配置文件，在运行时按照配置文件进行工作。

在这里使用的是我自己自定义的目录下：/usr/local/bin/hconfig/redis.conf

2、网络相关的配置

（1）bind

• 绑定IP地址，其它机器可以通过此IP访问Redis，默认绑定127.0.0.1，也可以修改为本机的IP地址。
• 服务器是需要远程访问的，所以需要将其注释掉
• 如果开启了protected-mode，那么在没有设定bind ip且没有设密码的情况下，Redis只允许接受本机的响应

保存配置，停止服务，重启启动查看进程，发现已经不再是本机访问了

（2）protected-mode

• 将本机访问保护模式设置no

（3）tcp-backlog

• 设置tcp的backlog，backlog其实是一个连接队列，backlog队列总和=未完成三次握手队列 + 已经完成三次握手队列。
• 在 高并发的环境下需要设置一个高的backlog值来避免慢客户端连接问题

（4）timeout

• 一个空闲的客户端维持多少秒会关闭，0表示关闭该功能。即永不关闭。

（5）tcp-keepalive

• TCP连接保活策略，可以通过tcp-keepalive配置项来进行设置，单位为秒，假如设置为60秒，则server端会每60秒向连接空闲的客户端发起一次ACK请求，以检查客户端是否已经挂掉，对于无响应的客户端则会关闭其连接。如果设置为0，则不会进行保活检测。

3、常规设置

（1）daemonize

• 是否为后台进程，设置为yes

（2）pidfile

• 存放pid文件的位置，每个实例会产生一个不同的pid文件

（3）loglevel

• 指定日志记录级别，Redis总共支持四个级别：debug、verbose、notice、warning，默认为notice
• 开发阶段可以设置成debug，生产阶段通常设置为notice或者warning

（4）logfile

• 指定日志文件名，如果不指定，Redis只进行标准输出。
• 要保证日志文件所在的目录必须存在，文件可以不存在。

（5）databases

• 配置Redis数据库的个数，默认是16个。
• 可以使用SELECT 命令在连接上指定数据库id

4、安全配置

（1）requirepass

• 默认不配置密码，即访问不需要密码验证
• 此配置项需要在protected-mode=yes时起作用
• 在命令中设置密码，只是临时的。重启redis服务器，密码就还原了。
• 永久设置，需要再配置文件中进行设置。
• 使用密码登录客户端：redis-cli -h ip -p 6379 -a pwd

5、限制设置

（1）maxclients

• 设置redis同时可以与多少个客户端进行连接。
• 默认情况下为10000个客户端。
• 如果达到了此限制，redis则会拒绝新的连接请求，并且向这些连接请求方发出“max number of clients reached”以作回应。

（2）maxmemory

• 建议必须设置，否则，将内存占满，造成服务器宕机
• 设置redis可以使用的内存量。一旦到达内存使用上限，redis将会试图移除内部数据，移除规则可以通过maxmemory-policy来指定

（3)maxmemory-policy

• 内存达到上限之后的处理策略
• volatile-lru：使用LRU算法移除key，只对设置了过期时间的键；（最近最少使用）
• allkeys-lru：在所有集合key中，使用LRU算法移除key
• volatile-random：在过期集合中移除随机的key，只对设置了过期时间的键
• allkeys-random：在所有集合key中，移除随机的key
• volatile-ttl：移除那些TTL值最小的key，即那些最近要过期的key
• noeviction：不进行移除。针对写操作，只是返回错误信息

6、RDB设置

（1）save

• Redis是内存数据，如果没有持久化，那么断电就会导致数据丢失
• Redis 在seconds秒内key改变changes次，Redis把快照内的数据保存到磁盘中一次

默认策略是：

• 如果900s内，如果至少有1个key进行了修改，我们及时进行持久化操作
• save 900 1
• 如果300s内，如果至少有10个key进行了修改，我们及时进行持久化操作
• save 300 10
• 如果60s内，如果至少有10000个key进行了修改，我们及时进行持久化操作
• save 60 10000

（2）rdbcompression

• 是否压缩rdb文件，但是需要消耗一些CPU资源

（3)rdbchecksum

• 保存 rdb文件的时候，进行错误的检查校验

（4）dbfilename

• Redis持久化数据生成的文件名，默认是dump.rdb，也可以自己配置

（5）dir

• Redis持久化数据生成文件保存的目录，默认是 ./ 即redis的启动目录

7、AOF设置

（1）appendonly

• 配置是否开启AOF，yes表示开启，no表示关闭。默认是no。

（2）appendfilename

• AOF保存文件名

（3）appendfsync

• AOF异步持久化策略

• always：同步持久化，每次发生数据变化会立刻写入到磁盘中。性能较差但数据完整性比较好（慢，安全）
• everysec：出厂默认推荐，每秒异步记录一次（默认值）
• no：不即时同步，由操作系统决定何时同步。

二、Redis持久化

• redis是内存数据库，它把数据存储在内存中，这样在加快读取速度的同时也对数据安全性产生了新的问题，即当redis所在服务器发生宕机后，redis数据库里的所有数据将会全部丢失。为了解决这个问题，redis提供了持久化功能——RDB和AOF（Append Only File）。

1、RDB

• 在指定的时间间隔内，执行指定次数的写操作，则会将内存中的数据写入到磁盘中。即在指定目录下生成一个dump.rdb文件。Redis重启会通过加载dump.rdb文件来恢复数据。

（1）RDB原理

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

什么是Fork？

• Fork的作用是复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器等） 数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程

执行流程图：

（2）RDB 保存的文件

• RDB保存的文件是dump.rdb文件 ,位置保存在Redis的启动目录。Redis每次同步数据到磁盘都会生成一个dump.rdb文件，新的dump.rdb会覆盖旧的dump.rdb文件。

（3）配置RDB 持久化策略

• 在客户端执行flushdb或者flushall或者shutdown时，也会把快照中的数据保存到dump.rdb，只不过这种操作已经把数据清空了，保存的也是空文件，没有意义。

（4）RDB备份

• 通过脚本将Redis产生的dump.rdb文件备份(cp dump.rdb dump_bak.rdb)，每次启动Redis前，把备份的dump.rdb文件替换到Redis相应的目录(在redis.conf中配的的dir目录)下，Redis启动时会加载dump.rdb文件，并且把数据读到内存中。
• rdb恢复

• 关闭Redis
• 先把备份的文件拷贝到工作目录下 cp dump2.rdb dump.rdb
• 启动Redis, 备份数据会直接加载

（5）优缺点

优点：

• 适合大规模的数据恢复
• 对数据完整性和一致性要求不高更适合使用
• 节省磁盘空间
• 恢复速度快

缺点：

• 虽然Redis在fork时使用了写时拷贝技术,但是如果数据庞大时还是比较消耗性能。
• 在备份周期在一定间隔时间做一次备份，所以如果Redis意外down掉的话，就会丢失最后一次快照后的所有修改。

（6）小结

2、AOF

（1）AOF原理

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

（2）AOF执行流程

1. 客户端的请求写命令会被append追加到AOF缓冲区内；
2. AOF缓冲区根据AOF持久化策略[always,everysec,no]将操作sync同步到磁盘的AOF文件中；
3. AOF文件大小超过重写策略或手动重写时，会对AOF文件rewrite重写，压缩AOF文件容量；
4. Redis服务重启时，会重新load加载AOF文件中的写操作达到数据恢复的目的；

（3）AOF保存的文件

• AOF保存的文件是appendonly.aof文件 ,位置保存在Redis的启动目录。如果开启了AOF，Redis每次记录写操作都会往appendonly.aof文件追加新的日志内容。
• AOF在配置文件中默认不开启
• AOF文件的保存路径，同RDB的路径一致。

（4）AOF数据恢复

• AOF的备份机制和性能虽然和RDB不同, 但是备份和恢复的操作同RDB一样，都是拷贝备份文件，需要恢复时再拷贝到Redis工作目录下，启动系统即加载。
• 正常恢复

• 修改默认的appendonly no，改为yes

• 将有数据的aof文件复制一份保存到对应目录(查看目录：config get dir)
• 恢复：重启redis然后重新加载

• 异常恢复

• 修改默认的appendonly no，改为yes
• 如遇到AOF文件损坏，通过/usr/local/bin/redis-check-aof–fix appendonly.aof进行恢复
• 备份被写坏的AOF文件
• 恢复：重启redis，然后重新加载

（5）优缺点

优点：

• 备份机制更稳健，丢失数据概率更低
• 可读的日志文本，通过操作AOF稳健，可以处理误操作

缺点：

• 比起RDB占用更多的磁盘空间
• 恢复备份速度要慢
• 每次读写都同步的话，有一定的性能压力
• 存在个别Bug，造成恢复不能

（6）小结