redis 配置文件详解

Redis的配置文件

redis的默认配置文件在redis目录下，有个叫redis.conf的文件。

用配置文件启动redis命令为：

src/redis-server redis.conf

Redis支持的参数：

1k => 1000 bytes 1kb => 1024 bytes 1m => 1000000 bytes 1mb => 1024*1024 bytes 1g => 1000000000 bytes 1gb => 1024*1024*1024 bytes

这里可以指定内存的大小

bind 127.0.0.1

这里可以绑定监听一个或多个IP地址。如果注释掉，将处理所有的请求，生产环境就注释掉。

protected-mode yes

这个参数是3.2才新有的，保护模式，默认开启，如果你确定你想要从其它的主机获取redis的监听，那么你就设为NO.需要你将配置bind。

port 6379

这里是监听端口，默认6379.

tcp-backlog 511

TCP监听的最大数，这里需要注意，如果链接过多，需要调整的话，同时需要调整/proc/sys/net/core/somaxconn下的配置，否则linux下会默认使用此配置调正到最低。

timeout 0

设置客户端的超时时间，单位为秒，如果客户端在此时间内没有发出新的请求，就关闭连接。默认为0就是不管它。

tcp-keepalive 300

TCP检测，也就是说每过300秒检测一次客户端是否还有效，避免服务器长时间阻塞。

daemonize no

默认情况，redis服务不在后台开启，设为yes，则在后台以守护进程形式运行。

supervised no

可以通过upstart和systemd管理Redis守护进程，这个参数是和具体的操作系统相关的。

pidfile /var/run/redis_6379.pid

当 Redis 在后台运行的时候， Redis 默认会把 pid（redis进程号） 文件放在/var/run/redis.pid，你可以配置到其他地址。当运行多个 redis 服务时，需要指定不同的 pid 文件和端口。

loglevel notice

日志：Redis总共支持四个级别：debug、verbose、notice、warning。

Debug：记录很多信息，用于开发和测试；

Varbose：有用的信息，不像debug会记录那么多；

Notice：普通的verbose，常用于生产环境；

Warning：只有非常重要或者严重的信息会记录到日志；

默认是notice级别。

logfile ""

log的存放地址，默认为“”就是输出到控制台。

databases 16

可用的数据库数量，默认为16个。可以使用 SELECT 命令来切换数据库。默认使用的数据库是 0。

save 900 1 save 300 10 save 60 10000

设置 Redis 进行数据库镜像的频率：

900 秒后如果至少有 1 个 key 的值变化，则保存

300 秒后如果至少有 10 个 key 的值变化，则保存

60 秒后如果至少有 10000 个 key 的值变化，则保存

stop-writes-on-bgsave-error yes

当持久化出现错误之后，是否继续提供写服务.

rdbcompression yes

数据持久化的时候，是否压缩。

rdbchecksum yes

读取和写入的时候是否支持CRC64校验，默认是开启的.

dbfilename dump.rdb

镜像备份文件的文件名。

dir ./

数据库镜像备份的文件放置的路径。这里的路径跟文件名要分开配置是因为 Redis 在进行备份时，先会将当前数据库的状态写入到一个临时文件中，等备份完成时，再把该该临时文件替换为上面所指定的文件，而这里的临时文件和上面所配置的备份文件都会放在这个指定的路径当中。

slaveof masterauth slave-serve-stale-data yes

设置该数据库为其他数据库的从数据库。

如果需要密码验证则设置密码。

当slave服务器和master服务器失去连接后，或者当数据正在复制传输的时候，如果此参数值设置“yes”，slave服务器可以继续接受客户端的请求，否则，会返回给请求的客户端如下信息“SYNC with master in progress”。

slave-read-only yes

是否允许slave服务器节点只提供读服务。

repl-diskless-sync no repl-diskless-sync-delay 5 repl-ping-slave-period 10 repl-timeout 60

主从同步支持两种策略，即disk和socket方式（socket方式尚不完善，还处于实验阶段）。

新的slave端和重连的salve端不允许去继续同步进程，这被称之为“完全同步”。

一个RDB文件从master端传到slave端，分为两种情况：

1、支持disk：master端将RDB file写到disk，稍后再传送到slave端；

2、无磁盘diskless：master端直接将RDB file传到slave socket，不需要与disk进行交互。

无磁盘diskless方式适合磁盘读写速度慢但网络带宽非常高的环境。

1. 默认不使用diskless同步方式 .
2. 无磁盘diskless方式在进行数据传递之前会有一个时间的延迟，以便slave端能够进行到待传送的目标队列中，这个时间默认是5秒.
3. slave端向server端发送pings的时间区间设置，默认为10秒。
4. 设置超时时间。

repl-disable-tcp-nodelay no

指定向slave同步数据时，是否禁用socket的NO_DELAY选 项。若配置为“yes”，则禁用NO_DELAY，则TCP协议栈会合并小包统一发送，这样可以减少主从节点间的包数量并节省带宽，但会增加数据同步到 slave的时间。若配置为“no”，表明启用NO_DELAY，则TCP协议栈不会延迟小包的发送时机，这样数据同步的延时会减少，但需要更大的带宽。 通常情况下，应该配置为no以降低同步延时，但在主从节点间网络负载已经很高的情况下，可以配置为yes。

repl-backlog-size 1mb repl-backlog-ttl 3600

设置backlog的大小，backlog是一个缓冲区，在slave端失连时存放要同步到slave的数据，因此当一个slave要重连时，经常是不需要完全同步的，执行局部同步就足够了。backlog设置的越大，slave可以失连的时间就越长。

如果一段时间后没有slave连接到master，则backlog size的内存将会被释放。如果值为0则表示永远不释放这部份内存。

slave-priority 100 min-slaves-to-write 3 min-slaves-max-lag 10

当 master 不能正常工作的时候，Redis Sentinel 会从 slaves 中选出一个新的 master，这个值越小，就越会被优先选中，但是如果是 0 ， 那是意味着这个 slave 不可能被选中。

设置当一个master端的可用slave少于N个，延迟时间大于M秒时，不接收写操作。

maxclients 10000 maxmemory maxmemory-policy volatile-lru

限制同时连接的客户数量。当连接数超过这个值时，redis 将不再接收其他连接请求，客户端尝试连接时将收到error 信息。默认为10000，要考虑系统文件描述符限制，不宜过大，浪费文件描述符，具体多少根据具体情况而定。

redis-cache所能使用的最大内存(bytes),默认为0,表示”无限制”,最终由OS物理内存大小决定(如果物理内存不足,有可能会使用swap)。此值尽量不要超过机器的物理内存尺寸,从性能和实施的角度考虑,可以为物理内存3/4。此配置需要和”maxmemory-policy”配合使用,当redis中内存数据达到maxmemory时,触发”清除策略”。在”内存不足”时,任何write操作(比如set,lpush等)都会触发”清除策略”的执行。在实际环境中,建议redis的所有物理机器的硬件配置保持一致(内存一致),同时确保master/slave中”maxmemory”“policy”配置一致。

当内存满了的时候，如果还接收到set 命令，redis 将先尝试剔除设置过expire 信息的key，而不管该key 的过期时间还没有到达。在删除时，

将按照过期时间进行删除，最早将要被过期的key 将最先被删除。如果带有expire 信息的key 都删光了，内存还不够用，那么将返回错误。这样，redis 将不再接收写请求，只接收get 请求。maxmemory 的设置比较适合于把redis 当作于类似memcached的缓存来使用。

最大内存策略，你有 5 个选择：

• volatile-lru -> 使用 LRU 算法移除包含过期设置的 key 。
• noeviction -> 不让任何 key 过期，只是给写入操作返回一个错误。
• allkeys-lru -> 根据 LRU 算法移除所有的 key 。
• volatile-random -> 对”过期集合”中的数据采取”随即选取”算法,并移除选中的K-V,直到”内存足够”为止. 如果如果”过期集合”中全部移除全部移除仍不能满足,将OOM
• allkeys-random -> 对所有的数据,采取”随机选取”算法,并移除选中的K-V,直到”内存足够”为止
• volatile-ttl ->对”过期集合”中的数据采取TTL算法(最小存活时间),移除即将过期的数据.

maxmemory-samples 5

默认值5，上面LRU和最小TTL策略并非严谨的策略，而是大约估算的方式，因此可以选择取样值以便检查。

appendonly no

默认情况下，redis 会在后台异步的把数据库镜像备份到磁盘，但是该备份是非常耗时的，而且备份也不能很频繁。所以redis 提供了另外一种更加高效的数据库备份及灾难恢复方式。开启append only 模式之后，redis 会把所接收到的每一次写操作请求都追加到appendonly.aof 文件中，当redis 重新启动时，会从该文件恢复出之前的状态。但是这样会造成appendonly.aof 文件过大，所以redis 还支持了BGREWRITEAOF 指令，对appendonly.aof 进行重新整理。如果不经常进行数据迁移操作，推荐生产环境下的做法为关闭镜像，开启appendonly.aof，同时可以选择在访问较少的时间每天对appendonly.aof 进行重写一次。

另外，对master机器,主要负责写，建议使用AOF,对于slave,主要负责读，挑选出1-2台开启AOF，其余的建议关闭。

appendfilename "appendonly.aof"

aof文件名字，默认为appendonly.aof。

# appendfsync always appendfsync everysec # appendfsync no

设置对appendonly.aof 文件进行同步的频率。always 表示每次有写操作都进行同步，everysec 表示对写操作进行累积，每秒同步一次。no不主动fsync，由OS自己来完成。这个需要根据实际业务场景进行配置。

no-appendfsync-on-rewrite no

在aof rewrite期间,是否对aof新记录的append暂缓使用文件同步策略,主要考虑磁盘IO开支和请求阻塞时间。默认为no,表示”不暂缓”,新的aof记录仍然会被立即同步。

auto-aof-rewrite-percentage 100

当Aof log增长超过指定比例时，重写log file， 设置为0表示不自动重写Aof 日志，重写是为了使aof体积保持最小，而确保保存最完整的数据。

auto-aof-rewrite-min-size 64mb

触发aof rewrite的最小文件尺寸。

aof-load-truncated yes

: redis在启动的时候可以加载被截断的AOF文件，默认启用。

lua-time-limit 5000

lua脚本运行的最大时间。

cluster-enabled yes

配置redis做为一个集群节点来启动 。

cluster-config-file node-6379.conf

每个集群节点都有一个集群配置文件，这个文件不需要编辑，它由redis节点来创建和更新。每个redis节点的集群配置文件不可以相同。

cluster-node-timeout 15000

设置集群节点超时时间，如果超过了指定的超时时间后仍不可达，则节点被认为是失败状态，单位为毫秒。

一个属于失效的master端的slave，如果它的数据较旧，将不会启动failover。

现在来讲并没有一个简单的方法去解决如何判定一个slave端的数据的时效性问题，所以可以执行以下两个选择：

1、如果有多个slave可用于failover，它们会交换信息以便选出一个最优的进行主从复制的offset，slave端会尝试依据offset去获取每个slave的rank，这样在启动failover时对每个slave的利用就与slave端的rank成正比。

2、每个slave端和它的master端进行最后交互的时间，这可能是最近的ping或指令接收时间，或自与master端失连的过时时间。如果最近的交互时间太久，slave就不会尝试去进行failover。

第2点可以由用户来进行调整，明确一个slave不会进行failover。自最近一次与master端进行交互，过时时间有一个计算公式：

（node-timeout * slave-validity-factor）+repl-ping-slave-period

一个比较大的slave-validity-factor参数能够允许slave端使用比较旧的数据去failover它的master端，而一个比较小的值可能会阻止集群去选择slave端。

为获得最大的可用性，可以设置slave-validity-factor的值为0，这表示slave端将会一直去尝试failover它的master端而不管它与master端的最后交互时间。

cluster-slave-validity-factor 10

集群中的slave可以迁移到那些没有可用slave的master端，这提升了集群处理故障的能力。毕竟一个没有slave的master端如果发生了故障是没有办法去进行failover的。

要将一个slave迁移到别的master，必须这个slave的原master端有至少给定数目的可用slave才可以进行迁移，这个给定的数目由migration barrier参数来进行设置，默认值为1，表示这个要进行迁移的slave的原master端应该至少还有1个可用的slave才允许其进行迁移，要禁用这个功能只需要将此参数设置为一个非常大的值。

cluster-migration-barrier 1

默认情况下当redis集群节点发现有至少一个hashslot未被covered时将会停止接收查询。

这种情况下如果有一部份的集群down掉了，那整个集群将变得不可用。

集群将会在所有的slot重新covered之后自动恢复可用。

若想要设置集群在部份key space没有cover完成时继续去接收查询，就将参数设置为no。

cluster-require-full-coverage yes

slowlog-log-slower-than 10000

“慢操作日志”记录,单位:微秒(百万分之一秒,1000 * 1000),如果操作时间超过此值,将会把command信息”记录”起来.(内存,非文件)。其中”操作时间”不包括网络IO开支,只包括请求达到server后进行”内存实施”的时间.”0”表示记录全部操作。

slowlog-max-len 128

“慢操作日志”保留的最大条数,”记录”将会被队列化,如果超过了此长度,旧记录将会被移除。可以通过”SLOWLOG args”查看慢记录的信息(SLOWLOG get 10,SLOWLOG reset)。

latency-monitor-threshold 0

延迟监控，用于记录等于或超过了指定时间的操作，默认是关闭状态，即值为0。

hash-max-ziplist-entries 512 hash-max-ziplist-value 64

hash类型的数据结构在编码上可以使用ziplist和hashtable。ziplist的特点就是文件存储(以及内存存储)所需的空间较小,在内容较小时,性能和hashtable几乎一样.因此redis对hash类型默认采取ziplist。如果hash中条目的条目个数或者value长度达到阀值,将会被重构为hashtable。

这个参数指的是ziplist中允许存储的最大条目个数，，默认为512，建议为128。

ziplist中允许条目value值最大字节数，默认为64，建议为1024。

list-max-ziplist-size -2 list-compress-depth 0

redis在3.2中废弃了之前的两个list底层结构设置：list-max-ziplist-entries 512 list-max-ziplist-value 64。改为新的quicklist结构。

set-max-intset-entries 512

与哈希和列表类似，有序集合也会使用一种特殊的编码方式来节省空间，这种特殊的编码方式只用于这个有序集合的长度和元素均低于以下参数设置的值时。 intset中允许保存的最大条目个数,如果达到阀值,intset将会被重构为hashtable。

zset-max-ziplist-entries 128 zset-max-ziplist-value 64

zset为有序集合,有2中编码类型:ziplist,skiplist。因为”排序”将会消耗额外的性能,当zset中数据较多时,将会被重构为skiplist。

hll-sparse-max-bytes 3000

设置HyeperLogLog的字节数限制，这个值通常在0~15000之间，默认为3000，基本不超过16000 。

activerehashing yes

是否开启顶层数据结构的rehash功能,如果内存允许,请开启。rehash能够很大程度上提高K-V存取的效率。redis将会在每秒中抽出10毫秒来对主字典进行重新散列化处理，这有助于尽可能的释放内存。

client-output-buffer-limit

因为某些原因，client不能足够快的从server读取数据，那client的输出缓存限制可能会使client失连，这个限制可用于3种不同的client种类，分别是：normal、slave和pubsub。

client-output-buffer-limit normal 0 0 0 client-output-buffer-limit slave 256mb 64mb 60 client-output-buffer-limit pubsub 32mb 8mb 60

客户端buffer控制。在客户端与server进行的交互中,每个连接都会与一个buffer关联,此buffer用来队列化等待被client接受的响应信息。如果client不能及时的消费响应信息,那么buffer将会被不断积压而给server带来内存压力.如果buffer中积压的数据达到阀值,将会导致连接被关闭,buffer被移除。

buffer控制类型包括:normal -> 普通连接；slave ->与slave之间的连接；pubsub ->pub/sub类型连接，此类型的连接，往往会产生此种问题;因为pub端会密集的发布消息,但是sub端可能消费不足.

指令格式:client-output-buffer-limit ”,其中hard表示buffer最大值,一旦达到阀值将立即关闭连接;

soft表示”容忍值”,它和seconds配合,如果buffer值超过soft且持续时间达到了seconds,也将立即关闭连接,如果超过了soft但是在seconds之后，buffer数据小于了soft,连接将会被保留.

其中hard和soft都设置为0,则表示禁用buffer控制.通常hard值大于soft.

hz 10

redis使用一个内部程序来处理后台任务，例如关闭超时的client连接，清除过期的key等等。它并不会同时处理所有的任务，redis通过指定的hz参数去检查和执行任务。

hz默认设为10，提高它的值将会占用更多的cpu，当然相应的redis将会更快的处理同时到期的许多key，以及更精确的去处理超时。

hz的取值范围是1~500，通常不建议超过100，只有在请求延时非常低的情况下可以将值提升到100。

aof-rewrite-incremental-fsync yes

当一个子进程要改写AOF文件，如果以下选项启用，那文件将会在每产生32MB数据时进行同步，这样提交增量文件到磁盘时可以避免出现比较大的延迟。