Redis 3.0配置

配置文件说明

使用redis.conf; 在配置文件中，可以使用下面的方式来对配置项进行配置：

keyword argument1 argument2 ... argumentN

比如：

slaveof 127.0.0.1 6380

可以使用双引号将带有空格的参数包含起来，比如：

requirepass "hello world"

Redis 3.0的配置文件

• 为了让Redis读取配置文件，在启动redis的时候，必须将配置文件路径作为redis-server命令的第一个参数，比如：

./redis-server/path/to/redis.conf

 

• 内存大小的单位，使用k,GB,M,MB等作为单位是可以得，而且这些都是大小写不敏感的，所以很方便

     INCLUDE配置

• 可以在配置文件中使用include项来包含其它配置文件，这个对于拥有多个redis服务的时候很有用，可以先制作一个配置模板，然后对于某个redis服务有特定要求的，可以进行定制。

注意：当使用admin或Redis Sentinel的“CONFIGREWRITE”命令来重写redis.conf文件，include配置项是不会被重写的。由于redis总是使用读取到的配置项作为最终配置，如果为了使得include的配置不会被重写，应该将include配置放在配置文件的末尾；如果include的配置可以被重写，那么就将include配置放在配置文件的开头

     基本配置

• demonized：默认情况下，redis不是在后台运行的，为了使redis在后台运行，这个配置项需要修改为yes

• pidfile：当redis在后台运行的时候，Redis会将进程ID写入一个文件，默认情况下是写入/var/run/redis.pid；如果想修改文件名称，可以在这里修改。
• port：监听连接的端口号配置，默认为6379；如果配置为0，Redis不会创建监听套接字
• tcp-backlog：配置listen函数的backlog参数；在并发数比较高的场景下，应该将这个值配置大些，以免出现慢客户端连接的问题。注意：Linux内核会自动将这个值缩小到/proc/sys/net/core/somaxconn的值，所以为了设置较大的值生效，需要先提高somaxconn和tcp_max_syn_backlog的值。
• bind：默认情况下，Redis会绑定服务器上所有的网络接口，但是我们可以通过这个配置，让Redis绑定到一个或几个网络接口上；比如：

bind 192.168.1.100 10.0.0.1

• unixsocket和unixsocketperm：配置Unix域套接字的路径和权限，因为默认情况是不会使用Unix域套接字来监听端口的，所以很少使用。
• timeout：关闭一个客户端连接，如果这个连接在timeout时间内都是空闲的。默认为0，永远都不会关闭连接。
• tcp-keepalive：如果非0，在没有通信的情况下，则使用SO_KEEPALIVE套接字选项去发送keepalive探测报文；这个有两个作用：1）检测已经退出的客户端 2）从网络设备的角度来查看连接是不是活的；在Linux上，配置的值（以秒为单位）是发送探测报文的周期时长；注意：关闭一个连接，需要两倍的时间。一个建议值是：60秒
• loglevel：设置日志级别，debug -> verbose -> notice -> warning; 默认是notice 级别。
• logfile：设置日志文件的名称；如果为空，则日志写入到标准输出上；如果没有配置logfile，然后又设置demonized选项为yes，那么日志都被重定向到/dev/null上。
• syslog-enable:开启写入系统日志，可以设置为yes，默认为no
• syslog-ident:写入syslog时，日志中进程的名称，默认为redis
• syslog-facility：syslog的级别，默认为local0
• databases：设置数据库的数目，默认为16个；

持久化配置

• save：可以设定过了多长时间或者数据库发生了多少次操作则进行持久化操作。

save 900 1
save 300 10
save 60 10000

上面的配置表示，在900秒内至少有一次修改；在300秒内至少有10次修改；在60秒内，至少有10000次修改，则进行持久化。

• stop-writes-on-bgsave-error:  Redis默认会开启RDB快照。如果上次写入快照文件失败，Redis不会再接收任何其它的RDB写的请求。这样用户就可以及时发现数据没有正常的写入磁盘；否则的话没有人知道错误已经发生，最终整个数据都被破坏了。如果持久化工作恢复正常了，Redis会自动恢复接收写RDB快照的请求。不过，如果你已经建立了对Redis server和持久化的监控机制，你也可以将这个配置设置为no，这样即使磁盘出现了问题（或者权限问题），Redis还是可以正常进行工作。
• rdb-compression：写入rdb文件时，对string对象使用LZF进行压缩，默认为开启的；如果需要节省CPU，可以将其设置为no
• rdb-checksum:从RDB格式的第5个版本以后，在RDB文件的最后都会写入一个CRC64的校验和，这样做可以确保文件的一致性；但是开启这个选项，在写入和加载RDB文件的时候，会带来将近10%的性能消耗。如果取消了rdb-checksum选项，那么checksum被置为0，这样加载进程发现checksum为0，就不会进行checksum计算
• dbfilename：RDB的文件名称
• dir：文件存放的目录

复制

• slaveof：该配置使得当前Redis实例称为另外一个Redis的备机；关于主备复制，我们注意：

1）Redis的复制操作是异步的，但是我们可以配置一个mater停止接受写的请求，如果mater当前没有足够数目的slave

2）如果slave和mater之间的连接中断了很小的时间，slave还是能够和master进行部分重同步，而不是全量同步。这个可以通过设置backlog的大小来实现（见下面的配置说明）

3）复制操作是自动进行的，不需要人工的参与；在网络恢复之后，slave会自动重连master，并进行数据同步

• masterauth：如果master是密码保护的，则需要配置master的密码，否则，mater会拒绝同步
• slave-serve-stale-data：默认为yes，那么在slave和master连接已经断开的情况下，slave会继续接受请求，虽然请求的数据可能是过期的数据或者是空值，如果数据之前还没有同步过来的话。如果设置为no，则对任何命令（除了INFO和SLAVEOF）都返回“SYNC with master in progress”的错误信息。
• slave-read-only:默认为yes；一般都不会配置为no，因为slave写入的数据会被主同步的数据覆盖掉。

/*****以下两个配置为无盘配置，这个功能还处于试验状态******/

• repl-diskless-sync::新的slave和重新连接上的slave，如果发现不一致，就会执行“全量同步”；RDB文件会从master发送到slave，这里有两种方式：1）disk-backed:redis master创建一个新的进程将RDB文件写入硬盘；然后父进程将文件发送给slaves2）diskless：redis master创建一个新的进程，它直接将RDB文件写入到slave的套接字上，这样就不需要任何磁盘操作了。使用disk-backed模式的时候，当RDB文件正在写的时候，slave进行排队，当文件生成完毕，那么slave将会得到RDB文件的内容；使用diskless模式的时候，master在等待了一段时间后，会启动数据传输，如果在传输过程中有slave过来，那么这些slave会被放入队列中，在前面的slave同步完成之后，再进行排队中的slave同步。

当使用diskless模式的时候，master可配置一个等待时间，master期望在这个等待时间之内所有slave都连接上来，这样可以进行并发传输。

如果磁盘速度比较慢，而网络非常快，使用diskless传输方式会更好。

• repl-diskless-sync-delay:这个就是用来配置上述等待时间的。默认为5秒，如果配置为0，那么有slave过来就会进行传输（也就是ASAP：as soon as possible）
• repl-ping-slave-period:slaves会周期性地发送PINGs到master上，这个周期可以通过它进行配置，默认为10秒
• repl-timeout：本配置项设置的超时时间是：1）从slave来看，在SYNC的过程中有大量的I/O传输2）从slave来看，Master超时了（无论是发送数据还是ping） 3）从master来看，slave超时了 这个选项的值一定要大于repl-ping-slave-period，否则的话，在链路空闲的时候会不断地检测到超时；
• repl-disable-tcp-nodelay：如果设置为yes，那么Redis将会使用更少数目的报文和更小的带宽来发送数据，但是这会导致数据在slave上更新会晚些；默认是no，也就是开启tcp nodelay。
• repl-backlog-size：设置复制的backlog大小；当slave断开连接后，master会申请一个backlog，它是一个用来存放slave数据的缓存，这样，当slave重新连接上的时候就不用进行全量同步了，只要将缓存的数据进行同步就可以了。这个值越大，slave可以断开的时间就越长（不需要进行全量同步）；backlog只会分配一次，分配的时候是一旦有slave连接上来了。

• repl-backlog-ttl: 如果master过了这个配置的时间都还没有slave连接上来，那么backlog的空间就会被释放掉；这里配置的时间是从最后一个slave断开连接的时候开始计算的。
• slave-priority：通过INFO命令可以看到这个整数值；当master down掉的时候，Redis sentinel使用这个值来选择一个slave称为master；这个值越小，优先级越高；但是如果这个值为0，表示slave不会参与到master选举当中，也就是设置为0，它永远不会成为master。
• min-slaves-to-write和min-slaves-max-lag：Redis 的master可以配置为，如果有少于N个slave连接到master上面，并且持续了M秒钟，那么master会拒绝进行write操作。N就是min-slaves-to-write配置的值；M就是min-slaves-max-lag配置的值。lag time是从最后一次收到salve的ping来开始计算的。 这两个配置中的其中一个设置为0，则这个特性会失效。默认情况下，min-slaves-to-write为0，min-slaves-max-lag为10

安全

• requirepass：如果配置了这个项，那么Redis需要客户端在执行任何操作之前，先执行AUTH 命令
• rename-command  src-command  dst-command:对危险的命令进行重新命名，这样可以防止误操作。比如：

rename-command CONFIGb840fc02d524045429941cc15f59e41cb7be6c52

当然也可以取消一个操作，简单的把命令设置为空串

限制

• maxclients：设置同时连接的客户端最大数目；默认为10000，但是如果Redis进程不能创建这么多的文件数目的时候，Redis将把maxclients设置为当前进程的file limits - 32（因为Redis自身也需要创建一些文件）
• maxmemory：Redis确保不会使用超过配置的最大内存的大小；如果Redis使用的内存达到了这个大小，那么它会尝试根据配置的eviction策略，对key进行删除。如果Redis根据eviction策略无法删除key，或者配置的eviction策略为noeviction，那么Redis会对需要申请内存空间的命令返回错误，比如：SET，LPUSH等等，但是只读命令会继续返回结果。 这个选项对于将Redis作为LRU 缓存非常有用，或者设置一个实例的绝对内存限制。

注意：如果有salve连接到配置了maxmemory的master上面，每个slave的输出缓存大小会占用系统已使用的内存空间，因此当发生网络或重新同步的时候，而此时已使用空间加上redis占用的内存大于系统的内存，这会导致需要从现有key中删除一些key，而这些删除语句又会占用slave的同步缓存，导致空间得不到释放，又继续进行key的删除，直到所有key都被删除了。一般来说，如果master有slave连接上来，设置的maxmemory应该比系统内存要小一些，以给slave的同步预留空间（如果配置的删除策略为noeviction，则不需要这么做）

• maxmemory-policy：这个用来配置当redis达到maxmemory的时候，如何选择key删除以释放空间。它可以有5个不同的选择：
  • volatile-lru:从设置了过期时间的数据集中，选择最近最久未使用的数据释放
  • allkeys-lru：从数据集中(包括设置过期时间以及未设置过期时间的数据集中)，选择最近最久未使用的数据释放
  • volatile-random：从设置了过期时间的数据集中，随机删除一个key
  • allkeys-random：从数据集中(包括设置过期时间以及未设置过期时间的数据集中)，随机删除一个key
  • volatile-ttl：删除最快就要过期（ttl最小）的key
  • noeviction：不删除key，对于写入操作返回一个错误

注意：对于上面的任何策略，只要redis根据策略无法删除任何key的时候，它对于write操作就会返回一个错误，比如: lpush, set, setnx等等

• maxmemory-samples：LRU和最小TTL的算法都是近似算法，而不是精确算法（为了节省内存），我们可以通过这个参数来调节算法的速度或准确度。默认情况下，检查5个key，然后从中选择一个最近最少使用的key；我们可以改变样本的大小，10个结果很精确，但是速度有影响；5个速度和结果都可以；3个很快，但是结果不太精确。

Append Only Mode

• apendonly：默认情况，Redis异步的将数据集写入磁盘。这种模式对于很多应用是足够了的；但是存在一个问题是，redis进程异常或机器停电会导致几分钟的写丢失（具体需要根据配置来评估）。AOF是另外一种可选的持久化模式，它提供了更好的持久性。比如：使用默认的data fsync策略，在断电的时候，Redis只会丢失1秒内的写入操作；在Redis进程出现问题的时候（操作系统是OK的），只会丢失一个写操作。我们可以同时开启AOF和RDB持久化，但是在Redis启动过程中，如果发现有AOF文件，则会加载AOF文件，因为AOF提供了更好的持久性。默认情况下AOF是关闭的。
• appendfillename:AOF文件的名称。
• appendfsync：fsync系统调用告诉操作系统真正的将数据写入到磁盘当中，而不是等待输出缓冲中积累更多的数据。一些操作会立即将数据刷入磁盘，而有些操作系统则是尽快刷入（as soon as possible）。Redis支持3种不同的刷入AOF的模式，1）no：不执行fsync，操作系统决定什么时候将缓存刷入到磁盘，比较快 2）always：每次写完之后都将aop文件写入到磁盘，慢，但是安全 3）everysec：每秒中执行一次fsync，效果中等。默认就是everysec
• no-appendfsync-on-rewrite：由于后台AOF或RDB日志写入进程会对磁盘做非常多的I/O操作，在一些Linux配置当中，如果上面配置的策略为everysec或always，Redis可能会在fsync系统调用上阻塞比较长的时间；但是当前还没有解决这个问题的办法，因为即使在一个不同的线程中执行fsync，也会阻塞同步的write系统调用。

为了减轻这个问题，可以使用下面的选项，以便在BGSAVE或BGREWRITEAOF的时候，不在主进程当中调用fsync函数。这就意味着当子进程正在进行saving的时候，Redis的持久化和配置appendfsyncnone一样的；也就是在默认的Linux的配置中，至多会丢失30秒的数据。如果我们对延迟有比较高的要求，可以将这个选项设置为yes

• auto-aof-rewrite-percentage 和 auto-aof-rewrite-min-size：自动触发AOF的rewrite；当AOF日志大小增长率超过auto-aof-rewrite-percentage的时候，Redis能够自动调用BGREWRITEAOF（目的是减小AOF文件的大小）来rewrite日志文件。它是这么工作的：Redis知道上次rewrite 的时候，日志文件的大小（如果重启后还没有rewrite过，则为初始大小）；Redis会使用CurrentSize和上次的日志大小进行比较，如果CurrentSize超过上次日志文件大小的auto-aof-rewrite-percentage的时候（默认为100，也就是CurrentSize是上次日志文件大小的2倍），就会触发BGREWRITEAOF操作；为了避免在AOF比较小的时候就启动了AOF重写操作，还是设置最小多大的时候才需要启动重写。
• aof-load-truncated：当Redis启动并将AOF数据加载到内存的时候，Redis可能会发现日志文件可能被truncated，数据不完整了。这种情况可能会发生在Redis 进程crash了，特别是当文件系统是ext4的时候，但是mout的时候没有设置data=ordered选项（但是这种情况不会发生在Redis crash了，操作系统却正常运行）。在这种情况发生的时候，Redis可以选择抛出错误后退出或尽量多的加载数据到内存中，并继续运行（默认就是这种方式），这个选项就是用来控制这个行为的。如果aof-load-truncated设置为yes，一个truncated文件被加载，并会在日志中写入告警日志，通知用户发生了这种情况；如果设置为no，那么redis会拒绝启动，用户就需要使用redis-aof-check对文件进行检测后，然后进行启动。注意：如果Redis发现AOF文件在文件的中间发生了破坏，Redis仍然会报错退出；这个选项只有当Redis想从AOF文件中读取更多的数据，但是没法读取足够多的字节。

LUA脚本

• lua-time-limit：设置Lua脚本执行的最大时长（单位：毫秒），如果Lua脚本执行的时间达到了最大时长，Redis会记录一个日志：说有一个脚本执行时间达到了最大时长，然后会开始向客户端（其它请求）返回错误。当Lua脚本执行时间超过最大长度的时候， 只有命令SCRIPT KILL 和SHUTDOWN NOSAVE可以使用，第一个命令用于杀死一个当前没有调用write命令的脚本；第2个命令是当长时间执行的脚本正在执行write命令的时候，杀死脚本，停止服务器的唯一途径（用户不想等太长的时间）；如果设置为0或负数，那么执行时间是无限制的。

Redis集群

• cluster-enabled：普通的Redis实例不能成为Cluster的一部分；只有作为cluster 启动的节点才能加入集群。为了做到这一点，这个选项需要设置为yes。
• cluster-config-file：每一个cluster node都有一个cluster配置文件，这个文件不是用来随手编辑的，它是Redis Cluster节点来自动创建和更新的，每一个cluster node都需要一个不同的集群配置文件；一定要确保运行在同一台服务器上的服务器节点使用的配置文件不一样。
• cluster-node-timeout：就是一个节点不可达，从而进入failure状态的时间（单位：毫秒）
• cluster-slave-validity-factor：当master挂掉了，它的slave会查看它的数据是否很旧，如果很久就不会启动切换。这个没有一个好的办法，让slave确切知道它的“data age”，所以下面两个检查会执行：1）如果这里有多个slave能够进行切换，那么它们之间会进行消息交互，以便发现那个slave拥有更多的有效数据（也就是：replication offset）。slave会根据offset得到它们的等级，然后根据等级来得到启动failover的延迟时间（延迟时间和等级城正比） 2）每一个slave都会计算和master交互的最后时间，这个时间可能是：last ping或最后获取的command的时间（如果master还是connected的）或自从mastr disconnected后经过的时长。如果这个时间太长了，那么slave不会参与failover（切换）的操作。 其中第2点是用户可以进行调优的，特别是slave不参与切换，如果自从上次和master交互以来经过的时间大于：(node-timeout * slave-validity-factor) + repl-ping-slave-period（每个变量的含义见上面的说明），更大的slave-validity-factor会使得master选择了一个数据比较旧的slave进行了切换，太小的slave-validity-factor可能会使得master无法找到一个slave做切换。为了最大的可靠性，应该将slave-validity-factor设置为0，这就意味着slave一定会尝试进行切换，而不管它们同master交互的最后时间（但是上面提到的第1点还是会遵守的）。0是唯一 一个能确保总是会发生切换的值。
• cluster-migiration-barrier：集群中的slave可以迁移转变为orphaned master（就是那些没有任何slave的master），这么做可以提升集群的容错能力。因为一旦出现错误，orphaned master不能进行fail over。slave转变为orphaned master是有条件的，它的old master必须有一定数目的正常工作的slave。这个数目就称为：“migration barrier”。这个配置的默认值为1，意味着old master的slave至少为1个。
• cluster-require-full-coverage：在默认情况下，如果集群节点发现有的slot没有被任何节点覆盖，它就会停止接受任何请求。如果集群中有节点挂了，这样有部分slot就无法覆盖了，这个时候，整个集群都会停止对外提供服务，直到对应slot都被覆盖了（通过slot迁移等）。不过，有的时候，我们希望那些正常覆盖的slot还能对外提供服务，我们可以设置这个参数为no。

慢查询日志

• slow-log-slower-than：Redis 可以将执行时间超过一定值的操作记录到慢查询日志当中。这个执行时间，不包括I/O操作，比如：和client的交互，发送响应给客户端等等。这个时间是执行命令消耗的时间，这段时间内Redis线程被阻塞，不能处理其它请求。slow-log-slower-than参数用于配置命令执行时间超过了多少（微秒为单位）才会被记录到慢查询日志当中。如果配置为0，那么所有命令都会记录到慢查询日志当中。
• slow-log-maxlen：配置慢查询日志的长度，默认为128. 如果有新的命令需要记录，Redis会从记录命令的队列中将最老的命令移除。