Redis2.8配置文件详解

Published: by Creative Commons Licence

内存单位说明

当配置文件中涉及到内存大小的时候,需要注意下单位:

1k => 1000 bytes

1kb => 1024bytes

1m => 1000000 bytes

1mb => 1024×1024 bytes

1g => 1000000000 bytes

1gb => 1024×1024×1024 bytes

配置模板

如果已经有一个标准的配置模板,并且希望在该模板上做一些个性化的修改,可以使用 include 指令来引入其他的配置文件。REDIS 对配置文件的解析方式是从前往后依次解析,后面的会覆盖前面的。因此应该将include放在配置文件的最前面。

include /path/to/local.conf

include /path/to/other.conf

常用配置

# 设置yes可以让 REDIS 以一个守护进程来运行,默认为no.当REDIS作为一个守护进程来运行的时候 pidfile 参数作为pid文件。

daemonize yes

# 当 REDIS 以守护进程运行的时候,该参数作为其pid文件。/var/run/redis.pid为默认值,同一台服务器上不同的 REDIS 实例需要配置不同的pidfile,建议使用前面提到的配置文件的命名规则。

pidfile /var/run/redis.pid

# 设置 REDIS 在指定的端口上监听连接。设置为0的话则表示 REDIS 不会监听TCP Sockets.比如在一些使用了Unix socket本地进程通信的场景下可以禁用TCP链接。 注意:这个参数在2.8.3以及之前的版本上有一个bug: https://github.com/antirez/redis/issues/1477

port 6379

# TCP listen() 方法backlog值。在一个高并发的环境下,需要指定一个比较大的backlog值来避免慢连接(由于网络原因导致握手速度慢)情况。 注意:Linux 内核会默认使用/proc/sys/net/core/somaxconn 的值来削减 backlog的实际值,因此需要确保提升somaxconn 和 tcp_max_syn_backlog 这两个值来确保此处backlog设置生效。

tcp-backlog 511

# 默认情况下REDIS会在所有的可用网络接口中进行监听,如果你想让REDIS 在指定的网络接口中监听,那么可以使用bind指令来指定。当一个主机在网络中有多个IP的时候,比如有内网、外网之分的时候可能就需要用到该参数,bind 127.0.0.1就是指定只能本机网络访问。

# bind 192.168.1.100 10.0.0.1

bind 0.0.0.0

# 指定Unix socket的路径来进行连接监听。默认不指定 REDIS 不会再Unix socket上监听。

# unixsocket /tmp/redis.sock

# unixsocketperm 755

# 用来指定关闭空闲N秒的连接,默认0表示不处理空闲连接。

timeout 0

# 如果该值不为0,将使用 SO_KEEPALIVE 这一默认的做法来向客户端连接发送TCP ACKs.这样的好处有两个原因:

# 1)检测已死亡的对端;

# 2)保持连接在网络中的存活。

tcp-keepalive 0

# 指定日志记录的级别,可以是下面几个值之一:

# debug(尽可能多的日志信息,用于开发和测试之中)

# verbose(少但是有用的信息,没有debug级别那么混乱)

# notice(适量的信息,用于生产环境)

# warning(只有非常重要和关键的信息会被记录)

loglevel notice

# 指定日志文件的位置。为空时将输出到标准输出设备,如果 REDIS 是以守护进程方式运行的则会输出到/dev/null。

logfile “”

# 当设置 'syslog-enabled'为 yes时, 允许记录日志到系统日志中。以及你可以使用更多的日志参数来满足你的要求。

# syslog-enabled no

# 指定在系统日志中的身份。

# syslog-ident redis

# 制定系统日志的能力,必须为LOCAL0到LOCAL7之间的一个值。

# syslog-facility local0

# 设置数据库的数量。默认使用的数据库为DB 0, 可以在每个连接的基础上使用SELECT 来指定另外的数据库,但是这个值必须在0到 'databases'-1之间。

databases 16

持久化(RDB)

# 将数据保存到磁盘中。

# save 表示至少个key发生改变的时候秒后将数据保存到硬盘中。可以同时指定多个策略,比如下面这三个配置分别表示:

# 当存在至少1个key发生改变时,900秒后保存到硬盘

# 当存在至少10个key发生改变时,300秒后保存到硬盘

# 当存在至少1000个key发生改变时,60秒后保存到硬盘

# 这种持久化的方式在 REDIS 中乘坐 RDB 或者是 SNAPSHOTTING,可以通过注释所有save配置或者增加一个save ““ 配置关闭 RDB。

save 900 1

save 300 10

save 60 10000

# 默认的当RDB 快照开启(至少一个保存点)和后台保存(BGSAVE)失败后会停止接受写入命令。这是为了让用户察觉到BGSAVE 发生了问题。BGSAVE 恢复后,REDIS 会自动的允许写入。如果对REDIS 做了全面的合理的监控,那么可以关闭这个选项,这意味着无论是硬盘,权限还是其他的出现问题了,REDIS 仍然可以正常工作。

stop-writes-on-bgsave-error yes

# 是否在dump 数据到.rdb 文件的时候对字符串对象进行 LZF 压缩,默认为yes。大部分情况开启压缩都比不开启的收益大,除非是机器的CPU非常紧张。

rdbcompression yes

# 从 RDB 的版本5开始,REDIS 会在RDB文件末尾写入CRC64校验值。这让格式化过程中数据的完整性更有保障,但会是得保存和加载数据的时候损失不少的性能(10%左右)。为了提高性能,可以关闭这个选项,这个时候REDIS 会用0作为校验值写入到RDB文件中,加载的代码据此来跳过校验步骤。

rdbchecksum yes

# dump 文件名称。

dbfilename dump.rdb

# 工作目录。

# DB将会使用上述 'dbfilename'指定的文件名写入到该目录中,后面提到的AOF 文件也会写入到这个目录下。

dir ./

持久化(AOF)

# 是否开启 AOF 持久化模式。相比 RDB ,AOF的完整性会更好,但是一般产生的AOF文件也更大。AOF 和 RDB 机制可以同时开启,这时候 REDIS 启动的时候默认会加载 AOF 文件。

appendonly no

# AOF(append only file)文件的名称,默认为appendonly.aof。

appendfilename "appendonly.aof"

# 对于数据写入硬盘,一些操作系统会立即将数据写入硬盘,另外一些则可能不是,fsync()调用可以强制操做系统立即将数据写入到硬盘中,而不是先写到缓冲区再写到磁盘。基于fsync()调用Redis对于AOF文件的落地提供三种模式:

# no:不进行强制同步,将决策交给操做系统,这种模式速度会更快。

# appendfsync always:每一次的追加写入操作都采用强制同步,这种模式非常安全但也很慢。

appendfsync everysec:每隔一秒钟强制一次写入,是上面两种方案的一种折中。

# 当 AOF 的强制写入策略(fsync)设置为 always 或者 everysec 的时候,后台的保存进程(BGSAVE)或者AOF 文件重写进程(BGREWRITEAOF)会占用大量的磁盘IO资源,这在有些 Linux 的配置下会造成fsync() 长时间的阻塞,虽然 fsync() 是在fork出的子进程中执行,但是因为底层的系统调用 write(2) 是同步,所以问题其实是出在磁盘IO上面。将这个参数设置为yes 可以一定程度上避免这个问题,意思是在子进程在执行BGREWRITEAOF或者BGSAVE 的时候主进程不调用 fsync() ,但这会导致最多可能会丢失30秒的数据(Linux 默认的配置会保证数据30内会写入磁盘)。

no-appendfsync-on-rewrite no

# AOF 文件重写配置。REDIS 会记住上一次重写后的 AOF 文件的大小,以此做为基准值,当文件的大小超过 auto-aof-rewrite-percentage 指定的百分比的时候则进行重写,另外要指定一个文件的最小值,是为了防止文件过小频繁的重写。auto-aof-rewrite-percentage 设置为0表示关闭重写机制。

auto-aof-rewrite-percentage 100

auto-aof-rewrite-min-size 64mb

主从复制

# 主从复制。使用slaveof 命令来指定当前节点(作为从)的主节点。

# slaveof

# 如果主节点开启了密码保护(见下面requirepass配置),这个配置就是告诉从节点在向主节点发起同步请求的时候使用如下的密码进行验证,否则主节点会拒绝请求。

# masterauth

# 如果从节点失去了和主节点之间的连接,或者当复制操做(数据同步)处于进行状态的时候,从节点会有下面两种行为:

# 1)如果该参数设置为yes(默认值),从节点会继续返回给客户端数据,但客户端获取的数据可能是过期的,也有可能获取到的数据为空,如果从节点是第一次向主节点进行同步。

# 2)如果设置为no,从节点针对客户端的所有命令都会返回"SYNC with master in progress"这个错误,除了INFO 和 SLAVEOF这两个命令。

slave-serve-stale-data yes

# 用来设置从节点是否可以接受写请求。从2.6版本开始从节点默认都是只读的。注意只读从节点不是用来设计开放给不信任客户端的,它只是一个简单的保护层,可以防止一些误操作,像CONFIG,DEBUG 这些管理命令还是可以执行的。如果想要更高的安全性建议用 rename-command 来隐藏这些命令。

slave-read-only yes

# 从节点PING 主节点的时间间隔,默认为10秒。

# repl-ping-slave-period 10

# 这个参数用来设置下面这些操做的超时时间:

# 1)从节点方面,SYNC时候批量的IO数据传输的超时时间。

# 2)从节点方面,主节点的超时时间(PINGs和同步的数据)。

# 3)主节点方面,从节点的超时时间(REPLCONF ACK pings)。

# 注意:确保这个值大于repl-ping-slave-period 设置的值。

# repl-timeout 60

# 这个参数是用来设置在主从同步的时候是否启用TCP的Nagle算法(默认内核是启用的),这个算法简单的说就是将小的数据包合并成大的数据包,从而缓解带宽的压力,但是相应的会增加网络延迟(使用默认的配置这个延迟可能达到40ms)。TCP_NODELAY是TCP一个选项,用来禁用Nagle算法。

# 在网络状况比较好的情况(比如同一个机房)下建议禁用Nagle算法(设置为no),在网络较差(比如跨机房,节点之间有很多跳)则建议启用Nagle算法(设置为yes)。

repl-disable-tcp-nodelay no

# 设置主从复制的backlog的大小,这个不是指TCP的backlog。这是一个缓冲区用来支持2.8版本以后的部分重同步机制(partial resynchronization),该值越大从节点断连的(之后可以使用部分重同步)时间越长。这个缓冲区是在第一个从节点连上后在主节点上分配的。从服务器断开连接之后,主服务器将更新的数据写入缓冲区中,当从服务重新连接上来时候就不需要对所有的数据都进行完整的同步了。

# repl-backlog-size 1mb

# 当从节点在一定时间内(单位为秒)没有连接上主节点的时候,backlog缓冲区就会被释放掉。设置为0表示永不释放。

# repl-backlog-ttl 3600

# 从节点的优先级。当有多个从节点的时候,主节点一旦异常的时候,Redis Sentinel会根据这个值选举新的主,值越小优先级越高,但是注意0表示该从节点不参与选举。默认为100。

slave-priority 100

# 这两个参数配合起来是用来调优主从之间数据一致性的。简单描述为:只有当至少有 'min-slaves-to-write' 个从节点处于在线状态, 并且这些节点的延迟(最近一次从节点的ping)值都小于等于' min-slaves-max-lag '秒, 那么主节点才会执行客户端请求的写操作。注意:这样的设置并不能保证从节点一定会写入,但是起码保证了当没有足够的从处于可用状态的时候,客户端能够及时发现。这两个参数有一个设置为0就表示禁用这个特性。

# min-slaves-to-write 3

# min-slaves-max-lag 10

安全和限制

# 用来设置客户端执行命令时是否需要密码认证。因为REDIS 的性能很高,所以建议密码要设置的非常强壮,以防止暴力破解。

# requirepass foobared

# 命令重命名。如果 REDIS 暴露在公共的不受信任的环境下,可以通过将一些危险的命令重命名的方式来保证安全性。虽然只读从节点一定程度上可以保证安全性,但是像 CONFIG 这样的命令还是可以执行的。需要注意的是重命名后的命令也会被写入AOF文件或者被传输到从节点,可能会导致一些问题。

# rename-command CONFIG ""

# 客户端最大并发连接数。默认为10000,如果没有设置则为操做系统最大文件描述符数-32。超出限制则 REDIS 会返回给客户端错误信息:” max number of clients reached”。

# maxclients 10000

# 设置 REDIS 能够使用的最大内存,超过的话 REDIS 会根据maxmemory-policy 指定的策略淘汰key。如果根据相关策略无法移除key,或者策略被设置为 'noeviction',那么内存超过的时候针对写操入操做(比如SET,LPUSH) REDIS 会返回客户端一个错误,不影响读取操作。在主从结构下需要注意的是主节点上的输出缓冲区属于使用内存的一部分,网络问题或者重同步都不会触发key淘汰的行为,而相反从节点上输出缓冲区满的话则会触发key的删除行为,所以从服务器上maxmemory设置要少于系统可用的最大内存,给输出缓冲区预留空间,当然如果maxmemory-policy 设置为'noeviction' 则不需要了。

# maxmemory

# 内存使用超过 maxmemory 设置的时候采用的 key 淘汰策略。一共有以下五种策略可选:

# volatile-lru –> 使用LRU算法依据过期时间来移除key(默认设置)

# allkeys-lru -> 使用LRU算法来移除任意key

# allkeys-random -> 随机移除一个key

# volatile-ttl -> 移除一个最近的要过期的key

# 不移除key

# maxmemory-policy volatile-lru

# LRU 和最小 TTL 算法都是一个近似的算法。这个设置是让 REDIS 选择一个样本进行测试,删除其中最近最少用的key,默认样本大小为3。

# maxmemory-samples 3

LUA 脚本

# lua脚本的最大执行时间(单位毫秒)。

lua-time-limit 5000

慢日志

# REDIS 慢日志记录执行时间超过指定值得请求。执行时间不包括I/O操做,比如客户端的网络交互,发送应答等等。仅仅是线程因为执行这个命令而锁定无法处理其他请求的时间。slowlog-log-slower-than 单位为微秒,默认值为10000(10毫秒),设置为-1表示关闭慢日志功能,0表示记录所有命令。

slowlog-log-slower-than 10000

# 指定最多能保存多少条慢日志。慢日志记录会消耗一定内存,可以用SLOWLOG RESET 来回收。

slowlog-max-len 128

延迟监控

# REDIS 延迟监控的阈值。通过 LATENCY 命令可以打印出相关监控报告。设置为0表示关闭该功能。

latency-monitor-threshold 0

事件通知

# 键空间事件通知机制。键空间通知使得客户端可以通过订阅/发布(Pub/Sub)来接受 REDIS 中哪些数据有什么改动的事件。比如在0号库中对 “foo” 执行了DEL 操做,系统将分发两条消息, 相当于执行以下两个 PUBLISH 命令:

# PUBLISH keyspace@0:foo del

# PUBLISH keyevent@0:del foo

# 订阅第一个频道 keyspace@0:foo可以接收 0 号数据库中所有修改键 “foo” 的事件, 而订阅第二个频道 keyevent@0:del 则可以接收 0 号数据库中所有执行 del 命令的键。

# 以 keyspace 为前缀的频道被称为键空间通知(key-space notification), 而以 keyevent 为前缀的频道则被称为键事件通知(key-event notification)。notify-keyspace-events 参数可以是以下字符串的任意组合,它们用来指定服务器发送哪些类型的通知:

# K键空间通知,所有通知以 __keyspace@__ 为前缀

# E键事件通知,所有通知以 __keyevent@__ 为前缀

# g DEL 、 EXPIRE 、 RENAME 等类型无关的通用命令的通知

# $ 字符串命令的通知

# l 列表命令的通知

# s 集合命令的通知

# h 哈希命令的通知

# z 有序集合命令的通知

# x 过期事件,每当有过期键删除时通知

# e 键淘汰事件:每当有键因为maxmemory-policy 策略被淘汰时通知

# A 参数g$lshzxe 的别名

# 举例说明,如果只想订阅键空间中和列表相关的通知, 那么参数就应该设为 Kl,诸如此类。参数中至少有一个 K 或 E,否则不会有任何通知分发,”AKE” 表示发送所有类型的通知,””空字符串表示关闭键空间通知功能。

notify-keyspace-events ""

高级配置

# 创建哈希表时REDIS 默认使用的是 REDIS_ENCODING_ZIPLIST 编码(压缩列表ziplist),但下面两个值超过阈值则编码自动切换为默认的 REDIS_ENCODING_HT:

# 哈希表中某个键或某个值的长度大于 hash_max_ziplist_value (默认值为 64)。

# 哈希表中的节点数量大于hash_max_ziplist_entries (默认值为 512)。

# 压缩列表顾名思义是为了节约内存而设计的,但是因为其数据结构的特点在添加或删除节点的时候,可能会引发所谓的”连锁更新”操做,但这种操作实际出现的概率很小,造成性能问题可能性也很小。

hash-max-ziplist-entries 512

hash-max-ziplist-value 64

# 跟哈希表类似

list-max-ziplist-entries 512

list-max-ziplist-value 64

# 跟哈希表类似

zset-max-ziplist-entries 128

zset-max-ziplist-value 64

# intset 是 REDIS 集合(Set)的编码方式之一,如果集合里只有整数,并且元素少于set-max-intset-entries(默认512)的时候 REDIS 会采用intset 作为该类型的实现。跟ziplist类似inset也是为了节约内存设计的。

set-max-intset-entries 512

# HyperLogLog 稀疏表示字节限制(sparse representation),默认3000。

# 这个限制包含了16个字节的头部,超过了这个显示,它就会转换到dense representation上,这个参数涉及到具体的HyperLogLog算法,这里不做详细说明。HyperLogLog的一个主要使用场景是对一个非常大的集合里有多少个不重复的元素进行计数,比如一天有多少独立IP访问网站,这个算法能在消耗非常少的内存的情况下处理非常大的集合。

hll-sparse-max-bytes 3000

# rehashing 使用CPU时间的每100毫秒中的1毫秒来进行rehashing工作。

activerehashing yes

# 客户端输出缓冲区大小限制。输出缓冲区是为了解决一些因为网络不稳定等原因导致的临时掉线的问题,当客户端无法读取数据的时候,会先将数据写入缓冲区内,这样客户端恢复正常之后就可以继续执行之前的操做。缓冲区主要用适用异步的操做,比如主从之间的半同步机制。主要有以下三种输出缓冲区:

# normal 针对正常的客户端

# salve 针对从节点和监控节点

# pubsub 针对至少订阅了一个频道或模式的客户端

# 参数的格式为:

# client-output-buffer-limit

# 缓存区一旦超过或者在 秒内连续的超过则认为客户端确实断线了,这时会强制中断连接。默认normal 客户端没有限制(因为是同步的读写请求),hard limit> 都设置为0即表示没有限制。

# 除了上面提到的主从半同步机制,对于发布订阅,一旦消息产生堆积(消费速度跟不上)输出缓冲区的大小就需要引起注意。

client-output-buffer-limit normal 0 0 0

client-output-buffer-limit slave 256mb 64mb 60

client-output-buffer-limit pubsub 32mb 8mb 60

# REDIS会按照一定的频率来执行诸如关闭超时连接,删除没有被使用的过期key等此类后台任务。hz设置越大,这些操作越及时跟精确,同时在 REDIS 空闲的时候也会消耗更多的 CPU。该值的取值范围在1到500之间,不建议设置超过100。

hz 10

# 当子进程重写AOF文件的时候,这个参数设置为yes时将允许等到存在32MB数据的时候才调用强制同,步这样可以降低IO延迟。

aof-rewrite-incremental-fsync yes

Sentinel哨兵配置

SENTINEL 程序用来监视和管理多个 REIDS 实例,这个程序主要有下面三个功能:

  • 监控(Monitoring):SENTINEL 会不断地检查你的主节点和从节点是否运行正常。

  • 提醒(Notification):当被监控的某个REDIS 节点出现问题的时候,SENTINEL 可以通过 API 向管理员或者客户端应用程序发送通知。

  • 自动故障转移(Automatic failover):当主节点不能正常工作的时候,SENTINEL 会开始一次故障转移操做,它会从从节点中选举一个新的主出来,同时通知客户端程序新的主节点的地址。

SENTINEL 程序的配置并不是很多。

# 设置 SENTINEL 程序在指定的端口上监听连接。

port 80000

# 设置yes可以让 SENTINEL 以一个守护进程来运行,默认为no。当SENTINEL作为一个守护进程来运行的时候 pidfile 参数作为pid文件。

daemonize yes

# 当 SENTINEL 以守护进程运行的时候,该参数作为其pid文件。/var/run/sentinel.pid为默认值,同一台服务器上不同的 SENTINEL 实例需要配置不同的pidfile,建议使用前面提到的配置文件的命名规则。

pidfile /var/run/sentinel.pid

# 指定日志文件的位置。为空时将输出到标准输出设备,如果 SENTINEL 是以守护进程方式运行的则会输出到/dev/null。

logfile “”

# SENTINEL 程序的工作目录。

dir ./

# sentinel monitor 指令用来设置监控的主节点,后面几项依次是主节点的名字,IP地址和端口,最后一项2表示当至少有2个 SENTINEL (SENTINEL 可以部署多个)认为主节点出现问题的时候才进行故障转移操做。需要注意的是无路这个数值是多少,一次故障转移必须获得大多数 SENTINEL 的同意才能执行,换句话说当只有少数SENTINEL 正常运行的时候 是不能执行故障转移操做的。

sentinel monitor mymaster 127.0.0.1 6379 2

# sentinel auth-pass

# SENTINEL 访问主节点和从节点用的密码。注意如果使用 SENTINEL 来监控主从,那么主从的密码设置必须是一样的。

# sentinel auth-pass mymaster MySUPER–secret-0123passw0rd

# 如果节点在指定的时间内(单位毫秒,默认为30000),没有回复 SENTINEL 发送的 PING 命令,那么 SENTINEL 会将这个节点标记为”主观下线“(subjectively down,简称 SDOWN)。当标记为主观下线的 SENTINEL 达到指定的数量(上面参数提到的)的时候,就会引发一次故障转移操做,这时候断线的节点被标记为”客观下线”(objectively down,检查 ODOWN)。

sentinel down-after-milliseconds resque 30000

# 指定在进行故障转移的时候,最多可以有多少个从节点同时对新的主节点进行同步,这个值设置的越小,故障转移需要的时间越长。实际使用场景下如果用从节点提供读取服务,那么可以考虑将这个值设置的小一点,不至于在故障转移期间,所有的从节点都不可用。

sentinel parallel-syncs mymaster 1

# 故障转移的超时时间(单位毫秒)。这个超时时间会用在以下几个地方:

# 1.对于同一个主节点,故障转移操做的重试超时时间为该值的两倍。

# 2.从节点从已经出问题的主节点上切换到新的主节点的超时时间(真正意义上的 failover timeout)。

# 3.当超过这个时间内没有任何配置被修改,则取消这次故障转移。

# 4.所有从节点完成切换的超时时间。注意超过这个时间 SENTINEL 还是会保证所有从节点切换到新的主节点,只是不会以 parallel-syncs 设置的策略来进行。

sentinel failover-timeout mymaster 180000

# 通知脚本。这是一个比较实用的功能,设置了之后,当 SENTINEL 发生了 WARNING 级别的事件(主观下线,客观下线)的时候会调用该脚本(必须有可执行的权限),传入的参数只有两个,一个是事件的类型,另一个是描述信息。

# sentinel notification-script mymaster /var/redis/notify.sh