Redis配置文件详解/参数详解及淘汰策略

一，Redis 配置文件参数详解（Pro）

port 6380        #redis监听的端口号
daemonize yes    #  默认情况下redis是不支持后台运行的，如果想要后台运行，也就是以守护进程的方式运行需要把该参数改为yes
bind 0.0.0.0    #指定 redis 只接收来自于该IP地址的请求
pidfile "/home/qrcode/rediscluster/logs/redis-6380.pid"
logfile "/home/qrcode/rediscluster/logs/redis-6380.log"
dir "/data/redis"           #  数据库镜像备份的文件放置的路径
dbfilename "redis-6380.rdb"  #镜像备份文件的文件名

#限制同时连接的客户端数量，默认10000，
# 如果达到此限制，Redis则会拒绝新的连接请求
# 并且向这些请求发出"max number of clients reached" 以作回应。
maxclients 1000

# 设置redis能够使用的最大内存，必须设置，否则内存占满，造成服务器宕机
maxmemory 40gb
# 内存达到上线处理策略 ：不进行移除，针对写操作，只是返回错误信息。
maxmemory-policy noeviction

#aof持久化策略的配置
#no表示不执行fsync，由操作系统保证数据同步到磁盘，速度最快
#always表示每次写入都执行fsync，以保证数据同步到磁盘
#everysec表示每秒执行一次fsync，可能会导致丢失这1s数据
appendonly yes
appendfsync everysec
appendfilename "appendonly-6380.aof"

# 在aof重写或者写入rdb文件的时候，会执行大量IO，此时对于everysec和always的aof模式来说，执行
#fsync会造成阻塞过长时间，no-appendfsync-on-rewrite字段设置为默认设置为no。如果对延迟要求很高的
#应用，这个字段可以设置为yes，否则还是设置为no，这样对持久化特性来说这是更安全的选择。设置为yes表
#示rewrite期间对新写操作不fsync,暂时存在内存中,等rewrite完成后再写入，默认为no，
#建议yes。Linux的默认fsync策略是30秒。可能丢失30秒数据
no-appendfsync-on-rewrite yes

#aof自动重写配置。当目前aof文件大小超过上一次重写的aof文件大小的百分之多少进行重写，
#即当aof文件增长到一定大小的时候Redis能够调用bgrewriteaof对日志文件进行重写。
#当前AOF文件大小是上次日志重写得到AOF文件大小的二倍（设置为100）时，自动启动新的日志重写过程
auto-aof-rewrite-percentage 100
#设置允许重写的最小aof文件大小，避免了达到约定百分比但尺寸仍然很小的情况还要重写
auto-aof-rewrite-min-size 128mb

#aof文件可能在尾部是不完整的，当redis启动的时候，aof文件的数据被载入内存。
#重启可能发生在redis所在的主机操作系统宕机后，尤其在ext4文件系统没有加上data=ordered选项（redis宕机或者异常终止不会造
#成尾部不完整现象。）出现这种现象，可以选择让redis退出，或者导入尽可能多的数据。
#如果选择的是yes，当截断的aof文件被导入的时候，会自动发布一个log给客户端然后load。
#如果是no，用户必须手动redis-check-aof修复AOF文件才可以
aof-load-truncated yes
#设置客户端连接后进行任何其他指定前需要使用此密码
requirepass ysg0x1joart2
#如果master设置了requirepass，那么slave要连上master，需要有master的密码才行
masterauth ysg0x1joart2 

# 集群开关，默认是不开启集群模式
cluster-enabled yes
#集群配置文件的名称，每个节点都有一个集群相关的配置文件，持久化保存集群的信息。
#这个文件并不需要手动配置，这个配置文件有Redis生成并更新，
#每个Redis集群节点需要一个单独的配置文件，请确保与实例运行的系统中配置文件名称不冲突
cluster-config-file nodes-6380.conf
#节点互连超时的阀值。集群节点超时毫秒数
cluster-node-timeout 15000
#在进行故障转移的时候，全部slave都会请求申请为master，但是有些slave可能与master断开连接一段时间了，
#导致数据过于陈旧，这样的slave不应该被提升为master。
#该参数就是用来判断slave节点与master断线的时间是否过长。判断方法是：
#比较slave断开连接的时间和(node-timeout * slave-validity-factor) + repl-ping-slave-period
#如果节点超时时间为三十秒, 并且slave-validity-factor为10,假设默认的repl-ping-slave-period是10
秒，即如果超过310秒slave将不会尝试进行故障转移
cluster-require-full-coverage no

二， Redis的内存淘汰/移除/内存达到上线策略：

Redis 可以设置最大占用内存大小，那么配置的内存就有用完的时候。那在内存用完的时候，还继续往Redis里面添加数据不就没内存可用了吗？实际上Redis定义了几种策略用来处理这种情况

1，Redis 五种淘汰策略

• 1），noeviction（默认策略）：
  不进行移除，对于写请求不再提供服务，直接返回错误（DEL请求和部分特殊请求除外）。

• 2），allkeys-random：从所有key中随机移除数据。

• 3），allkeys-lru：从所有key中使用LRU算法进行移除/淘汰Key。

• 4），volatile-random：从设置了过期时间的key中随机淘汰。

• 5），volatile-lru：从设置了过期时间的key中使用LRU算法进行淘汰。

• 6），volatile-ttl：在设置了过期时间的key中，根据key的过期时间进行淘汰，越早过期的越优先被淘汰。

当使用volatile-random、volatile-lru、volatile-ttl这三种策略时，如果没有key可以被淘汰，则和noeviction一样返回错误

2，设置淘汰策略

获取当前内存淘汰策略：

127.0.0.1:6380> config get maxmemory-policy

修改淘汰策略（redis.conf配置文件/命令行）：

maxmemory-policy allkeys-lru
127.0.0.1:6380> config set maxmemory-policy allkeys-lru

三，LRU算法

1，什么是LRU?

Redis可使用最大内存使用完了，可以使用LRU算法进行内存淘汰。
LRU(Least Recently Used)，即最近最少使用，是一种缓存置换算法。在使用内存作为缓存的时候，缓存的大小一般是固定的。当缓存被占满，这个时候继续往缓存里面添加数据，就需要淘汰一部分老的数据，释放内存空间用来存储新的数据。这个时候就可以使用LRU算法了。其核心思想是：如果一个数据在最近一段时间没有被用到，那么将来被使用到的可能性也很小，所以就可以被淘汰掉。

欢迎点赞收藏!

欢迎点赞收藏!

欢迎点赞收藏!