作者：黄湘龙

花了三天时间，把REDIS 3.0.6英文版大部分都翻译过来了，还有部分没翻译完，等我慢慢更新本文章。

原创首发，欢迎同学们纠正错误，也欢迎转载，但请标明出处。

 # Redis在没有配置文件的情况下也能启动，但一般不建议无配置启动

# 带配置启动Redis命令如下：

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

################################ 普通配置  #####################################

# Redis默认不以守护进程运行，如何配置为“yes”，那么以守护进程运行

# 如果以守护进程运行，Redis会生成一个进程文件在/var/run/redis.pid

daemonize no

# 如果以守护进程运行，守护进程的进程文件配置

pidfile /var/run/redis.pid

# 监听端口

port 6379

# TCP listen() backlog.

# 高并发环境下，为了避免出现TCP-IP的accept-quene满了导致的服务器端丢弃客户端发上来的SYN包的而引起的慢连接问题，

# 需要把本配置和linux内核的somaxconn配置都设置到一个合理值。

tcp-backlog 511

# 很多地方翻译如下：

# 指定redis只接收来自于该IP地址的请求，如果不进行设置，那么将处理所有请求，在生产环境中最好设置该项

# 但是，实际上，应该bind的是redis所在服务器网卡的ip。也就是说，如果你的redis服务器有两张网卡，一张是ip-1,另一张是ip-2，如果你bind ip-1.那么只有请求ip-1的请求会被受理。

# 这块其实和mysql的bind的意义是一样的

# Examples:

#

# bind 192.168.1.100 10.0.0.1

# bind 127.0.0.1

# unix上的配置，指定unix的socket文件路劲。Redis没有预设这个值，如果需要在unix上运行redis，需要设置这两个值。

# unixsocket /tmp/redis.sock

# unixsocketperm 700

# 关闭N秒内无请求的客户端连接，如果设置为0，不启动该功能

timeout 0

# TCP 的keepalive间隔时间

# 如果设置为0，在客户端没有请求上来时，使用系统的 SO_KEEPALIVE 值来发送TCP ACKs 给客户端。

# 发送这个请求给客户端主要有两个原因：

# 1.确认此客户端是否还活着

# 2.更新客户端和Redis中间的网络设备上的连接的活跃时间。一些中间网络设备会定期删除一些不活跃的连接。

#

# 这个值建议设置为60（秒）

tcp-keepalive 0

# 日志级别：

# debug (产生大量日志，给开发和测试时用)

# verbose (一些正常的日志，比debug少很多)

# notice (适度的日志，一般记录一些产品问题)

# warning (非常重要和严重问题的日志)

loglevel notice

# 日志文件路径

# 如果设置为空字符串，日志从控制台输出

# 如果以守护进程运行，并且本配置为空字符串，那么所有日志输出到/dev/null

logfile ""

# 是否将redis日志写入系统日志

# syslog-enabled no

# 系统日志中Redis日志标识

# syslog-ident redis

# 指定syslog 设备（facility), 必须是USER或者LOCAL0到LOCAL7

# syslog-facility local0

# 数据库个数，默认使用的数据库是0，可以使用select语句切换数据库

databases 16

################################ 内存快照  ################################

# Redis自动快照保存到磁盘或者调用bgsave，是后台进程完成的，其他客户端仍然和可以读写redis服务器，后台保存快照到磁盘会占用大量内存。

# 调用save保存内存中的数据到磁盘，将阻塞客户端请求，直到保存完毕。

# 调用shutdown命令，Redis服务器会先调用save，所有数据持久化到磁盘之后才会真正退出。

# 内存数据持久化配置

# save <时间> <变更次数>

# 两个条件同时满足，发生一次落地本地磁盘动作，下面三个配置是或的关系

# 如果不想落地内存中的数据，直接注释掉下面三个配置即可

# 如果配置成save ""，之前落地的数据都可能被删除

save 900 1

save 300 10

save 60 10000

# 如果最后一次落地磁盘操作失败，停止接受客户端的写请求，避免出现落地磁盘的数据和内存中的数据不一致

# 一旦持久化动作恢复工作，Redis可以继续接受客户端的写操作

# 如果你有良好的监控系统能监控redis和其持久化的操作，那么你可以屏蔽这个功能。

# 这个功能的副作用是可能会因为持久化的问题影响生产环境。

stop-writes-on-bgsave-error yes

# 指定存储至本地数据库时是否压缩数据，默认为yes，Redis采用LZF压缩，如果为了节省CPU时间，可以关闭该选项，但会导致数据库文件变的巨大

rdbcompression yes

# 保存rdb和加载rdb文件的时候CRC64检验，可以防止错误，但是要付出约10%的性能，可以关闭他，提高性能。

rdbchecksum yes

# 持久化文件名

dbfilename dump.rdb

# 设置工作目录, rdb文件会写到该目录, append only file也会存储在该目录下.

dir ./

################################# 数据同步 #################################

# 主从同步。用slaveof的配置来设置本机的Redis作为从实例，实时从主实例读取数据，成为起镜像。主要是高可用场景需要本功能。

# 1). 同一个Master可以同步多个Slaves。

# 2). Slave同样可以接受其它Slaves的连接和同步请求，这样可以有效的分载Master的同步压力。因此我们可以将Redis的Replication架构视为图结构

# 3). Master Server是以非阻塞的方式为Slaves提供服务。所以在Master-Slave同步期间，客户端仍然可以提交查询或修改请求。

# 4). Slave Server同样是以非阻塞的方式完成数据同步。在同步期间，如果有客户端提交查询请求，Redis则返回同步之前的数据。

# 5). 为了分载Master的读操作压力，Slave服务器可以为客户端提供只读操作的服务，写服务仍然必须由Master来完成。即便如此，系统的伸缩性还是得到了很大的提高。

# 6). Master可以将数据保存操作交给Slaves完成，从而避免了在Master中要有独立的进程来完成此操作。

# 7). Redis的数据同步是异步进行的，你可以配置主实例在和从实例断掉连接的时候停止接受客户端发过来的写请求。

# 8). 同步是自动完成的，不需要人工干预。主从之间的网络短暂的断开后，从再次连上主之后，会自动从上次断开的时候同步数据。

#

# slaveof <masterip> <masterport>

# 同步密码

# masterauth <master-password>

# 本配置决定slave实例在和master断掉连接或者同步过程中是否继续相应客户端的请求，默认是响应。

# 如果设置成no，那么slave实例在不同步状态只会正确响应INFO and SLAVEOF两个命令，对于其他命令一律返回"SYNC with master in progress"

slave-serve-stale-data yes

# 从实例是否只读

# 对从实例的写操作是非常不靠谱的行为，因为这些写操作可能下一秒就被同步过来的主实例的写操作给覆盖了，这个配置默认为yes

# 但对从实例设置为只读之后，也不以为着你可以把从实例放开给互联网上的不信任客户端，因为一些管理命令仍然可以在上面执行

slave-read-only yes

# 同步策略：先写文件，再通过文件同步；直接写socket同步.

#

# -------------------------------------------------------

# 注意：直接通过socket进行无文件全量同步，目前还是实验阶段

# -------------------------------------------------------

#

# 当新的从实例连入主实例，或者从实例断开连接时间比较长，再连入主实例的时候，为了保证数据一致，主实例会将

# 全量数据同步给从实例。称之为全量同步。这个同步有两种方式：

#

# 1).Disk-backed:主实例创建一个任务去写DB文件到磁盘，文件创建完毕后，主实例增量方式读取文件中的数据传输给从实例。

#

# 2).Diskless:主实例创建一个任务把全量数据直接写入从实例的socket连接上，数据不落地。

# 

# 使用Disk-backed模式同步数据有个好处就是，这个文件一旦生成，多个slave实例过来全量同步，都可以重用这一个文件；

# 使用Diskless模式同步全量数据，一旦一个全量同步行为开始了，其他slave实例的同步请求过来时，只能先排到队列里面去等下一次全量同步开始。

#

# 使用diskless的数据同步时，master实例会等一会（时间可配），看看这段时间内是否有多个slave实例同时请求全量同步，好凑齐了一块给所有实例传输数据。

#

# 在网络带宽充裕的情况下，diskless的同步避免了磁盘io，性能会好很多。

repl-diskless-sync no

# 就是上面说的主实例在开始给slave做全量同步前等待的时间

repl-diskless-sync-delay 5

# 从实例会定期去ping主实例，下面是时间间隔，不设置的话，默认是10秒

# repl-ping-slave-period 10

# 这个选项被以下三个逻辑共用:

#

# 1) 主从间数据同步的超时时间.

# 2) 从实例看到主实例的数据同步或者ping超时时间.

# 3) 主实例发送REPLCONF ACK pings时，从实例超时时间.

#

# 这个配置务必比repl-ping-slave-period这个配置要大，不然在业务量少的时候，每次主实例都会检测到从实例超时

# repl-timeout 60

# 在从实例发送SYNC后，禁用TCP_NODELAY

# 

# 如果禁用，Redis会发送更少的TCP包，占用更少的带宽，但会造成从实例上稍微的数据延迟，一般情况，按照linux内核默认配置，这个时间会在40ms

# 如果不禁用，延时会减少，但会使用多一点带宽。

#

# 一般情况下，我们为了主从的一致性，我们会设置成不禁用。但是在流量非常大的情况，或者带宽不够的情况，设置成经用说不定能达到一个理想的效果

repl-disable-tcp-nodelay no

# 同步数据缓存大小

# 有时候从实例会因为网络或其他原因断开与主实例的连接，短时间内，从实例又连上主。

# 如果从断开时间点到连上的时间点之间的所有变化数据都在这个缓存中，那么就不需要全量同步，主实例只需要将这些数据同步到从即可。

# 如果断开的时间太长，这块缓存cover不住所有的变动数据，那么就会发生一次主从之间的全量同步。

# 缓存越大，能容忍的断开时间越长。

# 一旦第一个从实例连上了主实例，主实例就会分配这块缓存并维护之。

# repl-backlog-size 1mb

# 主实例会在没有任何从实例连接的情况下清除同步数据缓存。

# 最后一个从实例断开连接repl-backlog-ttl秒后，主实例开始清理同步缓存数据。

# repl-backlog-ttl设置为零表示永不清理同步缓存

#

# repl-backlog-ttl 3600

# 本配置是一个可以用INFO命令从Redis内查出来的值，语义是在主实例挂了的情况下，根据从实例的优先级推举那个从实例作为主。

# Redis提供一个叫Redis Sentinel的监控程序做主从监控和主从切换工作。他主要有以下功能：

# 监控（Monitoring）： Redis Sentinel实时监控主服务器和从服务器运行状态。

#

# 提醒（Notification）：当被监控的某个 Redis 服务器出现问题时， Redis Sentinel 可以向系统管理员发送通知， 也可以通过 API 向其他程序发送通知。

#

# 自动故障转移（Automatic failover）： 当一个主服务器不能正常工作时，Redis Sentinel 可以将一个从服务器升级为主服务器， 

# 并对其他从服务器进行配置，让它们使用新的主服务器。当应用程序连接到 Redis 服务器时， Redis Sentinel会告之新的主服务器地址和端口。

# Redis Sentinel 是一个分布式系统， 你可以在架构中运行多个 Sentinel 进程，这些进程通过相互通讯来判断一个主服务器是否断线，以及是否应该执行故障转移。

# 在配置Redis Sentinel时，至少需要有1个Master和1个Slave。当Master失效后,Redis Sentinel会报出失效警告，并通过自动故障转移将Slave提升为Master，并提供读写服务;当失效的Master恢复后，Redis 

# Sentinel会自动识别，将Master自动转换为Slave并完成数据同步。

# 

# 下面问题来了，他这个切换过程怎么告知所有应用程序呢？他可以通过API向其他应用程序发通知，但我个人认为这个机制没有KeepAliveD切换网络虚拟IP可靠。

slave-priority 100

# Redis提供一个功能，用来限制主实例接受写请求：如果主实例没有min-slaves-to-write个从实例有效连接，那么主实例拒绝所有客户端发起的写请求。

# 有效连接是指从实例最后一次PING主实例的时间到检查时间的间隔小于min-slaves-max-lag秒。从实例一般每秒发送一次PING。

#

# 本配置主要为了避免从实例失去连接后大量丢失数据，导致必须全量同步的情况发生。

#

# 比如要求主实例必须连接三台从实例，并且，所有从实例的延迟时间在10秒以内可以这么设置：

#

# min-slaves-to-write 3

# min-slaves-max-lag 10

################################## 安全 ###################################

# Redis的密码，如果设置，那么在运行任何命令前，必须先输入密码。

# 如果你的内网环境有不信任的主机在运行，那么你需要设置这个密码。如果你的内网是安全的，那么不建议设置本密码。

#

# Redis允许客户端每秒尝试15万次密码匹配，如果你密码不够强，很容易被破解

#

# requirepass foobared

# 修改命令名

# Redis允许你修改一些危险的命令的指令名。比如你可以把CONFIG修改成一个很难猜测的名字，只有内部人员知道这个名字，以防外人使用次命令：

# rename-command CONFIG b840fc02d524045429941cc15f59e41cb7be6c52

#

# 你也可以完全禁用一些命令，把一个命令的指令名变为空字符串即可：

# rename-command CONFIG ""

#

# 请注意这些对命令名的修改也会同步到AOF文件中，或者传输给从实例中，引起其他问题。

################################### 内存限制 ####################################

# 客户端连接总数限制，默认值为10000

# 然而如果Redis服务器不能配置处理文件的句柄数来满足指定的值，那么最大的客户端连接数就被设置成当前文件限制数减32（因

# 为Redis服务器保留了一些文件描述符作为内部使用）

#

# maxclients 10000

# 内存限制

# 如果Redis使用的内存达到了内存限制，那么Redis会就会动用淘汰策略来处理expaire字典中的键，这种场景适合LRU模式

# 如果Redis不能删除数据，那么Redis停止接受写请求，开启只读模式

#

# 关于maxmemory的设置，如果redis的应用场景是作为db使用，那不要设置这个选项，因为db是不能容忍丢失数据的。

# 如果作为cache使用，则可以启用这个选项（其实既然有淘汰策略，那就是cache了）

#

# 在集群环境下（尤其是有多个slavers的情形），maxmeomory的值并不是实际redis使用的内存，这个选项值并没有包括slaver的output buffer。

# redis早期版本出过一个bug，在多个slaver的情形下，设置了maxmemory值，同时设定了淘汰策略，会造成master上的数据被渐渐擦除。

# 需要注意留点内存给同步缓存

# maxmemory <bytes>

# 内存淘汰策略，当内存使用达到限制时，Redis根据此策略删除数据

# 

# volatile-lru -> 根据LRU算法删除过期Key

# allkeys-lru -> 根据LRU算法删除所有Key

# volatile-random -> 随机算出过期数据

# allkeys-random -> 随机删除任意数据

# volatile-ttl -> 根据最近过期时间来删除（辅以TTL）

# noeviction -> 不删除任何数据，拒绝客户端写请求

#

# 注意：如果Reids在当前策略下找不到可以删除的key，那么Redis会拒绝所有客户端的写请求。

# 写请求的命令包括：set setnx setex append

#       incr decr rpush lpush rpushx lpushx linsert lset rpoplpush sadd

#       sinter sinterstore sunion sunionstore sdiff sdiffstore zadd zincrby

#       zunionstore zinterstore hset hsetnx hmset hincrby incrby decrby

#       getset mset msetnx exec sort

#

# 本配置项默认值为 

#

# maxmemory-policy noeviction

# LRU和最小TTL算法不是精确的算法，而是取样类模糊算法，主要是为了节省内存。你可以配置取样数量来控制精确度和速度。

# 例如，Redis默认取5个样本，然后选出最旧的那个。

#

# maxmemory-samples 5

############################## APPEND ONLY MODE ###############################

# 默认情况下Redis会异步落地内存中的数据到磁盘，这种模式对于很多场景是够用的。

# 但这种模式有个缺点就是对于突发情况，比如突然停电，落地的文件数据会丢失几分钟数据，具体的丢失时间视配置情况而定。

#

# AOF是一种可选的持久化模式，能很好地解决上面说的数据丢失的问题。默认配置下，AOF模式在意外故障发生时最多丢失一秒钟的数据。

# AOF和RDB两种持久化模式能同时启动，不会互相影响。如果AOF模式生效了，那么Redis启动的时候会首先载入AOF文件来保证数据的可靠性。

#

# AOF文件是可识别的纯文本，它的内容就是一个个的Redis标准命令,

# AOF日志也不是完全按客户端的请求来生成日志的，比如命令 INCRBYFLOAT 在记AOF日志时就被记成一条SET记录，

# 因为浮点数操作可能在不同的系统上会不同，所以为了避免同一份日志在不同的系统上生成不同的数据集，所以这里只将操作后的结果通过SET来记录。

# 每一条写命令都生成一条日志,AOF文件会很大。

#

# 请查看 http://redis.io/topics/persistence 来获取更多信息.

appendonly no

# AOF模式文件名，默认为 "appendonly.aof"

appendfilename "appendonly.aof"

# 函数fsync()的调用告诉操作系统将同步缓存中的数据真实落地到磁盘，一些操作系统会立即落地，一些会尽量快地落地。

# Redis在落地缓存数据的时候，有三种模式

#

# appendfsync always : 每次有客户端发送写操作，都需要落地到磁盘，性能最差，但最安全。

# appendfsync everysec : 顾名思义，每秒写一次，均衡模式。

# appendfsync no : 操作系统在需要的时候才落地数据到磁盘，性能最好，但可能有数据丢失风险。对大多数Linux操作系统，是每30秒进行一次fsync，将缓冲区中的数据写到磁盘上。

#

# Redis实用的默认模式是everysec，这是一种均衡的模式。

#

# 请查看下面的文章来获取更多的细节

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

appendfsync everysec

# 在AOF同步文件同步模式设置为always或者everysec的时候，会有一个后台线程去做这个事，同时产生大量磁盘IO。

# 这些IO操作经常会阻塞后台RDB落地线程和AOF日志重写线程，甚至导致整个Redis被阻塞，目前没有很好的解决方案。

# 

# 为了缓解这个问题，Redis增加了本配置，fsync()在BGSAVE或者BGREWRITEAOF时被阻止

# 这就意味这在BGSAVE或者BGREWRITEAOF时，Redis不会去写AOF，可能会因此丢掉30秒以内的数据。

# 

# 如果你因为AOF写入产生延迟问题，可以将本配置设置为yes。本配置设置为no为最安全，最不可能丢失数据的方式。

no-appendfsync-on-rewrite no

# AOF重写

# 在AOF文件增长到足够大超过配置的百分比的时候，Redis提供AOF重写功能

#

# Redis的实现方式是这样的：

# Redis会在启动的时候或者重写之后记住此时AOF文件的尺寸，然后定时对比当前AOF文件尺寸和记住的尺寸，如果尺寸达到设定的百分比，触发AOF重写

# 将auto-aof-rewrite-percentage设置为0，屏蔽自动重写能力

# 

# AOF重写是重新生成一份AOF文件，新的AOF文件中一条记录的操作只会有一次，而不像一份老文件那样，可能记录了对同一个值的多次操作。

# 其生成过程和RDB类似，也是fork一个进程，直接遍历数据，写入新的AOF临时文件。

# 在写入新文件的过程中，所有的写操作日志还是会写到原来老的 AOF文件中，同时还会记录在内存缓冲区中。

# 当重完操作完成后，会将所有缓冲区中的日志一次性写入到临时文件中。

# 然后调用原子性的rename命令用新的 AOF文件取代老的AOF文件。

#

# 重写后，AOF文件变成一个非常小的全量文件

# 命令：BGREWRITEAOF， 我们应该经常调用这个命令来来重写

# 

# 为了避免AOF非常小也发生重写这样的操作，我们增加auto-aof-rewrite-min-size配置，在AOF文件尺寸比这个配置小的时候，不发生重写动作。

auto-aof-rewrite-percentage 100

auto-aof-rewrite-min-size 64mb

# 有时候AOF因为突然断电等（mount ext4文件系统时没有加上data=ordered选项）特殊原因不完整

# 本配置设置为yes时自动加载，忽略错误，然后自动发布一个log给客户端（默认）

# 本设置设置为no时需要手动使用redis-check-aof工具修改AOF文件后才能启动Redis

aof-load-truncated yes

################################ LUA SCRIPTING  ###############################

# Lua script脚本最长运行时间限制，单位是毫秒

#

# 如果脚本出现这种情况，Redis会记录一条日志然后给执行者返回一条错误

# 当一条脚本执行时间超过最大限制，只有SCRIPT KILL 和 SHUTDOWN NOSAVE两条命令能关闭只

# SCRIPT KILL用来关闭没有写操作的脚本，SHUTDOWN NOSAVE可以关闭有写命令的脚本

# 设置成0或者负数，脚本运行时间就无限制了

lua-time-limit 5000

################################ REDIS 集群  ###############################

#

# ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

# WARNING EXPERIMENTAL: 开发者认为Redis 集群代码是稳定的的代码，但需要一定数量的用户

# 在生产环境中验证其成熟程度。

# ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

# 普通的Redis实例不能加入Redis集群，只有启动时，本参数设置为yes的Redis实例才能成为集群的一部分

# cluster-enabled yes

# Redis集群中的每个借点都需要一个单独的配置文件，这个配置文件不建议手动编辑，

# 它是由Redis节点来维护的。注意这个配置文件不能被集群中多个节点复用。

# cluster-config-file nodes-6379.conf

# 集群节点的超时时间

# 超过cluster-node-timeout毫秒连不上的节点会被认为是失效节点

# 一些内部时间限制都是节点超时时间的倍数

# cluster-node-timeout 15000

# A slave of a failing master will avoid to start a failover if its data

# looks too old.

# 集群的策略：Slave发现自己的数据太老了，那么它就不再去取代主。

#

# 没有一个好的办法让slaver去发现自己的数据太老了，目前Redis执行的检查主要有一下两点：

# 1)如果有多个可用的从（可以随时failover主的从），这些从会进行通信交换信息，

# 来确认数据最新的从的数据按照从新到旧的排行，一旦需要failover主的时候，排行中最靠前的从冲上去。

# 2)每个从都会计算自己和主在交互过程中失联间隔时间，这个时间是这样计算的：

# 如果是正常的同步联机状态，那么这个间隔时间是从最后一次和主的ping或者收到主的同步命令开始到目前的时间；

# 如果从和主断开连接，那么这个时间从断开连接的时间开始算。

# 如果这个间隔时间太长，那么这个从就不会再尝试去failure主。

#

# The point "2" can be tuned by user. Specifically a slave will not perform

# the failover if, since the last interaction with the master, the time

# elapsed is greater than:

#

#   (node-timeout * slave-validity-factor) + repl-ping-slave-period

#

# So for example if node-timeout is 30 seconds, and the slave-validity-factor

# is 10, and assuming a default repl-ping-slave-period of 10 seconds, the

# slave will not try to failover if it was not able to talk with the master

# for longer than 310 seconds.

#

# A large slave-validity-factor may allow slaves with too old data to failover

# a master, while a too small value may prevent the cluster from being able to

# elect a slave at all.

#

# For maximum availability, it is possible to set the slave-validity-factor

# to a value of 0, which means, that slaves will always try to failover the

# master regardless of the last time they interacted with the master.

# (However they'll always try to apply a delay proportional to their

# offset rank).

#

# Zero is the only value able to guarantee that when all the partitions heal

# the cluster will always be able to continue.

#

# cluster-slave-validity-factor 10

# Cluster slaves are able to migrate to orphaned masters, that are masters

# that are left without working slaves. This improves the cluster ability

# to resist to failures as otherwise an orphaned master can't be failed over

# in case of failure if it has no working slaves.

#

# Slaves migrate to orphaned masters only if there are still at least a

# given number of other working slaves for their old master. This number

# is the "migration barrier". A migration barrier of 1 means that a slave

# will migrate only if there is at least 1 other working slave for its master

# and so forth. It usually reflects the number of slaves you want for every

# master in your cluster.

#

# Default is 1 (slaves migrate only if their masters remain with at least

# one slave). To disable migration just set it to a very large value.

# A value of 0 can be set but is useful only for debugging and dangerous

# in production.

#

# cluster-migration-barrier 1

# By default Redis Cluster nodes stop accepting queries if they detect there

# is at least an hash slot uncovered (no available node is serving it).

# This way if the cluster is partially down (for example a range of hash slots

# are no longer covered) all the cluster becomes, eventually, unavailable.

# It automatically returns available as soon as all the slots are covered again.

#

# However sometimes you want the subset of the cluster which is working,

# to continue to accept queries for the part of the key space that is still

# covered. In order to do so, just set the cluster-require-full-coverage

# option to no.

#

# cluster-require-full-coverage yes

# In order to setup your cluster make sure to read the documentation

# available at http://redis.io web site.

################################## SLOW LOG ###################################

# The Redis Slow Log is a system to log queries that exceeded a specified

# execution time. The execution time does not include the I/O operations

# like talking with the client, sending the reply and so forth,

# but just the time needed to actually execute the command (this is the only

# stage of command execution where the thread is blocked and can not serve

# other requests in the meantime).

#

# You can configure the slow log with two parameters: one tells Redis

# what is the execution time, in microseconds, to exceed in order for the

# command to get logged, and the other parameter is the length of the

# slow log. When a new command is logged the oldest one is removed from the

# queue of logged commands.

# The following time is expressed in microseconds, so 1000000 is equivalent

# to one second. Note that a negative number disables the slow log, while

# a value of zero forces the logging of every command.

slowlog-log-slower-than 10000

# There is no limit to this length. Just be aware that it will consume memory.

# You can reclaim memory used by the slow log with SLOWLOG RESET.

slowlog-max-len 128

################################ LATENCY MONITOR ##############################

# The Redis latency monitoring subsystem samples different operations

# at runtime in order to collect data related to possible sources of

# latency of a Redis instance.

#

# Via the LATENCY command this information is available to the user that can

# print graphs and obtain reports.

#

# The system only logs operations that were performed in a time equal or

# greater than the amount of milliseconds specified via the

# latency-monitor-threshold configuration directive. When its value is set

# to zero, the latency monitor is turned off.

#

# By default latency monitoring is disabled since it is mostly not needed

# if you don't have latency issues, and collecting data has a performance

# impact, that while very small, can be measured under big load. Latency

# monitoring can easily be enabled at runtime using the command

# "CONFIG SET latency-monitor-threshold <milliseconds>" if needed.

latency-monitor-threshold 0

############################# EVENT NOTIFICATION ##############################

# Redis can notify Pub/Sub clients about events happening in the key space.

# This feature is documented at http://redis.io/topics/notifications

#

# For instance if keyspace events notification is enabled, and a client

# performs a DEL operation on key "foo" stored in the Database 0, two

# messages will be published via Pub/Sub:

#

# PUBLISH __keyspace@0__:foo del

# PUBLISH __keyevent@0__:del foo

#

# It is possible to select the events that Redis will notify among a set

# of classes. Every class is identified by a single character:

#

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

#  E     Keyevent events, published with __keyevent@<db>__ 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 the events.

#

#  The "notify-keyspace-events" takes as argument a string that is composed

#  of zero or multiple characters. The empty string means that notifications

#  are disabled.

#

#  Example: to enable list and generic events, from the point of view of the

#           event name, use:

#

#  notify-keyspace-events Elg

#

#  Example 2: to get the stream of the expired keys subscribing to channel

#             name __keyevent@0__:expired use:

#

#  notify-keyspace-events Ex

#

#  By default all notifications are disabled because most users don't need

#  this feature and the feature has some overhead. Note that if you don't

#  specify at least one of K or E, no events will be delivered.

notify-keyspace-events ""

############################### ADVANCED CONFIG ###############################

# Hashes are encoded using a memory efficient data structure when they have a

# small number of entries, and the biggest entry does not exceed a given

# threshold. These thresholds can be configured using the following directives.

hash-max-ziplist-entries 512

hash-max-ziplist-value 64

# 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-entries 512

list-max-ziplist-value 64

# 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-entries 512

# 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-entries 128

zset-max-ziplist-value 64

# 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-bytes 3000

# 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 if the

# 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 it is

# 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 requirements but

# want to free memory asap when possible.

activerehashing yes

# 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 <class> <hard limit> <soft limit> <soft seconds>

#

# 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-limit normal 0 0 0

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

client-output-buffer-limit pubsub 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 CPU when

# 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.

hz 10

# 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-fsync yes