redis :3.2.6版本
Redis 配置文件 示例
注意 为了 读取 此配置 文件, 开启Redis 服务 时 此文件路径 必须 作为第一个参数:
# ./redis-server /path/to/redis.conf
单位 注意事项; 在表示内存大小时, 可以 使用 常规的格式 如 1k, 5GB, 4M 等这样的 来表示:
# 1k => 1000 bytes
# 1kb => 1024 bytes
# 1m => 1000000 bytes
# 1mb => 1024*1024 bytes
# 1g => 1000000000 bytes
# 1gb => 1024*1024*1024 bytes
所有的单位 都是 大小写不敏感的 。所以 如 1GB 1Gb 1gB 都是 相同含义。
################################## 文件包含 ###################################
在这个位置 包含 一个或多个 另外的配置 文件 : 这样做 很有用! 特别是你 有 一个 对大多数redis服务都适用的标准的模版,
并且 只是有一小部分 配置选项需要自定义设置。 包含的文件 又可以再包含其他文件。所以 这样来使用的情况很多。
注意 “include” 包含的选项 不会被 (由 admin 或 Redis Sentinel 产生的 ) “CONFIG REWRITE” 这样的命令 覆盖。
由于 redis 总是 使用 最后一次处理的那一行 作为 配置指令 的值, 所以你最好 将 这些“include” 放在这个文件的开头,这样就能避免 在 运行的时候 覆盖 此文件中的配置 。
相反的,你想 使用 “include”s 去 覆盖 此文件中 配置选项,你最好在此文件的 末尾 使用 “include”s
# include /path/to/local.conf
# include /path/to/other.conf
################################## 网络 #####################################
默认的, 如果 没有指定 “bind” 配置指令, Redis 就会 监听 来自此服务器上 所有网卡接口 的连接。
可以使用 “bind” 配置指令(后边 跟着 1个或多个ip 地址) 去 监听 一个 或多个 网卡接口
例如:
# bind 192.168.1.100 10.0.0.1
#bind 127.0.0.1 ::1
~~~ 警告! ~~~ 如果 运行着 Redis 的这台计算机 直接 暴露在 internet 网络中, 那么 对所有网卡接口都 bind监听 就是
很危险的! 将 暴露给internet网络中的 每个人。 所以 默认的,不要注释 下面的 bind指令,这样就会 强制 Redis 去
监听IPv4 loolback 接口地址(这位意味着 Reids 将 只能 接受 来自 客户端发到 此(正在运行的redis的)计算机上 绑定了接口的 连接)
# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
bind 127.0.0.1 192.168.8.129
保护模式 是一层安全保护,是为了避免 在internet上保持打开的 Redis实例 被访问 和被利用。
何时 保护模式应该开启 ,条件是什么:
- 服务 没有显式地 用 “bind” 指令 绑定 一些 ip地址。
- 没有配置密码
服务器 仅仅支持 来自 IPv4 和IPv6 loopback 地址 127.0.0.1 和 ::1 和 unix域 套接字 的 客户端的 连接
默认的 保护模式 是 被禁用的。 如果你想让来自其他主机 的客户端 去连接 Redis, 即便是没有配置密码验证,也
没有 显式地 使用 bind 指令 列出一些网卡接口 。
protected-mode yes
在指定的端口 接受连接, 默认是 6379。如果 port指定的 是0, Redis 将不会监听 TCP 套接字
port 6379
# TCP listen() 积压日志(backlog)
#在每秒请求数很高的环境,你需要 高的 backlog, 是为了避免 慢的 客户端连接 问题。
#注意 Linux 内核(kernel) 将 默默的 截断它的值 和 /proc/sys/net/core/somaxconn 的值一样。
所以,确保同时提高 somaxconn 和 和 tcp_max_syn_backlog 的值 以达到 预期的效果。
tcp-backlog 511
# Unix 域套接字(Unix socket)
# 指定 Unix socket 的路径 ,这通常用于去监听新来的连接。 Unix socket 没有默认值, 所以如果没有指定
unix socket ,那么Redis 也不会监听。
# unixsocket /tmp/redis.sock
# unixsocketperm 700
如果 一个客户端是闲置 N秒,就关闭这个连接。0表示禁用此功能,即 服务器不主动断开连接
timeout = 0
# TCP 心跳包(keepalive).
# 如果 非零, 使用 SO_KEEPALIVE 发送 TCP ACKs 给缺乏交流的客户端。 这样做很有用!,基于如下两个原因:
# 1. 检测 死亡对
# 2. 接受 活着的(从中间的网络设备角度来看)连接 ;
# 在Linux , 用秒为单位指定的值, 通常作为 发送ACKs 的间隔时间。 注意, 为了关闭连接需要双倍的时间。
# 在其他的内核系统上, 间隔时间取决于 内核的配置。
# 这个选项 合理的,推荐的值是 300秒, 从Redis 3.2.1 开始就开始使用这个新的值了。
tcp-keepalive 300
################################# 常规(GENERAL) #####################################
# 默认 Redis 不会以守护进程方式来运行。 如果你需要守护进程方式来启动 ,使用 yes 。
# 注意 当守护进程方式的方式运行时, Redis 将会在 /var/run/redis.pid 下创建一个 pid 文件。
daemonize yes
# 如果你从 upstart 或者 systemd 来运行Redis, Redis 可以和 supervison tree 交互。 选项:
# supervised no - 无监督交互
# supervised upstart - 放 Redis 到 SIGSTOP mode 就会 signal upstart
# supervised systemd - 写 READY=1 到 $NOTIFY_SOCKET
# supervised auto - 基于 UPSTART_JOB 或 NOTIFY_SOCKET 环境变量 侦测 upstart 或者method方法。
# 注意: 这些监督方法 仅是 进程只读的信号
# 他们不启用 持续不断的活力 pings 回到 你的 supervisor.
# supervised no
# 如果 指定了 pid 文件, Redis 在startup 时写入, 在退出时 删除 pid 文件
# 当server 非守护进程方式 运行, 且 配置文件也没有指定,则 不会有pid 文件被创建,
# 当server 是守护方式运行, 则即便是 没指定 pid 文件也会被创建,默认是 /var/run/redis.pid
# 创建 一个 pid 文件 是最好的尝试: 如果redis 不能够创建 它,也不会有坏的结果产生,服务还是会 正常的开始运行
pidfile /var/run/redis_6379.pid
# 指定服务的 冗余级别
# 可取的值如下:
# debug (对 开发/测试 有用 的 大量的 信息)
# verbose ( 许多 罕见 的有用信息, 不像 debug 级别 那样杂乱)
# notice ( 适用于 生产环境的, 适量的冗余信息)
# warning ( 只记录 重要的 或 关键的 )
loglevel notice
# 指定日志文件名, 也可以是空字符,这被通常强制 redis 输出日志到标准输出上, 注意如果你在守护方式运行方式下,使用了
# 标准输出,那么日志 将会被 发送到 /dev/null
logfile ""
# 如果要 记录 系统日志,只需要 设置 ‘syslog-enabled’ 为 yes, 你可以根据你的需要 选择性的 改变其他的syslog参数
# syslog-enabled no
# 指定 syslog 身份
# syslog-ident redis
# 指定 syslog 设置 , 必须是 USER 或者 在 LOCAL0-LOCAL7.
# 设置数据库 的数量, 默认的database 是 DB 0, 你可以 使用 select <dbid> where dbid 来为具体的连接选择不同的databse
# dbid 是一个数字 取值 在 0 and ‘databases’-1 之间。
################################ 快照(SNAPSHOTTING) ################################
保存 DB 到 硬盘上:
save <seconds> <changes>
如果 指定了 秒数,和指定了写操作的次数, 那么就会保存到DB;
下面的例子中,相应的行为将被保存。
过了 900s ,且 至少有一个 key发生了改变。
过了 300s, 且 至少有10个key 发生了改变。
过了 60s, 且至少有 10000个 key 发生了改变。
注意: 你可以通过 注释掉所以的”save”行 来 完全禁用 saving
可以通过 save 指令 携带一个 空字符串参数 来移除所有 先前配置的save 点。就想下面这样:
# save “”
save 900 1
save 300 10
save 60 10000
#默认的 如果 RDB 快照 被启用(至少有一个save 点)并且 最近一次 后台save 失败,那么Redis 将停止接受 写操作。
这个使用户意识到数据没有被很好的持久化到硬盘上, 因此出现的情况是: 没有人注意到 一些灾难将要发生。
# 如果后台saving进程 再次开始工作,Redis 会自动再次地允许写。
# 然而 你已经 创建 Redis server 和 持久化 的监控, 你可能想禁用此功能,以让Redis 继续正常的工作,即便是发生了一些问题:比如:
硬盘的,权限的等等。
stop-writes-on-bgsave-error yes
# 当导出 .rdb 数据库时,使用LZF 来对 string 对象进行压缩?
# 默认地, 他将被设置为 “yes”, 因为 这几乎总是最好的选择。
# If you want to save some CPU in the saving child set it to 'no' but
# the dataset will likely be bigger if you have compressible values or keys.
rdbcompression yes
# 由于RDB 5版本 的一个CRC64 校验和 被放置在文件末尾。
# 这样做使这种格式 对 错误更加有抵抗能力,但是 当保存或加载RDB文件时,有性能损耗(大约10%) ,所以为了最高的性能考虑
# 你可以 禁止它。
# 没有 校验和的 RDB 文件 有 zero 校验,这个是为了告诉 加载的代码 跳过 检测。
# rdbchecksum yes
# 将DB 导出 后的文件名
dbfilename dump.rdb
工作目录
DB将被写到此目录,并使用上面 “dbfilename” 配置指令指定的名字。
仅仅是追加的文件 也会被创建到此目录。
注意:你必须在这里指定一个目录,而不是文件。
dir ./
################################# 主从复制(REPLICATION) #################################
主从复制, 使用 slaveof 去 创建 另一个Redis 服务的 一个复制实例。 关于Redis 复制,需要理解下ASAP的一些方面。
1)Redis 复制 是异步进行的。在没有达到最少指定数量的从的连接 时, 你可以配置master 来停止接受写。
2)如果 复制连接 是 在相当短暂的时间内断掉时,Redis 能够执行 一个部分的重新同步(同master 的);你可能想要配置 复制 的backlog size(看这个文件的下个部分);backlog size的大小取决于你的需求
3)复制 时自动的,不需要用户的交互,像网络如果出现问题, 复制会自动 重新尝试连接master 和重新和master同步
# slaveof <masterip> <masterport>
# 当 slave 失去和 master的连接, 或者 复制 仍在处理中, 那么 slave 可以有两种不同的行为:
1) 如果 slave-server-stale-data 被设置为 ‘yes’ (默认地),slave 仍然会响应 客户端的请求, 可能响应的是过期数据,或者数据是空的
2) 如果 slave-serve-stale-data 被设置为 ‘no’, slave 将响应一个错误“ SYNC with master in progress” 给 除了INFO 和 SLAVEOF的 所有的命令
slave-serve-stale-data yes
#你可以 配置 slave 实例 去接受或不接受 写。 slave支持写 可能 对 存储一些 短暂临时的数据 是很有用的,(因为 写在slave 的数据 可以很容易的在和master同步后被删除), 但 如果客户端的错误配置,也会引起问题
从 Redis 2.6 之后 默认的 slave 是只读的。
注意: 从服务 只读 设置 不是 专为 暴露给 在internet网络上不信任的客户端 设计的。它仅仅是 防止 错误使用 实例的 一个保护层。只读 的从服务 默认地仍然会暴露所有的 管理性质的命令 如: “CONFIG”, “DEBUG”, 等等。 在一定程度上,你可以通过 使用“rename-command” 来掩盖所有的管理的/危险的 命令。
slave-read-only yes
#复制 同步策略 : 硬盘 或者 socket
警告: 无硬盘复制 当前是 实验性质。
#新的 slaves 和 重新建立连接的slave 是不能够继续 复制处理。 需要做的是叫做“全部同步“。
# 一个 RDB 文件 从 master 被传播到 slaves.
# 有两种不同的 传播方式:
# 1) 硬盘back : master 创建一个新的 进程来在硬盘上写 RDB 文件, 之后file 增量方式 从父进程 传输到 slave 。
#2) 无硬盘: master 创建一个新的进程 ,他 直接将 RDB文件 写到 slave sockets, 完全不需要落地到硬盘
#使用硬盘的复制方式, RDB 文件生成时, 多个slave 排队等待着处理, 当前RDB 文件被处理完成后,他就可以使用RDB文件来提供服务了。
无硬盘的复制 是 ,当前 一个 结束后,后边排队的传输就开始了。
#当使用 无硬盘复制时,master 可以等待一定时间(几秒) 再开始传输,为的就是 多个 slave 都能到达,然后并行传输。
#像 慢的硬盘速度, 和 快的,有大带宽的网络环境, 无硬盘复制 就更适合了。
repl-diskless-sync no
# 当启用 无硬盘复制, 就很有必要 配置 延迟时间了, 这是为了并行的开启多个子进程 来通过 socket 将 RDB 传输 给 slaves
# 这很重要,因为 一旦开始 传输了,他就不能去 服务 新来的slave 了, 新来的,只能排队 等待下一次的 RDB 传输, 所以master
等待 一个 delay 时间 就是为了 让更多的slave 能及时到达。
# delay 以秒 为单位, 且 默认 为 5 秒, 为了完全禁用它,你可以将它设置为0, 这样传输 使用 ASAP 方式
repl-diskless-sync-delay 5
# slaves 会 以事先定义好的间隔时间来发送PING 包。可以通过下面的选项 来改变 这个间隔时间的 值, 默认的值 是 10秒
# repl-ping-slave-period 10
#下面的 选项 设置 复制的超时时间 是为了:
#1) 同步期间 大体量的传输 IO, 从slave角度看
#2)master超时时间, 从slaves 角度看 (data, pings)
# 3) slave 超时时间, 从 master角度看 ( Replconf ACK pings).
#
# 很重要的一点是 一定要 确保 下面选项的值 比 “repl-ping-slave-period “ 指定的 值大; 否则每次 master 和slave 的传输都会被
#认为是 发生超时了,这是很很低效的传输。
#
# repl-timeout 60
# 在同步完成后 在 slave socket 上 禁用 TCP_NODELAY?
# 如果你设置为 “yes” , Redis 将 使用 少量的TCP包 和少带宽 来发送数据给 slaves.
# 但是这会使 数据到达 slave 上 增加延迟, 根据Linux 内核的默认配置 是 40毫秒。
# 如果 你 设置为“no”, 数据到达slave 侧 的延迟将会降低,但是会使用更多的带宽。
# 默认的 我们优化的目标 是 低延迟, 但是在非常高的 传输负载 下、或者 master 和 slave 有许多跳 时,使用“yes” 可能是个好办法。
repl-disable-tcp-nodelay no
# 设置复制 的“积压大小” 。 这个 “backlog” 就是 缓冲, 有时slaves 失去连接时,积累从的数据 就放在这个缓冲区中, 所以当
# slave 再次连接进来,通常没必要进行一个 完全的 同步,只需要部分的再 同步 就足够了,只需要传递 slave 失去连接的这段时间的数据即可。
#
# 将 backlog 设置为更大的值,就能支持 slave 失去连接的 时间更长。
# backlog 内存 只会被分配一次, 必要条件是 “至少有一个 slave ”,
#
# repl-backlog-size 1mb
#
# 在 master 和 slave 的连接 断开一定时间后,backlog 对应缓冲区 将被释放, 下面的配置选项 单位是秒。
#
# 0 的值 意味着 从来不要释放 backlog.
#
# # repl-backlog-ttl 3600
# 有 小数字权重的 slave 是更有可能被 晋升, 所以 如果 现在 有 三个 slave 权重 分别是 10, 100, 25, 哨兵将会选择 值为10的slave,
# 因为 他的值最小
#
# 然而 0 值的slave, 不能够担任master, 所以 0 值的slave, 不会被哨兵选择来晋升。
#
# 默认的 权重的值 是 100
# slave-priority 100
#
# “如果 在 M秒的时间内,少于 N 个 slave 连接, master 就停止接受 写” 这是可以做到的,
#
# N 个Slave 需要是 在线的状态。
#
# 迟滞 的单位是秒, 它必须 小于等于 指定的值M, 迟滞的计算是从 收到上一个slave 发来的ping 开始计算。ping 通常每秒发送一个。
#
# 这个选项 不保证 N 个 slave 能接受 write, 但它可以限制 。。。。
#
# 例如: 至少 需要3 个 slave, 迟滞 小于等于 10秒 如下设置:
#
# min-slaves-to-write 3
# min-slaves-max-lag 10
# 可以 设置 上面的 为 0 来禁用 此功能
#
# 默认的 “min-slaves-to-write” 被设置为 0 (禁用此功能),min-slaves-max-lag 被设置为 10
#
# master 能够 以各种方式 列出 slave 的 地址 和端口 。如: “ INFO replication” , 它通常由 哨兵使用, 为了去发现 slave.
# 另外一个地方 就是 master 的 “ROLE” 命令 的 输出信息也包含它,
# slave 的 IP 地址 可以由 下面两种方式获取:
#
# IP: 可以通过 slave 到 master 连接 的 sockets 对 来自动的获取 到
# Port : 在 slave 复制 的 握手阶段,就可以得知 端口,
# 然而 当 端口转发 或者 使用NAT , slave 可能被 通过 不同的IP 和 端口 到达。 下面的 两个选项,slave 用来去 报告 给 master 它的 IP和port,
# 为了 INFO 和 ROLE 能报告 这些值。
#
# slave-announce-ip 5.5.5.5
# slave-announce-port 1234
################################## 安全(SECURITY) ###################################
#要求 客户端 在处理任何命令前 发出 AUTH <PASSWORD> 。 这可能 在某种环境下很有用,这样环境是:你不信任其他的客户端去访问正在 运行着的 Redis服务器
#
# 为了先后兼容,你可以注释掉它,因为大多数人不需要 auth (例如: 他们 运行他们自己的 服务器)
#
# 注意: 由于redis 是相当快, 外部的用户 可以 以每秒 15万次 去尝试。 这意味着 使用 一个非常健壮的密码, 否则很容易被破解。
#
# requirepass foobared
#
# 重命名 命令
#
# 在 一个共享的环境中 去对 危险的命令去重命名,是被允许的。例如 : CONFIG 命令, 它可以被重命名为 更难猜的名字,这样一般的客户端
# 就不能再使用,对于内部使用的 工具 还是仍然可以使用此命令的。
#
# 例如:
#
# rename-command CONFIG b840fc02d524045429941cc15f59e41cb7be6c52
#
# 去完全禁用 一个命令 也是可以的,方法就是 重命名为空字符串:
#
# rename-command CONFIG ""
#
#注意: 命令的名字,这种行为也会被记录在AOF 文件中 ,也会传输到slave 中,可能会引起问题。
################################### 限制(LIMITS) ####################################
#设置 在同一时间 的 最大 客户端链接数量。 默认的,这个 limit 被设置为 10000 客户端。。。。
#
# 一旦 限制达到了, Redis将关闭所有新的连接,并发送给连接的另一端 一个错误“ max number of clients reached’.
#
# maxclients 10000
# 不要 使用内存超过 指定数量的字节
# 当 到达了内存限制,Redis 将 根据 相应的驱逐策略( maxmemory-policy ) 来尝试移除 keys.
#
# 如果 不能够根据 策略 来移除 keys 或者 policy 被设置为 ‘不驱逐’, Redis 将 对一些命令响应 错误信息, 这些命令像
# SET, LPUSH,等等, 但它会继续正常的响应 只读的命令,如 GET.
#
# 如果Redis 被当作 LRU 缓存 时,这个选项很有用, 或者 被用来做一个严格内存限制(配合着,使用‘noeviction’ 策略).
#
# 警告: 如果 你的 slaves 开启了 maxmemory, ………..【不能理解!】
#
# 简而言之, 如果 你使用了 slave, 建议你 设置 一个更小的 maxmemory, 为了在 slave上 系统还能为 输出缓冲,留有一些内存空间(
# 但是 如果 是‘noeviction’ 策略,就没必要这样做了)。
#
# maxmemory <bytes>
# MAXMEMORY 策略: 就是 当内存使用 达到 maxmemory 的值时, Redis 如何去移除keys
#
# volatile-lru, -> 使用LRU 算法 移除掉那些带有 过期时间的key
# allkeys-lru -> 使用 LRU算法,移除掉 任意一个 key
# volatile-random -> 随机地 删除 一个带过期时间的key
# allkeys-random -> 随基地删除 一个 任意的key
# volatile-ttl -> 移除那些马上要过期的key (
# noeviction -> 不过期任何的key, 只是 对写操作返回一个 错误
#
# 注意: 当没有合适的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个keys 然后挑选一个 最近最少使用的, 你可以使用下面的配置 指令改变 这个 采样大小
#
# 默认的5 是 能产生 足够好的结果。 10左右 非常接近 真正的LRU,但是花费更多的CPU. 3 是 非常快,但不是非常精确
#
# maxmemory-samples 5
############################## 追加模式(APPEND ONLY MODE) ###############################
# 默认地 Reids 同步地到处数据到硬盘上。 这种模式 在大多数模式下 是足够好了, 但是 Redis进程的问题 或者 突然的 停电 都可能
# 引起几分钟的数据丢失 (取决于配置的保存点)
#
# AOF 模式( Append Only File )是 一个 另类的持久化模式 它提供了更好的 持久性。 像使用了 fsync 策略 保存的数据,Redis 即便是在发生 如:
# 突然断电的事件 或者 Redis 进程发生问题(但操作系统是仍然正确运行) 的 情况下 也只会丢失 一秒的写数据。
#
# AOF 和 RDB 持久化方式 可以被同时使用,没有任何问题。
# 如果AOF 被启用了, 在Redis 启动时 将会加载 AOF文件, 这个文件 会有更好的持久性的保证。
#
# 请 查看 http://redis.io/topics/persistence 来获取更好的信息。
appendonly no
# 只 追加 文件 名字: (默认是 “appendonly.aof”)
appendfilename "appendonly.aof"
# fsync() 调用 告诉 操作系统 去 真实地 写数据到硬盘上,而不是 等着 为了有更多的数据到输出缓冲。
# 一些OS 将真正地刷新数据到硬盘上, 一些其他的OS 将仅仅只是 试着去做 采用 ASAP方式。
#
# Redis 支持三种不同的模式:
#
# no : 不进行 fsync, 仅让 OS 想刷新数据的时候再刷新。 这种快。
# always : 每次 写append only 日志 就去 fsync。 慢, 但是最安全。
# everysec : 每秒钟 进行一次 fsync。 折中的方案。
#
# 默认是 “everysec”, 它通常是 速度快 和 数据安全 之间正确的折中,妥协的方案
#
# 更多详情 可以检查下面的标题:
# http://antirez.com/post/redis-persistence-demystified.html
#
# 如果不知道怎么使用, 就用 ”everysec".
#
# appendfsync always
appendfsync everysec
# appendfsync no
# 当AOF fsync 策略被设置为 always 或 everysec。 则后台进程就会执行大量的I/O 操作, 在一些Linux配置, Redis 会在
# fsync上 阻塞很长时间。 注意当前 没有修复这个问题。因为即便 在不同的线程上执行,也将会阻塞我们的同步写 调用。
#
# 为了缓和这个问题, 使用下面的选项 将可以在 主进程正在调用BGSAVE 或 BGREWRITEAOF 时,阻止主进程调用fsync()。
#
# 这意味着 当另一个子进程 正在保存,Redis 的 持久性和 “appendfsync none” 一样。 在特殊的时期,在特殊情况,Redis可能
# 丢失 达到 30秒( 这是 Linux 系统的默认设置)的数据。
#
# 如果你有潜在的问题 ,你可以改为“yes” 。 否则,就让它为 “no”, 这是 从 持久性的角度看 是 最安全的选择。
#
no-appendfsync-on-rewrite no
# 自动 重写 AOF 文件
# 当 AOF 日志文件 增长超过指定的百分比时, Redis 能够自动地 重写 log 文件,含蓄的叫 BGREWRITEAOF,
#
# 他的运行机制 是: Redis 会记录最新的AOF 文件的大小(如果 从一启动就没有 rewrite 过,那么就使用一开始的AOF)
# 和 当前的 大小 比较。 如果 当前大小 比 指定的百分比更大, 就会触发 rewrite。
# 要给AOF文件 指定一个需要重写的最小 大小,这个很有用,当AOF文件百分比增加达到了,但大小没有达到,就可以避免rewrite 了
#
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
# 当AOF 数据被加载到内存时,Redis 的启动进程 会找到 AOF文件,可能会在进程的最后阶段将 AOF文件进行重置。
# 这会发生在 当 Redis 是 宕机, 特别是 ext4 文件系统 挂载时,没有按照数据顺序( 然而 当Redis 自己宕机,或者终止,而操作系统仍然工作正确)
#
# 当这种情况发生时,Redis 既可以推出并返回错误,也可以 (如果AOF文件被找到并在最后被重置) 加载更多地加载 数据。下面的选项可以控制此行为。
#
# 如果 aof-load-truncated 被设置为 yes, 则 AOF文件被加载并且Redis 服务 会 触发一个日志 来通知 用户这个事情。
# 因此 如果 选项 被 设置为 ‘no’, 服务器就会以发出错误信息终止,并且拒绝去开始启动。 当 选项被设置为 no, 用户需要 在开始服务器前使用 “redis-check-aof”工具去修复AOF文件。
#
# 如果 AOF 文件 在中间部分 被发现 出错误了,那么 Redis 服务 仍然会推出并返回错误。 这个选项 仅适用于 当Redis 试着去从AOF文件中 读取更多的数据,而没有足够的
# 数据被发现时。
################################ LUA脚本 (LUA SCRIPTING) ###############################
#
# lua 脚本的 最大执行时间,单位 “毫秒”
#
# 如果达到了最大执行时间, Redis 将记录日志,脚本仍然会执行,并且对 给查询要查询的 命令 返回一个错误。
# 当 一个正在运行的脚本,超过了最大执行时间,这时只有SCRIPT KILL 和 SHUTDOWN NOSAVE 命令可以用。 第一个命令可以用来去停止一个脚本,
# 这个命令不认为是 “写命令”, 第二个命令用来去关闭服务器, 为了防止脚本中的写命令出现问题,并且用户不想等待脚本的自然终止的这种情况。
#
# 设置为 0 或者 负数 值 含义 是 不限制 执行时间,也不会产生警告!
#
################################ Redis 集群 (REDIS CLUSTER ) ###############################
#
# ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
# 警告:实验性的 : Redis 集群被认为是 标准的代码, 为了能够去给它 一个“成熟”的标签,我们需要去等待 非凡的比例的用户去部署在生成环境中。
# ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
#
# 正常情况下 Redis 实例 不是Redis 集群的一部分; 只有当它被当作集群节点被启动时,它才能成为 集群节点。 为了将其作为一个集群节点来启动,集群需要
# 去掉下面选项的注释
#
# cluster-enabled yes
# 集群上的每一个节点 都有一个集群配置文件。 redis 不被打算手动来编辑, 它被Redis 节点创建和更新。每个Redis 集群节点都需要个一个不同的 集群配置文件。
# 要确保 运行在同一个系统上的 实例 不要使用相同的集群配置文件
#
# cluster-config-file nodes-6379.conf
#
# 集群节点超时时间,是毫秒为单位的, 一个节点 在这个时间内没有到达,就被认为处于 一个失败的状态。
#
# cluster-node-timeout 15000
# 一个 slave 如果它的数据 看起来很老,他会避免 开始故障转移。
#
# 对于 slave 当前没有 一个简单方式 去 真实的测量他的 数据 有效期, 所以会 有下面的两种检查行为。
#
# 1) 如果这里有 多个 slave 可以来进行 故障转移, 他们之间会交换信息,目的就是 选出 优势最大的那个 slave (更多的数据来自master 进程)
# slave 将 获取它自己的排名, 来应用到 故障转移
#
# 2) 每个slave节点 会 计算他和master 上次交互时的时间。 这可以通过ping 或者 收到的命令, 或者 和master 断开连接后的时间。
# 如果上次交互是太老, slave 将不会尝试 去故障转移。
#
# 第二点 可以被用户调试到。 具体来说 一个slave 不会执行故障转移,是由于,和master 的上次交互 的时间 大于:
#
# (node-timeout * slave-validity-factor) + repl-ping-slave-period
#
# 例如: 如果 node-timeout 是 30秒, 并且 slave-validity-factor 是 10, 并且 假定 repl-ping-slave-period 是 10秒 , 如果 slave 没能够 和master交互超过
# 310秒, 那么slave 将不会尝试着去故障转移。
#
# slave-validity-factor 有一个大的值 可以允许 slave 有一些太老的数据 也能进行故障转移, 然而 较小的值 可能会阻止集群 去快速的选择一个slave.
#
# 为了最大的可用性, 将slave-validity-factor 设置为0 值也是可以的,这样意味着: slaves 将总是 尝试 去故障转移 master, 而不管 它上次和master交互的时间
# ( 然而他们总是去根据他们的排名 来 按比例延迟)。
#
# cluster-slave-validity-factor 10
# 集群的 slave 能够迁移到 孤儿master , 孤儿master 是指没有 slaves 。 这会改进 集群 对抗失败的 能力.
# 孤儿master 如果在没有slave 情况下失败,是不能够 故障转移,
#
# 当 对于 老的 master 仍然 至少有一个(number 个)slave时, slave就可以迁移到 孤儿master。 这个number就是 “migration barrier” 。
# migration barrier 的值 1 意味着 master 至少有一个slave时 ,slave就可以 能迁移。 这个通常反映了 集群中 每个master 对应的slave 数量。
#
# 默认是 1 ; 你想禁用 这个功能,只需要 设置一个很大值 即可。0 值也是可以设置的,这种设置对 debug很有用,对在生成环境上是很危险的。
#
# cluster-migration-barrier 1
# 如果集群 侦测到 有至少一个 hash slot 没有被覆盖(没有节点对此slot服务),那么Redis集群节点就会停止接受 查询命令。
# 如果 集群中的部分 挂掉了(例如 : 一个范围的 hash slots 不再被覆盖), 集群 将变的 最终地, 不可用。
# 一旦所有的slots 被再次覆盖,它会 自动变的 可用。
#
# 然而 有时 你想 你的集群 部分是 正常工作,并能继续接受 查询 (这些查询设计的slot 仍然被覆盖的)。为了做到这样,你只需
# 设置 cluster-require-full-coverage 选项 为 no。
#
# cluster-require-full-coverage yes
# 为了去设置你的 集群,首先要确保 查看了 相关文档。
# 可用的 网址 : available at http://redis.io web site.
################################## 慢查询日志 ( SLOW LOG) ###################################
# Redis 的 慢查询日志 记录了 那些超过了指定执行时间的 查询。这个执行时间 不包括 I/O 操作 像 和客户端的连接, 发送响应等,
# 它 仅仅是 确实要执行命令需要的时间 (在命令执行期间,线程是阻塞的,并且不能够在同一时间服务其他的请求)
# 下面的时间,单位是微秒, 所以 1000000 是等于 1秒。 负数值 表示 禁用掉 满查询日志, 0值 会强制记录每个命令。
slowlog-log-slower-than 10000
# 这里对 长度没有限制, 只需要注意的是,它会消耗内存, 你可以 使用 SLOWLOG 重新声明 内存。
slowlog-max-len 128
################################ 潜在的 监控(LATENCY MONITOR) ##############################
# Redis 的潜在的监控子系统 在Redis 运行时 可以采集不同的操作,为了去 收集 Redis实例的数据。
# 通过 LATENCY 命令 用户能够获取 相应的信息,并且可以打印为 图像 或 获取报告。
#
# 系统 仅仅记录 那些执行时间等于或者大于 “latency-monitor-threshold “ 的值的操作。 当它的值被设置为0, 则,潜在的监控
# 就被关闭了。
#
# 默认地 潜在监控 被 禁用, 是由于 如果你没有潜在的问题,它大多数是不需要的,并且收集数据会有性能上的损耗,尽管不大,但在
# 大负载的情况下还是能够测量到的。如果有需要的话, 在运行时 可以使用“ CONFIG SET latency-monitor-threshold <milliseconds>”命令 来很容易地开启。
latency-monitor-threshold 0
#
#############################事件通知( EVENT NOTIFICATION )##############################
# Redis 可以 给 Pub/Sub 客户端 通知一些关于 key空间 的一些事件。
# 这个功能 的 文档 在: http://redis.io/topics/notifications
#
# 对于实例 如果开启了 事件通知, 当 一个 客户端 对 一个 存储在 Database 0 上 的 “foo” Key 执行 DEL 操作, 则 有两种消息 会通过
# Pub/Sub 发布出去。
#
# PUBLISH __keyspace@0__:foo del
# PUBLISH __keyevent@0__:del foo
#
# 去 选择 Redis 定义的一个类集的事件 来通知是可能的。 每个类 都被用 一个 单独的字符 来定义。
#
# K Keyspace 事件, 使用 __keyspace@<db>__ 来发布
# E Keyevent 事件 , 使用 __keyevent@<db>__ 来发布
# g Generic 命令 , 非指定类型的命令 如: DEL, EXPIRE, RENAME, …
# $ 字符 命令,
# l 列表命令,
# s 集合 命令
# h 哈希 命令
# z 有序集合命令
# x 过期事件 (每次 一个key 过期时,就会产生一个事件)
# e 驱逐事件 (当一个key 被 maxmemory 机制 驱逐掉时 产生)
# A g$lshzxe 的别名,所以 “ AKE” 意味着 所有事件。
#
#
# notify-keyspace-events 接收 一个由 0个或多个 字符组成的字符串 作为参数。空的字符串 意味着 禁用 通知机制。
#
# 例如 : 从事件名的 视角 来 启用 list 和 generic 事件。使用:
#
# notify-keyspace-events Elg
#
# 例子2: 为了 获取 过期key 订阅的 名叫 __keyevent@0__:expired 的频道 产生的数据流。
#
# notify-keyspace-events Ex
#
# 默认地 所有的通知功能是被禁用的,因为大多数人 不需要使用此功能,并且此功能有些开销。注意,
#如果你不指定 K 或 E 中至少一个,那么就不会有事件被投送。
notify-keyspace-events ""
############################### 高级配置 (ADVANCED CONFIG) ###############################
# Hash 当有一些少量的 entry 时 被 使用 一个内存高效的数据结构 编码, 最大的 entry 数量不要 超过一个 给定的 门槛。
# 这个 门槛 可以使用如下的指令 来配置。
hash-max-ziplist-entries 512
hash-max-ziplist-value 64
# List 也会以一种特殊的方式 来进行编码,为了能够节省空间。
# 每个 list 内部 entry 的数量 可以被 用 固定的内存大小或者 固定的元素数量,来指定。
# 对于固定的内存大小 ,使用 -5 至 -1 ,含义如下:
# -5 : 最大大小 :64Kb <— 不建议! 对正常的工作负载来说
# -4 :最大大小: 32Kb <— 不建议
# -3 :最大大小: 16Kb <— 可能不建议
# -2 : 最大大小: 8Kb <— 好
# -1 : 最大大小 <— 好
# 整数数值 意味着 每个 list 存储的真是的 元素的数量
#
# 最高性能的选项 通常是 -2 或 -1
list-max-ziplist-size -2
# List 有可能也被压缩。
# compress-depth 是 quicklist ziplist 从 *each* 到 *exclude* 的节点的数量 。列表的头和尾总是不被压缩,
# 是 为了更快的 push/pop 操作。 设置有:
# 0 : 禁用 所有压缩
# 1 : 在list 中 从 第一个节点后开始压缩 , 不管是 从头 或尾部 开始都是如此。
# 所以 :[head]->node->node->...->node->[tail]
# [head], [tail] 将总是不被压缩, 内部的节点将被压缩。
# 2 :[head]->[next]->node->node->...->node->[prev]->[tail]
# 2意味着 不压缩 head 或 head->next 或者 or tail->prev 或者 tail。 但是压缩他们中间的节点
# 3: [head]->[next]->[next]->node->node->...->node->[prev]->[prev]->[tail]
# 等等
list-compress-depth 0
# 在某种情况下 会使用特殊的编码, 这个情况就是 一个 集合 由 字符串组成,碰巧 是 10 进制整型,范围在 64位无符号整型范围内。
# 下面的配置 可以设置 集合的限制,这个限制是为了能够使用 特殊的节省内存的编码。
#
set-max-intset-entries 512
# 类似哈希、列表 ,有序集合 也会使用特殊的编码 以 节省许多空间。
# 当 长度 和 有序集合里边的元素 低于 下面的 限制时,才会使用此编码。
zset-max-ziplist-entries 128
zset-max-ziplist-value 64