Redis配置文件的参数集合

Posted 2021-03-03 粽先生

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了Redis配置文件的参数集合相关的知识，希望对你有一定的参考价值。

===============================================

2020/3/30_第1次修改 ccb_warlock

===============================================

由于修改框架学习了redis连接池的相关内容，顺便整理了redis配置文件用到的部分配置项，方便学习记录的同时也方便将来回顾。

redis的配置项远不止下面的这些，我这里针对接触到的一些参数进行整理。

1. 绑定IP

为了保护redis故只允许被内部（127.0.0.1）访问，但是在外网环境时经常会通过其他方式（防火墙规则、安全组、redis设密码）来限制连接redis，所以常用是下面的方式：

# 允许192.168.1.1、10.0.0.1访问该redis

bind 192.168.1.1 10.0.0.1

# 允许任意IP访问

# 注释掉
#bind 127.0.0.1

或

# 设置不绑定任何IP
bind 0.0.0.0

2. 保护模式

根据官网描述，该模式也是为了保护redis使用默认的配置运行redis，这意味着此时redis只能被本地连接且没有密码，一般会关闭保护模式方便使用。

# yes.开启, no.关闭

protected-mode no

3. 端口

其他服务访问redis的端口（默认是6379）

port 6379

4. 密码

默认redis连接是没有密码的，如果需要redis也可以设置密码。（一般首先考虑通过其他方式来屏蔽对redis的连接，而不是把redis暴露在公网后通过密码来限制）

requirepass 123456

5. 内存限制

为了更好的管理redis的内存占用，可以通过设置maxmemory来限制redis的内存占用。

PS:

1）32位系统即使配置没有限制，依旧包含3GB的隐形限制。（也能理解，32位的系统最多也只能管理4G内存嘛）

2）当占用达到限制时，redis将会根据“驱逐策略”（下面会具体描述）对数据进行操作。

# 限制最大内存为512MB

maxmemory 512mb

# 不限制内存

# 注释掉
#maxmemory 512mb

或

# 设置为0
maxmemory 0

6. 驱逐策略

当内存使用达到内存限制时，就会触发驱逐策略，进行接下去的操作。

在讲具体的策略之前，首先了解下2种淘汰策略：

LRU(Least Recently Used): 最近最少使用

LFU(Least Frequently Used): 最近最不常用

两者的区别，LRU是该数据被使用了一次就被提到表头（实际以链表实现），删除则是选择表尾的数据来删除。

LFU则是对每个数据使用的频率进行统计，删除则是选择频率最低的数据来删除。

# 使用最近不常用的驱逐策略

maxmemory-policy allkeys-lfu

策略类型	参数项	说明	备注
NoDel	noeviction	不删除任何key，达到内存限制时再请求写入时，则返回错误。	默认
LRU	volatile-lru	在已设置过期时间的数据集中，删除最近最少使用(LRU)的key。
LRU	allkeys-lru	在整个的数据集中，删除最近最少使用(LRU)的key。
Random	volatile-random	在已设置过期时间的数据集中，随机删除一部分key。
Random	allkeys-random	在整个数据集中，随机删除一部分key。
TTL	volatile-ttl	在已设置过期时间的数据集中，删除将要过期（ttl较小）的key。
LFU	volatile-lfu	在已设置过期时间的数据集中，删除最近使用频率最低的key。	Redis4.X开始才有的策略
LFU	allkeys-lfu	在整个的数据集中，删除最近使用频率最低的key。	Redis4.X开始才有的策略

7. RDB持久化

全量备份方案，redis默认启用持久化方案。

RDB的持久化时通过快照（snapshotting）来实现的，即当符合条件时redis将内存的所有数据生成一份快照文件存到磁盘的RDB文件（二进制文件）中。

# 设置RDB的文件名

dbfilename dump.rdb

由下面3种场景触发快照：

1）根据配置的规则，自动快照。

默认的3个规则如下：

# 900秒内，至少对1个key进行了增删改，执行BGSAVE。
save 900 1

# 300秒内，至少对10个key进行了增删改，执行BGSAVE。
save 300 10

# 60秒内，至少对10000个key进行了增删改，执行BGSAVE。
save 60 10000

2）执行SAVE或BGSAVE命令时，将会执行一次快照。

SAVE：同步进行快照。快照的过程中会阻塞所有客户端的请求。

BGSAVE：异步进行快照。Redis fork 创建一个新的子进程负责进行快照后退出，而原来的 Redis 进程(父进程)继续处理客户端请求。

3）执行FLUSHALL命令且有自动快照规则时，将会执行一次快照。

8. AOF持久化

增量备份方案。

将每条增删改的命令写入AOF文件（文本文件）中。

AOF持久化的价值在于，在等待RDB自动快照的过程中，redis进程突然中止或服务器断电，可能会造成几秒甚至几分钟内的写丢失。故为了尽可能的防止这类问题，可以开启AOF持久化，更好的持久化数据（当然提高了操作磁盘的频率性能会有所降低，不过是可以接受的）。

# yes.开启, no.关闭（默认）

appendonly yes

# 设置AOF的文件名

appendfilename "appendonly.aof"

# 设置每秒对增删改操作日志进行持久化

appendfsync everysec

参数值	说明	备注
always	每次收到写命令就立即写入文件，这种方案数据更完整，但是性能最低。
everysec	每秒钟写入文件一次，这种方案是在性能和持久化之间做了折中。当你不确定另外2种模式对项目的价值时推荐使用这个配置。	默认
no	完全由os决定什么时候将缓存数据写入文件，这种方案性能最好，但是持久化没保证。