Redis配置文件详解

 

redis配置的详细讲解，每一项含义与原理介绍。全为本人整理、翻译，谢绝转载，谢谢合作。

一、单位

关于内存单位，一般格式如1k、5GB、4M，不用区分大小写，所以1GB、1Gb、1gB代表的意思是一样的，单位之间的转换关系如下：

#1k => 1000 bytes

#1kb => 1024 bytes

#1m => 1000000 bytes

#1mb => 1024*1024 bytes

#1g => 1000000000 bytes

#1gb => 1024*1024*1024 bytes

 

二、文件包含

当你的所有redis服务端有一个统一的标准配置，但各又有细小的差别时，可以通过标准配置文件包含“个性”配置文件的方式来配置，简单方便，so cool…

# include /path/to/local.conf

# include /path/to/other.conf

Include配置是不支持运行时命令“CONFIG REWRITE”改写的，也就是说不能通过“CONFIG REWRITE”指令来更换被包含的配置文件，当然也不能改写里面的内容。同时redis又以最后一行配置为准(你可能有重复配置同一个属性，但是以最后一个为准)，所以基于此特性，你有两个小技巧。

1.当你不想你的配置文件，在redis运行时被“CONFIG REWRITE”指令改写，那你把被包含的文件放在这个配置文件的前部。

2.当你想通过被包含文件来覆盖你的配置(即此配置文件的相同项)，那把包含项放到此文件的最后一行。

三、基本设置

1.守护进程

可以把redis server配置成守护进程，相当于windows系统下的“服务”进程，守护进程一般运行在服务器后台，没有控制终端，没有与前台交互。默认配置成非守护进程。

daemonizeno

当以守护进程模式运行的时候，redis sever把自己的pid写入到缺省文件“/var/run/redis.pid”下，你可以也可以自定义路径，如下：

pidfile/var/run/redis.pid

2.服务端口

Redis server用于接收客户端连接的TCP监听端口是6379，如果配置成0，将不会开启TCP监听服务。

port6379

 

3.最大连接数

是指redis server能接收的客户端最大连接数，它还受限于Linux的设置，所以你还得配置“/proc/sys/net/core/somaxconn”,而redis的配置如下：

tcp-backlog511

4.绑定客户端IP

Redis server缺省情况下是接收所有本服务端所有网卡的请求，但是也可以通过指定IP来绑定网卡，可以绑定多个，用空格隔开，如下：

#bind 192.168.1.100 10.0.0.1

#bind 127.0.0.1

 

5.指定Unix socket路径

在Unix系统中，默认不会开启监听，如果没有指定的话。

#unixsocket /tmp/redis.sock

#unixsocketperm 700

 

6.链路空闲超时

当链路空闲(没数据往来)超过指定值，将被断开。设置为0关闭此功能。

timeout0

 

7.TCP链路保持

如果此项配置为非0，那么在链路没有正常数据交互时，服务端将定时通过TCP ACKs包发送SO_KEEPALIVE信息给客户端，此项建议设置为60秒

此机制有助于：

1.检测已经无响应的终端

2.在网页层保持连接的活跃

在Linux系统，根据此值定时发送ACKs，当超过此值2倍时间，没有收到响应，链路装被切断。在其他内核，发送间隔基于其具体内核。

tcp-keepalive0

 

8.运行时信息级别

运行时输出的信息可分为4个级别，分别是：

debug：信息非常详尽，一般用于开发或者调试。

verbose：比较有用的信息，但是没有Debug那么冗长。

notice：比Verbose更精简，一般用于生产环境。

warning:仅仅是非常重要的消息，警告、提醒级别的。

loglevelnotice

 

9.日志文件设置

指定输入日志信息的文件，如果为空，将从标准输出窗口输出，同时又设置了守护进程模式的话，将会把日志记录到/dev/null

logfile""

如果想把通过系统日志记录器记录日志，可以把syslog-enabled设置为yes：

#syslog-enabled no

 

设置系统日志标识：

#syslog-ident redis

 

系统日志工具设置，必须是USER或者LOCAL0~LOCAL7之一：

#syslog-facility local0

 

10.数据库数

可以给redis server设定数据库数据，客户端建立连接上，默认连接的是0号数据库，可能通过指令select来切换数据库，数据库ID是基于0的，取值范围：0~databases-1。

databases16

 

11.保护模式

默认情况下，redis实例是在保护模式下运行的，保护模式下的实例，只能回路下的客户端才能访问，如果你想其他服务器可以访问，把以下项设置成no。此模式下安全问题可以通过bind指令绑定客户端的IP，或者直接给设置访问密码requirepass指令来解决。

protected-modeyes

四、快照同步

1.同步触发

把数据库(内存里)里的数据，同步到硬盘有两种方式，AOF与SNAPSHOTTING，后者即快照方式同步数据，此处要介绍的是触发快照同步的条件的配置。

触发同步条件有两个：时间与更新数，两个条件相互结合，条件满足即会触发同步。第一个参数是时间，单位秒，第二个是更新数，而且可以配置多条，结合使用，如下格式如下：

#save

save900 1

save300 10

save60 10000

以上三条分配是900秒内有一条记录更新，300秒内有10条更新，60秒内有10000条更新，所有条件是或的关系，只有任意一条满足，即将触发。

如果想关闭此功能，格式如下：

save""

如果快照同步方式开关打开，但是同步失败的情况下，redis的写入功能也将失效，同时也不会得到提示，那是很悲剧的，你只能祈求它，在你能够发现并处理之前，别发生什么灾难性的问题。

如果同步工作恢复正常工作后，那redis的写入功能也将得到恢复。

如果你的redis做了很好的监控、持久化机制，那你可以把此功能关闭，即把以下配置的yes改成no，这样即使同步到硬盘的操作异常，也不影响redis的写入功能。

stop-writes-on-bgsave-erroryes

2.压缩保存

以快照方式同步数据到硬盘的时候，可以把数据按LZF算法压缩，当然，压缩需要消耗一些CPU，你也可以把此开关关闭，但是存储的数据会更大一些，消耗一些存储空间，配置如下：

rdbcompressionyes

3.CRC64校验

从RDB的version版本，就对整个文件进行了CRC64校验，并把校验值存储到了文件的最末尾，它提高了数据安全可靠性。但是，在同步与装载快照文件时，执行效率将要打10%的折扣，如果你对此不爽就把它关了吧。

rdbchecksumyes

 

4.快照文件名

存放快照文件的文件名，默认是dump.rdb,可以自定义文件名，扩展名你就别动它了。

dbfilenamedump.rdb

 

5.文件路径

以上(第4节)只是设置的文件名，而非路径，通过命令dir可以指定路径，文件将按指定路径与指定的文件名存储。同时AOF（Append Only File）也是参照此路径的。

dir./

 

五、主从复制

这是一种安全机制，让一个slave实例成为一个master实例的副本，对master的数据进行定时的备份。关于主从复制，以下几点你是应该知道的：

1.主从复制时是异常通信的，然后你可以把它配置成不可写的状态，当主服务无法联系上任意一个指定的从服务时。

2.当主从短暂中断连接后，从可以实行部分数据(没同步的部分)再同步，但是，你需要配置一下缓存大小，具体见后章节。

3.主从复制是原子方式进行的，并且不需要人为干预的。当网络环境变化时，从服务将会自动的与主重新建立连接，并重新做同步工作。

1.从服务配置

给一redis实例指定所属的主服务的IP与端口，如下：

#slaveof

 

2.密码认证

如果主服务是保护模式运行的话，那么在从连接上主服务器，会要求先进行认证，才能获取数据同步，不然，所有请求都将被拒绝。

#masterauth

 

3.同步进行时、从的服务模式

当从服务与主失去连接或者说同步正进行时，对于客户端的请求，根据slave-serve-stale-data的设置不同，会有不同的表现。

1.如果设置为yes（缺省值），对于客户端的请求，服务一直是可获得的。当然也可能会是没有数据返回的，如果这是第一次同步而导致从服务端没有数据的情况下。

2.如果设置为no，所有客户端的请求操作都会得到"SYNC with master in progr

ess"的回应，除INFO与SLAVEOF命令外。

slave-serve-stale-datayes

 

4.从服务只读/可写

对于从服务，默认是只读的，但高于2.6版本(含)的redis从服务可配置成可写，虽然当下次同步的时候，写入的数据将被擦除，同时它因为设置问题，了可能导致一些定入错误。

然而，从服务只读的功能只是一种防止误操作的保护机制，并不代表可以随意放到不安全的网络环境中。对于安全问题，有一处改进方案，就是对危险操作的指令通过指令rename-command重命名，改成狗都认识的乱码。

slave-read-only yes

5.有/无硬盘复制

主从复制分有硬盘与socket两种方式。当新的从服务建立或者从服务断开重连后，有可能要与主之间进行“全复制“，即把主这边的快照文件完全复制到从，这种数据的传输方式有两种：

1.硬盘作媒介，主服务创建一个新的进程，负责在硬盘创建一个新的快照文件，然后通过主服务的父线程把快照文件传送给从服务来实现同步。

2.无硬盘方式，主服务会创建一个进程，进入通过socket传输快照文件给从服务。

硬盘模式，当快照文件生成后，从服务可排队挨个地通过快照文件得到同步。而无硬盘模式，如果同步已经开始，那么后到的从服务只能排队，等待先到的已经开始同步的从服务完成同步后，才能获取服务。

无硬盘模式下，主服务将会按配置设置的值，等待N秒钟，希望从服务都尽量到齐，来一起(并行)同步。

与蜗速的硬盘速度相比，socket传输能飞起来的，铁定是无硬盘模式更胜一筹，但是，你得想想你的带宽问题。

repl-diskless-syncno

6.等待开饭

当同步方式设置成了无硬盘方式的话，那主服务在同步数据之前，会等待一定的时间，等待从服务们都尽量到齐，然后一起并行同步。不然的话，前先到的已经在同步的话，后到的将要等到下一次同步才能得到服务，所以还是等等大家吧，总不能一直等吧，某些人就是爱迟到，那下面大家商量一个等待时间吧。那可是以秒计时的哦，亲。

repl-diskless-sync-delay5

 

7.心跳

所有从服务都要按设定的时间间隔给自己的主服务发送Ping请求，默认真是10秒。

#repl-ping-slave-period 10

 

8.响应超时

#The following option sets the replication timeout for:

#

#1) Bulk transfer I/O during SYNC, from the point of view of slave.

#2) Master timeout from the point of view of slaves (data, pings).

#3) Slave timeout from the point of view of masters (REPLCONF ACK pings).

#

#It is important to make sure that this value is greater than the value

必须保证比repl-ping-slave-period设定的值大，默认为60秒

#repl-timeout 60

9.延迟发送

这个是比较深层的技术问题，是指一有数据就立即发送，还是结合时间、数据等因素来约定是否发送。这个叫作TCP_NODELAY具体细节可查看相关技术文献。Linux内核默认延迟时间是40毫秒。此处指主服务给从服务发送数据。

如果你设置为yes，发送的TCP包，将更小包化，因为不延时嘛，所以一有数据就发，所以对带宽的要求也更低，副作用是它将增加总体数据的传输时间

如果设置为no，总体传输时间将下降，但是对带宽要求高些，因为你相当于一次发的量大嘛

然而，传输的有交数据总量是一样的，但是前者会传输次数比后者多，每传输一次将有额外包头开销。

如果想要在低延时方面取得更好的效果，同时有好的带宽，或者主从服务之间有很多跳点(经过多路由)，设置成yes也许是个好主意。

repl-disable-tcp-nodelayno

 

10.缓存大小

指主服务给从服务复制数据时的缓存空间大小，当主从服务之间的链路断开后，主服务要传输给从服务的数据就可以先放到缓存里，当从服务再次恢复连接后，就可能得到断开期间的全部数据，而不需要进行“全复制”，所以缓存越大，只进行局部复制的可能性就越大，换句话说，允许从连接断线的时间就越长，缓存空间是在第一个从服务连接后分配的。

#repl-backlog-size 1mb

 

11.缓存释放时间

当一个主服务与最后一个从服务断开连接后，N秒钟再也没有被从服务连接的话，缓存空间将要被释放，如果设置成0，将永远不会被释放。

#repl-backlog-ttl 3600

12.提升优先权

从服务被提升为主服务的优先级，是一个整数。在主服务无法正常工作的情况下，用于redis Setinel（redis哨兵）提升从服务为主服务用的。数值越小，优先级越高，如果为0的话，永远不会被提升为主服务。优先级的缺省值为100。

slave-priority100

 

13.主服务停止写入

可以设置主服务在以下两种条件下停止被写入，1.少于N个从服务连接，延时超过M秒。以下两个项只要设置其中一项为0，关闭此功能。默认min-slaves-to

-write设置为0，min-slaves-max-lag为10秒。

#min-slaves-to-write 3

#min-slaves-max-lag 10

 

六、安全

1.认证

可以增加密码，对连接的客户端，必须先发起认证，在通过后其他请求才能有效，这样对不信任的访问可以起到一定的安全保护。然而，redis的服务端响应超快，一秒钟能响应150k的认证，所以你需要一个非常强大的密码来降低被暴力破解的大冒险。

#requirepass foobared

 

2.重命名指令

在一些公司不受信任的环境里，可以对一些危险的指令进行重命名，命令成很难猜测的名字，例如重命令CONFIG指令如下：

#rename-command CONFIG b840fc02d524045429941cc15f59e41cb7be6c52

也可以直接让某命令失效，如：

#rename-command CONFIG ""

值得注意的是，重命名的操作如果被存入了AOF文件或者传给了从服务，那可能会导致一些问题。

 

七、限制

1.最大连接数限制

redis服务端的最大连接数默认是1000，如果由于进程文件受限，无法达到你设置的这个数，那你需要把这个值减去32，因为redis需要保留一些连接自己内部使用。当连接数达到顶值，那新来的连接将收到错误信息“max number of clients reached”并被关闭

#maxclients 10000

 

2.内存限制

如果使用的内存超过设定的值，那有些键将会按照你选择的移除策略被移除，不能被移除或者是移除策略被设置成了noeviction，对于需要分配消耗内存的命令将返回错误，如set,push等命令，而对只读命令如get将还能正常服务。

如果有从服务连接到一个开启了最大内存限制的主服务实例时，最大内存数需要减去为从服务分配的输出缓存，剩下的才是其能够分配的内存空间。

#WARNING: If you have slaves attached to an instance with maxmemory on,

#the size of the output buffers needed to feed the slaves are subtracted

#from the used memory count, so that network problems / resyncs will

#not trigger a loop where keys are evicted, and in turn the output

#buffer of slaves is full with DELs of keys evicted triggering the deletion

#of more keys, and so forth until the database is completely emptied.

#

总之，如果你的主服务配置了从服务，建议你对内存放宽限制，以便有更多空间分配给从服务的输出缓存。当然，如果移除策略配置成了“noeviction”就没有必要了。

#maxmemory

 

3.最大内存策略

当内存使用已经达到设置的上限，这里有5种策略来决定什么数据从内存总移除。1.移除那些通过LRU算法来设定了有效期的，2.通过LRU算法移除任何数据，3.随机移除那些设置了有效期的，4.随机移除，5.移除那些设置了有效期，交最快到期的。无论选择以上任何一种策略，对于写操作如果没有合适的数据可以被删除的话都将返回错误。当然，你可以设置成不移除任何值(不选择以上任一策略)，对写操作只返回错误。

#volatile-lru -> remove the key with an expire set using an LRU algorithm

#allkeys-lru -> remove any key according to the LRU algorithm

#volatile-random -> remove a random key with an expire set

#allkeys-random -> remove a random key, any key

#volatile-ttl -> remove the key with the nearest expire time (minor TTL)

#noeviction -> don't expire at all, just return an error on write

写操作的命令有：

#setsetnx setex append incr decr rpush lpush rpushx lpushx linsert lset rpoplpushsadd sinter sinterstore sunion sunionstore sdiff sdiffstore zadd zincrby zunionstorezinterstore hset hsetnx hmset hincrby incrby decrby getset mset msetnx execsort

内存策略默认设置如下：

#maxmemory-policy noeviction

 

4.样本因子

LRU和minimal TTL算法不是精准的算法，但是相对准确(用于节省内存)，可以在速度与准确性之间进行权衡，调节一个合适的样本因子(取样个数)，默认取样数是5，然后取5个样本中最近用得最少的进行移除。样本因子取5是经过验证比较合适的，取10的准确度比较高但是更耗CPU，3的话速度倒是很快，但是准确度有欠缺。

#maxmemory-samples 5

 

八、AOF备份

AOF即APPEND ONLY FILE备份模式，redis默认情况下会把数据以异步的模式镜像备份到硬盘，这种方式在很多应用程序是足够满足要求的，但是如果遇到redis运行问题或者忽然断电之类的问题，就可能导致几分钟的数据丢失(丢失数据多少与保存的配置有关)。AOF即是一种可靠性比较好的持久化方案，使用默认的数据同步方案，即使发生忽然断电的突发情况也只会丢失一秒钟的写入数据，如果是redis自身异常的话只会丢失一条数据，首先是操作系统得运行OK的情况下。

1.AOF开关

AOF与RDB两个持久化方案可同时使用，如果开启了AOF持久化方案，Redis启动的时候将会加载比RDB更可靠的AOF文件。以下命令配置AOF。

appendonlyno

2.AOF文件名

AOF备份的文件名通过以下命令配置。

appendfilename"appendonly.aof"

3.写入方式

AOF备份时会调用fsync()函数，它会让操作系统把数据立即写入到硬盘，而不会依赖于输出缓存区数据的多少，部分系统会真实的把数据立即存入硬盘，而有些只是尽力而为，而redis支持三种模式：

#no:不是同步方式，只是让系统存储数据，什么时候存系统决定：比较快。

#always:同步的，在每个一个数据写入append only日志后，：慢，但最安全。

#everysec:每秒一次：折中方案。

默认选择的是"everysec",它是权衡了速度与可靠性的折中方案，如果你因为效率的因素，选择了"no"，让操作系统来决定什么时候把输出缓存的数据刷入硬盘，同时你也可以考虑默认的快照备份方案，只要你能容忍数据一定程度的丢失。相反，选择"always"虽然效率最差，但比"everysec"更安全的策略。更多详细信息参考以下链接：

#http://antirez.com/post/redis-persistence-demystified.html

#appendfsync always

appendfsynceverysec

#appendfsync no

4.阻塞

当AOF的fsync策略被设置成alwasys或者everysec时，负责写入的工作的后台进程的I/O量是非常大的，在某些Linux系统配置中，可能会导致redis不确定的时长的堵塞。即使在不同的线程里处理，也一样可能导致everysec写操作的阻塞，为解决这个问题，可以采用如下配置：

no-appendfsync-on-rewrite yes

它将阻止主进程通过fsync对BGSAVE或BGREWRITEAOF的调用，而是在子进程里处理，但是它的处理效果相当于"appendfsync none"配置，同时它可能导致30秒钟的数据丢失，在最坏情况下。所以，如果有延迟阻塞问题，把此项配置成yes，不然，配置成no

5.重写增量

当AOF文件达到一定量的时候，将会调用BGREWRITEAOF被重写，为了避免频率的重写，你可以指定一个百分比，当增量达到一比例后再触发重写，同时还可以指定一个容量值(单位MB)，以避免因增加的容量太小而指定的百分比达到指定值，而导致的频率重写的问题。

auto-aof-rewrite-percentage100

auto-aof-rewrite-min-size64mb

6.AOF清除策略

当redis启动后，可能会发现所要的AOF文件被清除了，那可能产生一些问题，对这种情况采取以下配置来控制，如果设置成yes，redis server发现没有AOF文件的话，会生成一个日志来通知用户；如果设置成no的话，redis server会异常中断工作，这个时候用户得通过redis-check-aof工具修复AOF文件后再重启redis。

aof-load-truncatedyes

运行redis的服务器发生异常的情况下，会发生AOF文件被清除的情况，特别是没有配置data=ordered option的ext4文件系统(是什么鬼，请自行查阅ext4文件系统相关资料)。然而，在redis自身异常、中断，同时操作系统工作正常的情况下，这种AOF文件被干掉的情况是不会发生的。

九、LUA SCRIPTING

redis执行LUA脚本可能会很耗时，这里我们可以设置其最大时限。单位：毫秒。设置成0或者负值，那对脚本运行就不会超时限制，也不会产生告警。

lua-time-limit5000

当脚本执行超过了指定时限，redis将会记录一个相关的日志，同时对所有请求将会以错误回应。这个时候只有两个命令可以被接收SCRIPT KILL 和 SHUTDOWN NOSAVE。前者用于结束运行的脚本；当脚本的写命令已经发出，但是一直在运行中，并且超时了，这个时候，其他写操作请求就得不到服务了，如果用户实在等不及了，那只有通过SHUTDOWN NOSAVE指令来结束redis 服务，这是唯一途径。

十、集群

redis的集群技术是被认为稳定的，但是想把它贴上“成熟”方案的标签，要等待更多的用户在生产环境中使用验证，得到更多的健壮运行的报告。

1.集群开关

普通的redis实例是不能成为集群的一部分的，只有当作一个群集的“节点”（NODE）运行时才行。那把以后配置的注释(#)去掉，就可以了。

#cluster-enabled yes

2.节点配置文件

每个节点都有自己的非人工可逻辑的配置文件，它由节点来创建、更新。每个节点有自己唯一的一个配置文件，所以在同一个系统需要保证没有同名的配置文件。

#cluster-config-file nodes-6379.conf

 

3.链接超时

各节点如果超过一定时间失去连接，那它将被认为是失效的状态，一般内部时限(指系统，链路之类的吧)要比这个值大（应该是告诉你，别把这个值设置的太大了），超时时限单位为毫秒。

#cluster-node-timeout 15000

4.被提升的权重计算

当主服务down了，从服务时需要提升为主服务进行替代的，但是如果从服务的数据过于老旧，那就是我们想要的了，而关于数据的更新时间，并没有好的测算方式，所以通过以下两种方法来检测：

1.如果有多个备选的从服务可提升为主服务，他们之间会相互交换信息，通过比较从原主服务复制来的数据的量差，进行优化排序，最出主优的从服务以提升为主服务。

2.第二种方式是通过与主服务最后交互时间来确认，如ping或其他命令最后交互时间(如果与主服务连接一直正常的话)，或者与主服务失去连接的时间等信息来分析判断，如果交互时间太旧，这个从服务端就不合适提升为主服务了。

对于上二种方式，用户是可以调节的，如果与主服务失去连接的时长超过以下值的总量：(node-timeout * slave-validity-factor) + repl-ping-slave-period。

5.从服务有效因子

从服务有效因子如果比较大的话，那对从服务数据越旧的容忍度就越大(数据很旧但是也可以提升为主服务)，相反，一个比较小的因子，那就很容易让数据稍旧的从服务无资格提升为主服务了。

如果你把有效因为设置为0，那它是最后的备选方案，也就是说它还是会通过以上(第4节)逻辑来交换信息，以此削减自己的权重，如果没有比他更优的从服务来提升为主服务的话，最它就是最终备选了，它是唯一方法来确保有从服务能提升为主服务的方案。

#cluster-slave-validity-factor 10

6.过继

每个主服务都应该有从服务的，如果没有(一般开始有，运行中down了)，那就像一个人没有儿子，这个时候一般会让孩子多的兄弟过继一个孩子给他，以续香火，以防不测。redis集群也一样，如果某个主服务没有从服务了，那在其他主服务有多余(它自己有多于一个从的情况下)从服务的情况下，将会过继一个从服务给它。那怎么个过继规则呢？多余migration barrier个从服务的时候，可符合过继条件，如migration barrier为1的话，意思是自己最少有一个从服务而还有多的情况下，可以过继一个给其他“绝后”的主服务，一般这个值默认为1。如果你不想过继给别人，那把这个值设置的足够大即可。设置为0一般是用于调试，同时在生产环境中也是非常危险的。

#cluster-migration-barrier 1

7.hash槽

正常情况下，所有hash槽都会有节点提供服务的，如果有一个hash槽没有节点给它提供服务的话(集群局部down了)，那整个集群都会不可用，直到所有槽都恢复服务为止。

然而，如果你希望出现局部hash槽down的情况下，某些正常hash槽还能接受服务请求，那把以下项设置成no即可。

#cluster-require-full-coverage yes

 

十一、蜗牛日记

SLOW LOG我叫它为蜗牛日记，是用来记录某些执行超时的请求，这个时间不包括I/O操作，只是纯粹的命令执行时间，它一般是个阻塞的耗时操作，这个时候不能响应其他请求，才为此类。

1.蜗速标准

指执行时长(单位：微秒)达到多少时，才算蜗速，并记入日志。设置为负数的话，关闭此功能，如果为0的话，则表示记录所有指令的执行时间。

slowlog-log-slower-than10000

2.队列长度

记录的日志队列有一个参考长度，它并不是强制限制的，只是用于对内存使用的一个参考，当你使用SLOWLOG RESET命令时，你可以以此收回内存。，如果有新记录需要记录，那么最旧的那个记录将被替换。

slowlog-max-len128

十二、延时监控

用于监控redis运行时的耗时问题，收集可能导致延时问题的源头。延时信息可能简单的通过LATENCY命令输出到图形界面，并能重复获取。它只记录延时不小于指定值的记录，时限单位为毫秒，可以通过以下配置项配置。

latency-monitor-threshold0

如果设置为0那代表关闭此功能，默认情况下是关闭的，但是在运行时，也可以通过"CONFIG SET latency-monitor-threshold"命令简单开启。

十三、事件通知

它可以通知发布/订阅客户端相关的的键发生的一些事件，这个功能在有详细说明http://redis.io/topics/notifications。如果事件通知功能开启的话，如客户端删除一个存储在0号数据库的键foo，那两个消息会被发布：

#PUBLISH __keyspace@0__:foo del

#PUBLISH __keyevent@0__:del foo

你可以通过一个“类”集合选择你关注的事件，每个“类”被一个字符标记，如下是类集合列表，我就不翻译了，一看就懂：

#  K    Keyspace events, published with __keyspace@__ prefix.

#  E    Keyevent events, published with __keyevent@__ prefix.

#  g    Generic commands (non-type specific) like DEL, EXPIRE,RENAME

#  $    String commands

#  l    List commands

#  s    Set commands

#  h    Hash commands

#  z    Sorted set commands

#  x    Expired events (events generated every time a key expires)

#  e    Evicted events (events generated when a key is evicted for maxmemory)

#  A    Alias for g$lshzxe, so that the "AKE" string means all theevents.

开启事件通知功能通过notify-keyspace-events项来设置，它后续的参数是由多个字符组成的字符串，如果为空的话代表关闭此功能。例如，开启列表与普通事件，设置如下：

#  notify-keyspace-events Elg

此功能默认是关闭的，如下：

notify-keyspace-events""

十三、高级配置

1.hash编码

当hash表元素总数没超过指定量，并且最大元素也没超出指定值时，hash是用一种高效的内存数据结构来编码的。以下是两个临界值的设置：

hash-max-ziplist-entries512

hash-max-ziplist-value64

2.队列编码

#Similarly to hashes, small lists are also encoded in a special way in order

#to save a lot of space. The special representation is only used when

#you are under the following limits:

 

list-max-ziplist-entries512

list-max-ziplist-value64

 

#Sets have a special encoding in just one case: when a set is composed

#of just strings that happen to be integers in radix 10 in the range

#of 64 bit signed integers.

#The following configuration setting sets the limit in the size of the

#set in order to use this special memory saving encoding.

set-max-intset-entries512

 

#Similarly to hashes and lists, sorted sets are also specially encoded in

#order to save a lot of space. This encoding is only used when the length and

#elements of a sorted set are below the following limits:

zset-max-ziplist-entries128

zset-max-ziplist-value64

 

#HyperLogLog sparse representation bytes limit. The limit includes the

#16 bytes header. When an HyperLogLog using the sparse representation crosses

#this limit, it is converted into the dense representation.

#

#A value greater than 16000 is totally useless, since at that point the

#dense representation is more memory efficient.

#

#The suggested value is ~ 3000 in order to have the benefits of

#the space efficient encoding without slowing down too much PFADD,

#which is O(N) with the sparse encoding. The value can be raised to

#~ 10000 when CPU is not a concern, but space is, and the data set is

#composed of many HyperLogLogs with cardinality in the 0 - 15000 range.

hll-sparse-max-bytes3000

 

#Active rehashing uses 1 millisecond every 100 milliseconds of CPU time in

#order to help rehashing the main Redis hash table (the one mapping top-level

#keys to values). The hash table implementation Redis uses (see dict.c)

#performs a lazy rehashing: the more operation you run into a hash table

#that is rehashing, the more rehashing "steps" are performed, so ifthe

#server is idle the rehashing is never complete and some more memory is used

#by the hash table.

#

#The default is to use this millisecond 10 times every second in order to

#actively rehash the main dictionaries, freeing memory when possible.

#

#If unsure:

#use "activerehashing no" if you have hard latency requirements and itis

#not a good thing in your environment that Redis can reply from time to time

#to queries with 2 milliseconds delay.

#

#use "activerehashing yes" if you don't have such hard requirementsbut

#want to free memory asap when possible.

activerehashingyes

 

#The client output buffer limits can be used to force disconnection of clients

#that are not reading data from the server fast enough for some reason (a

#common reason is that a Pub/Sub client can't consume messages as fast as the

#publisher can produce them).

#

#The limit can be set differently for the three different classes of clients:

#

#normal -> normal clients including MONITOR clients

#slave  -> slave clients

#pubsub -> clients subscribed to at least one pubsub channel or pattern

#

#The syntax of every client-output-buffer-limit directive is the following:

#

#client-output-buffer-limit

#

#A client is immediately disconnected once the hard limit is reached, or if

#the soft limit is reached and remains reached for the specified number of

#seconds (continuously).

#So for instance if the hard limit is 32 megabytes and the soft limit is

#16 megabytes / 10 seconds, the client will get disconnected immediately

#if the size of the output buffers reach 32 megabytes, but will also get

#disconnected if the client reaches 16 megabytes and continuously overcomes

#the limit for 10 seconds.

#

#By default normal clients are not limited because they don't receive data

#without asking (in a push way), but just after a request, so only

#asynchronous clients may create a scenario where data is requested faster

#than it can read.

#

#Instead there is a default limit for pubsub and slave clients, since

#subscribers and slaves receive data in a push fashion.

#

#Both the hard or the soft limit can be disabled by setting them to zero.

client-output-buffer-limitnormal 0 0 0

client-output-buffer-limitslave 256mb 64mb 60

client-output-buffer-limitpubsub 32mb 8mb 60

 

#Redis calls an internal function to perform many background tasks, like

#closing connections of clients in timeout, purging expired keys that are

#never requested, and so forth.

#

#Not all tasks are performed with the same frequency, but Redis checks for

#tasks to perform according to the specified "hz" value.

#

#By default "hz" is set to 10. Raising the value will use more CPUwhen

#Redis is idle, but at the same time will make Redis more responsive when

#there are many keys expiring at the same time, and timeouts may be

#handled with more precision.

#

#The range is between 1 and 500, however a value over 100 is usually not

#a good idea. Most users should use the default of 10 and raise this up to

#100 only in environments where very low latency is required.

hz10

 

#When a child rewrites the AOF file, if the following option is enabled

#the file will be fsync-ed every 32 MB of data generated. This is useful

#in order to commit the file to the disk more incrementally and avoid

#big latency spikes.

aof-rewrite-incremental-fsyncyes