Redis是一个高性能的key-value数据库。node
Redis支持数据的持久化,能够将内存中的数据保存在磁盘中,重启的时候能够再次加载进行使用。
Redis不只仅支持简单的key-value类型的数据,同时还提供list,set,zset,hash等数据结构的存储。
Redis支持数据的备份,即master-slave模式的数据备份。redis
为了更好的使用redis,咱们须要详细的了解redis配置文件及相关参数做用。算法
include /path/to/local.conf
额外载入配置文件,若是有须要的话,能够开启此配置数据库
bind 127.0.0.1 bind 192.168.1.100
绑定redis服务器网卡IP,默认为127.0.0.1,即本地回环地址。这样的话,访问redis服务只能经过本机的客户端链接,而没法经过远程链接。若是bind选项为空的话,那会接受全部来自于可用网络接口的链接。如上配置,绑定一个127.0.0.1的本机地址和192.168.1.100的外网地址。安全
protected-mode yes
保护模式,默认是开启状态,只容许本地客户端链接, 能够设置密码或添加bind来链接bash
port 6379
监听端口号,默认为6379,若是设为0,redis将不在socket 上监放任何客户端链接服务器
tcp-backlog 511
TCP监听的最大容纳数量,在高并发的环境下,你须要把这个值调高以免客户端链接缓慢的问题。Linux 内核会把这个值缩小成 /proc/sys/net/core/somaxconn对应的值,要提高并发量须要修改这两个值才能达到目的网络
unixsocket /tmp/redis.sock unixsocketperm 700
指定redis监听的unix socket路径,默认不启用,unixsocketper指定文件的权限数据结构
timeout 0
指定在一个 client 空闲多少秒以后关闭链接(0表示永不关闭)并发
tcp-keepalive 300
单位是秒,表示将周期性的使用SO_KEEPALIVE检测客户端是否还处于健康状态,避免服务器一直阻塞,官方给出的建议值是300s,若是设置为0,则不会周期性的检测
daemonize yes
默认状况下 redis 不是做为守护进程运行的,若是你想让它在后台运行,你就把它改为 yes。当redis做为守护进程运行的时候,它会写一个 pid 到 /var/run/redis.pid 文件里面
supervised no
能够经过upstart和systemd管理Redis守护进程
选项:
supervised no - 没有监督互动
supervised upstart - 经过将Redis置于SIGSTOP模式来启动信号
supervised systemd - signal systemd将READY = 1写入$ NOTIFY_SOCKET
supervised auto - 检测upstart或systemd方法基于 UPSTART_JOB或NOTIFY_SOCKET环境变量
pidfile /var/redis/run/redis_6379.pid
配置PID文件路径,当redis做为守护进程运行的时候,它会把 pid 默认写到 /var/redis/run/redis_6379.pid 文件里面
loglevel notice
定义日志级别。
能够是下面的这些值:
debug(记录大量日志信息,适用于开发、测试阶段)
verbose(较多日志信息)
notice(适量日志信息,使用于生产环境)
warning(仅有部分重要、关键信息才会被记录)
logfile /var/redis/log/redis_6379.log
日志文件的位置,当指定为空字符串时,为标准输出,若是redis已守护进程模式运行,那么日志将会输出到/dev/null
syslog-enabled no
要想把日志记录到系统日志,就把它改为 yes,也能够可选择性的更新其余的syslog 参数以达到你的要求
syslog-ident redis
设置系统日志的ID
syslog-facility local0
指定系统日志设置,必须是 USER 或者是 LOCAL0-LOCAL7 之间的值
databases 16
设置数据库的数目。默认的数据库是DB 0 ,能够在每一个链接上使用select <dbid> 命令选择一个不一样的数据库,dbid是一个介于0到databases - 1 之间的数值。
save 900 1 save 300 10 save 60 10000
存 DB 到磁盘:
格式:save <间隔时间(秒)> <写入次数>
根据给定的时间间隔和写入次数将数据保存到磁盘
下面的例子的意思是:
900 秒内若是至少有 1 个 key 的值变化,则保存
300 秒内若是至少有 10 个 key 的值变化,则保存
60 秒内若是至少有 10000 个 key 的值变化,则保存
注意:你能够注释掉全部的 save 行来停用保存功能。
也能够直接一个空字符串来实现停用:
save ""
stop-writes-on-bgsave-error yes
若是用户开启了RDB快照功能,那么在redis持久化数据到磁盘时若是出现失败,默认状况下,redis会中止接受全部的写请求。
这样作的好处在于可让用户很明确的知道内存中的数据和磁盘上的数据已经存在不一致了。
若是redis不顾这种不一致,独断独行的继续接收写请求,就可能会引发一些灾难性的后果。
若是下一次RDB持久化成功,redis会自动恢复接受写请求。
若是不在意这种数据不一致或者有其余的手段发现和控制这种不一致的话,能够关闭这个功能,
以便在快照写入失败时,也能确保redis继续接受新的写请求。
rdbcompression yes
对于存储到磁盘中的快照,能够设置是否进行压缩存储。
若是是的话,redis会采用LZF算法进行压缩。若是你不想消耗CPU来进行压缩的话,
能够设置为关闭此功能,可是存储在磁盘上的快照会比较大。
rdbchecksum yes
在存储快照后,咱们还可让redis使用CRC64算法来进行数据校验,可是这样作会增长大约10%的性能消耗,
若是但愿获取到最大的性能提高,能够关闭此功能。
dbfilename dump.rdb
设置快照的文件名
dir /var/redis/6379
设置快照文件的存放路径,这个配置项必定是个目录,而不能是文件名
slaveof <masterip> <masterport>
主从复制,使用 slaveof 来让一个 redis 实例成为另外一个reids 实例的副本,默认关闭
注意这个只须要在 slave 上配置
masterauth <master-password>
若是 master 须要密码认证,就在这里设置,默认不设置
slave-serve-stale-data yes
当一个 slave 与 master 失去联系,或者复制正在进行的时候,
slave 可能会有两种表现:
1) 若是为 yes ,slave 仍然会应答客户端请求,但返回的数据多是过期,
或者数据多是空的在第一次同步的时候
2) 若是为 no ,在你执行除了 info he salveof 以外的其余命令时,
slave 都将返回一个 "SYNC with master in progress" 的错误
slave-read-only yes
你能够配置一个 slave 实体是否接受写入操做。
经过写入操做来存储一些短暂的数据对于一个 slave 实例来讲多是有用的,
由于相对从 master 从新同步数而言,据数据写入到 slave 会更容易被删除。
可是若是客户端由于一个错误的配置写入,也可能会致使一些问题。
从 redis 2.6 版起,默认 slaves 都是只读的。
repl-diskless-sync no
主从数据复制是否使用无硬盘复制功能。
新的从站和重连后不能继续备份的从站,须要作所谓的“彻底备份”,即将一个RDB文件从主站传送到从站。
这个传送有如下两种方式:
1)硬盘备份:redis主站建立一个新的进程,用于把RDB文件写到硬盘上。过一下子,其父进程递增地将文件传送给从站。
2)无硬盘备份:redis主站建立一个新的进程,子进程直接把RDB文件写到从站的套接字,不须要用到硬盘。
在硬盘备份的状况下,主站的子进程生成RDB文件。一旦生成,多个从站能够当即排成队列使用主站的RDB文件。
在无硬盘备份的状况下,一次RDB传送开始,新的从站到达后,须要等待如今的传送结束,才能开启新的传送。
若是使用无硬盘备份,主站会在开始传送之间等待一段时间(可配置,以秒为单位),但愿等待多个子站到达后并行传送。
在硬盘低速而网络高速(高带宽)状况下,无硬盘备份更好。
repl-diskless-sync-delay 5
当启用无硬盘备份,服务器等待一段时间后才会经过套接字向从站传送RDB文件,这个等待时间是可配置的。
这一点很重要,由于一旦传送开始,就不可能再为一个新到达的从站服务。从站则要排队等待下一次RDB传送。所以服务器等待一段
时间以期更多的从站到达。
延迟时间以秒为单位,默认为5秒。要关掉这一功能,只需将它设置为0秒,传送会当即启动。
repl-ping-slave-period 10
从redis会周期性的向主redis发出PING包,你能够经过repl_ping_slave_period指令来控制其周期,默认是10秒。
repl-timeout 60
接下来的选项为如下内容设置备份的超时时间:
1)从从站的角度,同步期间的批量传输的I/O
2)从站角度认为的主站超时(数据,ping)
3)主站角度认为的从站超时(REPLCONF ACK pings)
确认这些值比定义的repl-ping-slave-period要大,不然每次主站和从站之间通讯低速时都会被检测为超时。
repl-disable-tcp-nodelay no
同步以后是否禁用从站上的TCP_NODELAY
若是你选择yes,redis会使用较少许的TCP包和带宽向从站发送数据。但这会致使在从站增长一点数据的延时。
Linux内核默认配置状况下最多40毫秒的延时。
若是选择no,从站的数据延时不会那么多,但备份须要的带宽相对较多。
默认状况下咱们将潜在因素优化,但在高负载状况下或者在主从站都跳的状况下,把它切换为yes是个好主意。
repl-backlog-size 1mb
设置备份的工做储备大小。工做储备是一个缓冲区,当从站断开一段时间的状况时,它替从站接收存储数据,
所以当从站重连时,一般不须要彻底备份,只须要一个部分同步就能够,即把从站断开时错过的一部分数据接收。
工做储备越大,从站能够断开并稍后执行部分同步的断开时间就越长。
只要有一个从站链接,就会马上分配一个工做储备。
repl-backlog-ttl 3600
主站有一段时间没有与从站链接,对应的工做储备就会自动释放。
这个选项用于配置释放前等待的秒数,秒数从断开的那一刻开始计算,值为0表示不释放。
slave-priority 100
从站优先级是能够从redis的INFO命令输出中查到的一个整数。当主站不能正常工做时
redis sentinel使用它来选择一个从站并将它提高为主站。
低优先级的从站被认为更适合于提高,所以若是有三个从站优先级分别是10,
100,25,sentinel会选择优先级为10的从站,由于它的优先级最低。
然而优先级值为0的从站不能执行主站的角色,所以优先级为0的从站永远不会被redis sentinel提高。
默认优先级是100
min-slaves-to-write 3 min-slaves-max-lag 10
主站能够中止接受写请求,当与它链接的从站少于N个,滞后少于M秒,N个从站必须是在线状态。
延迟的秒数必须<=所定义的值,延迟秒数是从最后一次收到的来自从站的ping开始计算。ping一般是每秒一次。
这一选项并不保证N个备份都会接受写请求,可是会限制在指定秒数内因为从站数量不够致使的写操做丢失的状况。
若是想要至少3个从站且延迟少于10秒,如上配置便可
slave-announce-ip 5.5.5.5 slave-announce-port 1234
Redis master可以以不一样的方式列出所链接slave的地址和端口。
例如,“INFO replication”部分提供此信息,除了其余工具以外,Redis Sentinel还使用该信息来发现slave实例。
此信息可用的另外一个地方在masterser的“ROLE”命令的输出中。
一般由slave报告的列出的IP和地址,经过如下方式得到:
IP:经过检查slave与master链接使用的套接字的对等体地址自动检测地址。
端口:端口在复制握手期间由slavet通讯,而且一般是slave正在使用列出链接的端口。
然而,当使用端口转发或网络地址转换(NAT)时,slave实际上能够经过(不一样的IP和端口对)来到达。 slave可使用如下两个选项,以便向master报告一组特定的IP和端口,
以便INFO和ROLE将报告这些值。
若是你须要仅覆盖端口或IP地址,则不必使用这两个选项。
requirepass foobared
设置redis链接密码
rename-command CONFIG ""
将命令重命名,为了安全考虑,能够将某些重要的、危险的命令重命名。
当你把某个命令重命名成空字符串的时候就等于取消了这个命令。
maxclients 10000
设置客户端最大并发链接数,默认无限制,Redis能够同时打开的客户端链接数为Redis进程能够打开的最大文件
描述符数-32(redis server自身会使用一些),若是设置 maxclients为0
表示不做限制。当客户端链接数到达限制时,Redis会关闭新的链接并向客户端返回max number of clients reached错误信息
maxmemory <bytes>
指定Redis最大内存限制,Redis在启动时会把数据加载到内存中,达到最大内存后,Redis会先尝试清除已到期或即将到期的Key
当此方法处理 后,仍然到达最大内存设置,将没法再进行写入操做,但仍然能够进行读取操做。Redis新的vm机制,
会把Key存放内存,Value会存放在swap区,格式:maxmemory <bytes>
maxmemory-policy noeviction
当内存使用达到最大值时,redis使用的清楚策略。有如下几种能够选择:
1)volatile-lru 利用LRU算法移除设置过过时时间的key (LRU:最近使用 Least Recently Used )
2)allkeys-lru 利用LRU算法移除任何key
3)volatile-random 移除设置过过时时间的随机key
4)allkeys-random 移除随机ke
5)volatile-ttl 移除即将过时的key(minor TTL)
6)noeviction noeviction 不移除任何key,只是返回一个写错误 ,默认选项
maxmemory-samples 5
LRU 和 minimal TTL 算法都不是精准的算法,可是相对精确的算法(为了节省内存)
随意你能够选择样本大小进行检,redis默认选择3个样本进行检测,你能够经过maxmemory-samples进行设置样本数
appendonly no
默认redis使用的是rdb方式持久化,这种方式在许多应用中已经足够用了。可是redis若是中途宕机,
会致使可能有几分钟的数据丢失,根据save来策略进行持久化,Append Only File是另外一种持久化方式,
能够提供更好的持久化特性。Redis会把每次写入的数据在接收后都写入appendonly.aof文件,
每次启动时Redis都会先把这个文件的数据读入内存里,先忽略RDB文件。
appendfilename "appendonly.aof"
aof文件名
appendfsync always
appendfsync everysec
appendfsync no
aof持久化策略的配置
no表示不执行fsync,由操做系统保证数据同步到磁盘,速度最快。
always表示每次写入都执行fsync,以保证数据同步到磁盘。
everysec表示每秒执行一次fsync,可能会致使丢失这1s数据
no-appendfsync-on-rewrite no
在aof重写或者写入rdb文件的时候,会执行大量IO,此时对于everysec和always的aof模式来讲,
执行fsync会形成阻塞过长时间,no-appendfsync-on-rewrite字段设置为默认设置为no。
若是对延迟要求很高的应用,这个字段能够设置为yes,不然仍是设置为no,这样对持久化特性来讲这是更安全的选择。
设置为yes表示rewrite期间对新写操做不fsync,暂时存在内存中,等rewrite完成后再写入,默认为no,建议yes。
Linux的默认fsync策略是30秒。可能丢失30秒数据。
auto-aof-rewrite-percentage 100
aof自动重写配置,当目前aof文件大小超过上一次重写的aof文件大小的百分之多少进行重写,
即当aof文件增加到必定大小的时候,Redis可以调用bgrewriteaof对日志文件进行重写。
当前AOF文件大小是上第二天志重写获得AOF文件大小的二倍(设置为100)时,自动启动新的日志重写过程。
auto-aof-rewrite-min-size 64mb
设置容许重写的最小aof文件大小,避免了达到约定百分比但尺寸仍然很小的状况还要重写
aof-load-truncated yes
aof文件可能在尾部是不完整的,当redis启动的时候,aof文件的数据被载入内存。
重启可能发生在redis所在的主机操做系统宕机后,尤为在ext4文件系统没有加上data=ordered选项,出现这种现象
redis宕机或者异常终止不会形成尾部不完整现象,能够选择让redis退出,或者导入尽量多的数据。
若是选择的是yes,当截断的aof文件被导入的时候,会自动发布一个log给客户端而后load。
若是是no,用户必须手动redis-check-aof修复AOF文件才能够。
lua-time-limit 5000
若是达到最大时间限制(毫秒),redis会记个log,而后返回error。当一个脚本超过了最大时限。
只有SCRIPT KILL和SHUTDOWN NOSAVE能够用。第一个能够杀没有调write命令的东西。
要是已经调用了write,只能用第二个命令杀
cluster-enabled yes
集群开关,默认是不开启集群模式
cluster-config-file nodes-6379.conf
集群配置文件的名称,每一个节点都有一个集群相关的配置文件,持久化保存集群的信息。
这个文件并不须要手动配置,这个配置文件有Redis生成并更新,每一个Redis集群节点须要一个单独的配置文件
请确保与实例运行的系统中配置文件名称不冲突
cluster-node-timeout 15000
节点互连超时的阀值,集群节点超时毫秒数
cluster-slave-validity-factor 10
在进行故障转移的时候,所有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-migration-barrier 1
master的slave数量大于该值,slave才能迁移到其余孤立master上,如这个参数若被设为2,
那么只有当一个主节点拥有2 个可工做的从节点时,它的一个从节点会尝试迁移。
cluster-require-full-coverage yes
默认状况下,集群所有的slot有节点负责,集群状态才为ok,才能提供服务。
设置为no,能够在slot没有所有分配的时候提供服务。
不建议打开该配置,这样会形成分区的时候,小分区的master一直在接受写请求,而形成很长时间数据不一致
slowlog-log-slower-than 10000
slog log是用来记录redis运行中执行比较慢的命令耗时。
当命令的执行超过了指定时间,就记录在slow log中,slog log保存在内存中,因此没有IO操做。
执行时间比slowlog-log-slower-than大的请求记录到slowlog里面,单位是微秒,因此1000000就是1秒。
注意,负数时间会禁用慢查询日志,而0则会强制记录全部命令。
slowlog-max-len 128
慢查询日志长度。当一个新的命令被写进日志的时候,最老的那个记录会被删掉,这个长度没有限制。
只要有足够的内存就行,你能够经过 SLOWLOG RESET 来释放内存
latency-monitor-threshold 0
延迟监控功能是用来监控redis中执行比较缓慢的一些操做,用LATENCY打印redis实例在跑命令时的耗时图表。
只记录大于等于下边设置的值的操做,0的话,就是关闭监视。
默认延迟监控功能是关闭的,若是你须要打开,也能够经过CONFIG SET命令动态设置。
notify-keyspace-events ""
键空间通知使得客户端能够经过订阅频道或模式,来接收那些以某种方式改动了 Redis 数据集的事件。由于开启键空间通知功能须要消耗一些 CPU ,因此在默认配置下,该功能处于关闭状态。
notify-keyspace-events 的参数能够是如下字符的任意组合,它指定了服务器该发送哪些类型的通知:
K 键空间通知,全部通知以 __keyspace@__ 为前缀
E 键事件通知,全部通知以 __keyevent@__ 为前缀
g DEL 、 EXPIRE 、 RENAME 等类型无关的通用命令的通知
$ 字符串命令的通知
l 列表命令的通知
s 集合命令的通知
h 哈希命令的通知
z 有序集合命令的通知
x 过时事件:每当有过时键被删除时发送
e 驱逐(evict)事件:每当有键由于 maxmemory 政策而被删除时发送
A 参数 g$lshzxe 的别名
输入的参数中至少要有一个 K 或者 E,不然的话,无论其他的参数是什么,都不会有任何 通知被分发。
hash-max-ziplist-entries 512
hash类型的数据结构在编码上可使用ziplist和hashtable。
ziplist的特色就是文件存储(以及内存存储)所需的空间较小,在内容较小时,性能和hashtable几乎同样。
所以redis对hash类型默认采起ziplist。若是hash中条目的条目个数或者value长度达到阀值,将会被重构为hashtable。
这个参数指的是ziplist中容许存储的最大条目个数,,默认为512,建议为128
hash-max-ziplist-value 64
ziplist中容许条目value值最大字节数,默认为64,建议为1024
list-max-ziplist-size -2
当取正值的时候,表示按照数据项个数来限定每一个quicklist节点上的ziplist长度。好比,当这个参数配置成5的时候,表示每一个quicklist节点的ziplist最多包含5个数据项。
当取负值的时候,表示按照占用字节数来限定每一个quicklist节点上的ziplist长度。这时,它只能取-1到-5这五个值,每一个值含义以下:
-5: 每一个quicklist节点上的ziplist大小不能超过64 Kb。(注:1kb => 1024 bytes)
-4: 每一个quicklist节点上的ziplist大小不能超过32 Kb。
-3: 每一个quicklist节点上的ziplist大小不能超过16 Kb。
-2: 每一个quicklist节点上的ziplist大小不能超过8 Kb。(-2是Redis给出的默认值)
-1: 每一个quicklist节点上的ziplist大小不能超过4 Kb。
list-compress-depth 0
这个参数表示一个quicklist两端不被压缩的节点个数。
注:这里的节点个数是指quicklist双向链表的节点个数,而不是指ziplist里面的数据项个数。
实际上,一个quicklist节点上的ziplist,若是被压缩,就是总体被压缩的。
参数list-compress-depth的取值含义以下:
0: 是个特殊值,表示都不压缩。这是Redis的默认值。
1: 表示quicklist两端各有1个节点不压缩,中间的节点压缩。
2: 表示quicklist两端各有2个节点不压缩,中间的节点压缩。
3: 表示quicklist两端各有3个节点不压缩,中间的节点压缩。
依此类推…
因为0是个特殊值,很容易看出quicklist的头节点和尾节点老是不被压缩的,以便于在表的两端进行快速存取。
set-max-intset-entries 512
数据量小于等于set-max-intset-entries用intset,大于set-max-intset-entries用set
zset-max-ziplist-entries 128 zset-max-ziplist-value 64
数据量小于等于zset-max-ziplist-entries用ziplist,大于zset-max-ziplist-entries用zset
hll-sparse-max-bytes 3000
value大小小于等于hll-sparse-max-bytes使用稀疏数据结构(sparse)
大于hll-sparse-max-bytes使用稠密的数据结构(dense),一个比16000大的value是几乎没用的,
建议的value大概为3000。若是对CPU要求不高,对空间要求较高的,建议设置到10000左右
activerehashing yes
Redis将在每100毫秒时使用1毫秒的CPU时间来对redis的hash表进行从新hash,能够下降内存的使用。
当你的使用场景中,有很是严格的实时性须要,不可以接受Redis时不时的对请求有2毫秒的延迟的话,把这项配置为no。
若是没有这么严格的实时性要求,能够设置为yes,以便可以尽量快的释放内存
client-output-buffer-limit normal 0 0 0
对客户端输出缓冲进行限制能够强迫那些不从服务器读取数据的客户端断开链接,用来强制关闭传输缓慢的客户端。
对于normal client,第一个0表示取消hard limit,第二个0和第三个0表示取消soft limit,normal client默认取消限制,由于若是没有寻问,他们是不会接收数据的
client-output-buffer-limit slave 256mb 64mb 60
对于slave client和MONITER client,若是client-output-buffer一旦超过256mb,又或者超过64mb持续60秒,那么服务器就会当即断开客户端链接。
client-output-buffer-limit pubsub 32mb 8mb 60
对于pubsub client,若是client-output-buffer一旦超过32mb,又或者超过8mb持续60秒,那么服务器就会当即断开客户端链接。
hz 10
redis执行任务的频率为1s除以hz
aof-rewrite-incremental-fsync yes
在aof重写的时候,若是打开了aof-rewrite-incremental-fsync开关,系统会每32MB执行一次fsync。 这对于把文件写入磁盘是有帮助的,能够避免过大的延迟峰值