Redis 深度探险（三）：Redis 单机环境搭建以及配置说明

前言

经过 Redis 深度探险系列的学习相信大家对 Redis 的数据结构、对象、持久化机制、过期键删除策略等知识有了大致的了解，本篇博文主要讲述 Redis 的安装步骤，然后介绍一下 Redis 配置说明，最后对 Redis 集群搭建进行详细的讲解。

单机环境搭建

Mac 安装 Redis

Mac 中使用 brew 安装 Redis 的方法

$ brew install redis

Linux 安装 Redis

Ubuntu 中使用 apt-get 安装 Redis 的方法

$ sudo apt-get install redis-server

CentOS7 中使用 yum 安装 Redis 的方法

1. 检查 Redis 版本

// 通过 yum info redis 可知 Centos7 中 Redis 源的版本为3.2.12
$ yum info redis

2. 安装 Redis 数据库

$ yum install -y redis

3. 启动 Redis 数据库

$ systemctl start redis

4. 查看 Redis 运行状况

$ systemctl status redis

5. 检测 Redis 服务器是否开启

$ ps -ef | grep redis

6. 通过上述方法安装的 Redis 版本较低，如果想安装最新的 Redis 请执行如下命令

// 安装 Remi 的软件源
$ yum install -y http://rpms.famillecollet.com/enterprise/remi-release-7.rpm
// 更换 yum 源，通过 remi 源安装 Redis
$ yum --enablerepo=remi install -y redis

Redis 简单配置以及配置说明

Rdis设置为开启启动

$ systemctl enable redis.service

开启远程连接，Redis 默认只能 localhost 访问

修改 /etc/redis.conf 配置文件，执行 systemctl restart redis 重启 Redis 即生效。

1. 输入命令 vim /etc/redis.conf 进入编辑模式
2. bind 127.0.0.1 修改为 bind 0.0.0.0
3. protected-mode yes 修改为 protected-mode no（保护模式，是否只允许本地访问）

设置密码

修改 /etc/redis.conf 配置文件，在 requirepass foobared 前面去掉注释，将 foobared 改为自己的密码，我在这里改为 requirepass foobared，执行 systemctl restart redis 重启 Redis 即生效。

在线变更配置

// 通过 redis-cli 连接 redis 客户端，使用 AUTH 进行认证
127.0.0.1:6379> auth foobared
// 获取当前配置
127.0.0.1:6379> CONFIG GET *
// 修改密码为 root
127.0.0.1:6379> CONFIG SET requirepass root
// 将修改后的配置写入配置文件
127.0.0.1:6379> CONFIG REWRITE

配置文件详解

Redis 配置文件 redis.conf 以及Redis 配置文件 redis.conf 中文详解：

# 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 是一样的.

################################## INCLUDES ###################################

# 如果你拥有一个标准的配置模板, 并且希望在该模板之上做一些个性化的修改, 你可以使用 include 指令来引入其他的配置文件.
#
# 注意:"include" 不会被 admin 或者 Redis Sentinel "CONFIG REWRITE" 命令覆盖.
# 由于 redis 以最终的配置作为实际配置, 因此我们希望你将 include 命令放置在配置文件的最前面以防配置被覆盖.
# 
# 如果你打算使用另外的 conf 文件来覆盖当前文件的配置, 那么最好将 include 指令放置到该文件的末尾. 
# 即最后生效原则, 最后被解析的配置将作为最后的配置.
#
# include /path/to/local.conf
# include /path/to/other.conf

################################## MODULES #####################################

# 启动时加载模块. 如果服务器无法加载模块, 它将中止. 可以使用多个 loadmodule 指令.
#
# loadmodule /path/to/my_module.so
# loadmodule /path/to/other_module.so

################################## NETWORK #####################################

# 默认情况下 redis 会在所有的可用网络接口中进行监听, 如果你想让 redis 在指定的网络接口中
# 监听, 那么可以使用 bind 命令来指定 redis 的监听接口.
#
# 例如:
#
# bind 192.168.1.100 10.0.0.1
# bind 127.0.0.1 ::1
#
# ~~~ 警告 ~~~ 如果允许所有的网络接口访问 Redis, 这样做是很危险的, 如果你只是需要本机访问 
# 可以指定特定的 127.0.0.1, 如果需要外网访问, 请配置防火墙策略.
#
# IF YOU ARE SURE YOU WANT YOUR INSTANCE TO LISTEN TO ALL THE INTERFACES
# JUST COMMENT THE FOLLOWING LINE.
# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
bind 127.0.0.1

# 是否开启保护模式, 默认开启. 要是配置里没有指定 bind 和密码.
# 开启该参数后, redis 只会本地进行访问, 拒绝外部访问.
# 要是开启了密码和 bind, 可以开启. 否则最好关闭, 设置为 no.
protected-mode yes

# 在指定的端口上进行监听, 默认是 6379.
# 如果端口设置为 0, 那么 redis 就不会在 TCP socket 上进行监听.
port 6379

# TCP listen() backlog.
#
# 在一个并发量高的环境中, 你需要指定一个比较大的 backlog 值来避免慢连接的情况.
# 注意, linux 内核会默认 使用 / proc/sys/net/core/somaxconn 的值来削减 backlog 的实际值,
# 因此你需要确保提升 somaxconn 和 tcp_max_syn_backlog 这两个值来确保此处的 backlog 生效.
tcp-backlog 511

# Unix socket.
#
# 指定 unix sock 的路径来进行连接监听, 默认是不指定, 因此 redis 不会在 unix socket 上进行监听.
#
# unixsocket /tmp/redis.sock
# unixsocketperm 700

# 关闭掉空闲 N 秒的连接 (0 则是不处理空闲连接)
timeout 0

# TCP keepalive.
#
# 如果该值不为 0, 将使用 SO_KEEPALIVE 这一默认的做法来向客户端连接发送 TCP ACKs 
#
# 这样的好处有以下两个原因:
# 1) 检测已经死亡的对端 (译者注: TCP 的关闭会存在无法完成 4 次握手的情况, 如断电, 断网, 数据丢失等等)
# 2) 保持连接在网络环境中的存活
#
# 在 Linux 中, 该指定时间是一次发送 ACKs 的时间片.
# 对于其他内核系统, 其时间片大小与内核配置有关.
# 一个比较合理的值是 300 seconds.Redis 3.2.1 版本之后默认指定该值为 300 seconds.
#
tcp-keepalive 300

################################# GENERAL #####################################

# redis 默认不是以一个守护进程来运行的, 使用 yes, 可以让 redis 作为守护进程来运行.
# 注意: 当 redis 作为守护进程的时候 /var/run/redis.pid 作为 pid 文件.
daemonize no

# 如果需要在机器启动 (upstart 模式 或 systemd 模式) 时就启动 Redis 服务器, 可以通过该选项来配置 Redis.
# 支持的模式:
#	supervised no      – 无, 不会与 supervised tree 进行交互
# 	supervised upstart – 将 Redis 服务器添加到 SIGSTOP 模式中
# 	supervised systemd – 将 READY=1 写入 $NOTIFY_SOCKET
# 	supervised auto    - 根据环境变量 UPSTART_JOB 或 NOTIFY_SOCKET 检测 upstart 还是 systemd
# 
# 注意, 上述 supervision 方法 (upstart 或 systemd) 仅发出 “程序已就绪” 信号, 不会继续给 supervisor 返回 ping 回复.
supervised no

# 如果指定了 pid 文件, Redis 会在启动时写该 pid 文件, 在退出时删除该文件.
# 当 Redis 服务器已守护进程启动时, 如果指定了配置文件, 则直接使用, 如果没有指定, 则创建 / var/run/redis.pid 作为配置文件.
pidfile /var/run/redis_6379.pid

# 指定日志的记录级别的.
# 可以是如下的几个值之一:
# debug (尽可能多的日志信息, 用于开发和测试之中)
# verbose (少但是有用的信息, 没有 debug 级别那么混乱)
# notice (适量的信息, 用于生产环境)
# warning (只有非常重要和关键的信息会被记录)
loglevel notice

# 指定日志文件的位置. 为空时将输出到标准输出设备.
# 如果你在 demo 模式下使用标准输出的日志, 日志将会输出到 /dev/null .
logfile /var/log/redis/redis.log

# 当设置'syslog-enabled'为 yes 时, 允许记录日志到系统日志中.
# 以及你可以使用更多的日志参数来满足你的要求.
# syslog-enabled no

# 指定在系统日志中的身份.
# syslog-ident redis

# 指定系统日志的能力. 必须是 LOCAL0 到 LOCAL7 之间 (闭区间).
# syslog-facility local0

# 设置数据库的数量. 默认的数据库是 DB 0 使得你可以在每一个连接的基础之上使用 
# SELECT <dbid> 来指定另外的数据库, 但是这个值必须在 0 到'database'-1 之间.
databases 16

# 默认情况下, Redis 只会在交互模式才显示 ASCII 版本的 logo, 可以通过设置此选项为 yes,
# 来使 Redis 在任何情况下都显示 logo, 使得 Redis 的此行为和 4.0 之前的版本行为保持一致.
#
always-show-logo yes

################################ SNAPSHOTTING  ################################
#
# 将 DB 数据保存到磁盘:
#
# save <seconds> <changes>
#
# 将会在 < seconds> 和 <changes > 两个值同时满足时, 将 DB 数据保存到硬盘中
# 其中 < seconds> 每多少秒,<changes > 是改变的 key 的数量
#
# 在以下的例子中, 将会存在如下的行为:
# 当存在最少一个 key 变更时, 900 秒 (15 分钟) 后保存到硬盘
# 当存在最少 10 个 key 变更时, 300 秒后保存到硬盘
# 当存在最少 1000 个 key 变更时, 60 秒后保存到硬盘
#
# 提示: 你可以禁用如下的所有 save 行.
#
# 你可以删除所有的 save 然后设置成如下这样的情况.
#
# save ""

save 900 1
save 300 10
save 60 10000

# 默认情况下, 在发生 RDB 快照或 BGSAVE 执行失败的那一刻, Redis 执行接收写请求.
# 这会使用户察觉 (通常比较困难) 到数据没有正确的持久化到磁盘. 否则有可能出现不被察觉的灾难性后果.
# 
# 当后台 BGSAVE 程序可以再次开始工作时, Reidis 会再次自动允许写入.
# 
# 如果已经对 Server 和服务器持久化建立了正确的监控, 那么当你禁用该功能后, 即使磁盘、持久化等出现问题, Redis 也能继续提供服务.
stop-writes-on-bgsave-error yes

# 是否在 dump 到 rdb 数据库的时候使用 LZF(一种高效的压缩算法) 来压缩字符串.
# 默认是 yes, 因为这是一个优良的做法.
# 如果你不想耗费你的 CPU 处理能力, 你可以设置为 no, 但是这会导致你的数据会很大.
rdbcompression yes

# 从 RDB 的版本 5 开始, CRC64 校验值会写入到文件的末尾.
# 这会使得格式化过程中, 使得文件的完整性更有保障,
# 但是这会在保存和加载的时候损失不少的性能 (大概在 10%).
# 你可以关闭这个功能来获得最高的性能.
#
# RDB 文件会在校验功能关闭的时候, 使用 0 来作为校验值, 这将告诉加载代码来跳过校验步骤.
rdbchecksum yes

# DB 的文件名称.
dbfilename dump.rdb

# 工作目录.
#
# DB 将会使用上述'dbfilename'指定的文件名写入到该目录中.
# 
# 追加的文件也会在该目录中创建.
# 
# 注意, 你应该在这里输入的是一个目录而不是一个文件名.
dir /var/lib/redis

################################# REPLICATION #################################

# Redis 主从复制. 单机模式下, Redis 支持使用 slaveof 命令从另一个 Redis 服务器的拷贝中来创建一个实例.
# 集群模式下则使用 cluster replicate <master-id > 命令. Redis 复制使用前须知:
#
#   +------------------+      +---------------+
#   |      Master      | ---> |    Replica    |
#   | (receive writes) |      |  (exact copy) |
#   +------------------+      +---------------+
#
# 1)Redis 复制是异步复制, 但是可以配置连接的从节点数量.
# 2)当连接断开, Redis 从节点支持部分重同步 (psync) 功能来保证主从节点数据同步.
# 3)复制过程是一个自动化过程, 无需人工干预. 当出现网络分区后, 从节点会自动尝试建立与主节点的连接, 并尝试同步.
#
# replicaof <masterip> <masterport>

# 如果主服务器开启了密码保护 (使用下面的 "requirepass" 配置).
# 这个配置就是告诉从服务在发起向主服务器的异步复制的请求之前使用如下的密码进行认证,
# 否则主服务器会拒绝这个请求.
#
# masterauth <master-password>

# 如果从服务器失去了和主服务器之间的连接, 或者当复制仍然处于处理状态的时候
# 从服务器做出如下的两个行为:
#
# 1) 如果 slave-serve-stale-data 被设置为 yes(默认值), 从服务器将会持续
# 回复来自客户端的请求, 可能会回复已经过期的数据,
# 或者返回空的数据, 当从服务器第一次异步请求数据时.
#
# 2) 如果 slave-serve-stale-data 被设置为 no ,
# 从服务器就会返回 "SYNC with master in progress"
# 这个错误, 来应答所有命令除了 INFO 和 SLAVEOF.
#
replica-serve-stale-data yes

# 你可以配置一个从服务器的实例是否接受写请求,
# 从服务器在存储一些短暂的数据的的时候, 接收写请求是一件非常正确的事情
# (因为数据在向主服务器同步之后非常容易擦除) 但是会因为配置不正确而导致一些问题.
#
# 从 redis 2.6 开始默认从服务器是只读的服务器.
#
# 提示: 只读的从服务器并不是设计用来公开给不受信任的互联网客户端的, 它
# 仅仅是一个用来防止对实例进行误操作的保护层. 只读从服务器默认用来输出管理命令
# 例如 CONFIG, DEBUG 和其他. 如果你想限制它的规模, 你可以使用'rename-command'来
# 提高它的安全性, 使得她作为一个影子来执行管理或者危险的命令.
replica-read-only yes

# 是否使用 socket 方式复制数据. 目前 redis 复制提供两种方式, disk 和 socket.
# 
# 对于新连接的 slaves 或断开重连的 slaves 将无法执行 “部分同步”, 需要进行一次完全同步. 当进行完全同步时, 主节点将传播一个 RDB 文件给从节点. 该 RDB 文件的传播方式有两种:
# 1)基于磁盘: Redis 主节点创建一个新进程将 RDB 文件写到磁盘, 然后将生成的 RDB 文件传播给从节点.
# 2)无磁盘: Redis 主节点创建一个新进程直接将 RDB 文件写到 slaves 的套接字中, RDB 文件无需落盘.
# 
# 基于磁盘的复制, 一旦 RDB 文件生成, 多个 slaves 将排队等待并可以共享该文件. 而无磁盘复制一旦开始传输数据, 新 slaves 到来后将会排队等待.
# 
# 在使用无磁盘复制时, 主节点在开始传输同步数据前将根据配置的时间进行等待, 从而实现多个从节点的并发传输.
# 
# 在磁盘速度缓慢且网络速度很快 (高带宽) 时, 无磁盘复制效率更高. 默认情况下, 无磁盘复制同步关闭.
repl-diskless-sync no

# 无磁盘复制前, 主节点需要等待的时间. 该配置在启用无磁盘复制时将生效.
# 由于一旦开启一次数据传输, 其余 slaves 将排队等待, 所以最好让主节点等待一段时间, 这样主节点就可对多个 slaves 并发传播数据.
# 等待的单位是秒(second), 默认是 5 秒. 一旦将其设置为 0, 主节点将会马上开始数据传输.
repl-diskless-sync-delay 5

# slave 根据指定的时间间隔向服务器发送 ping 请求.
# 时间间隔可以通过 repl_ping_slave_period 来设置, 默认 10 秒.
#
# repl-ping-replica-period 10

# 复制连接超时时间. master 和 slave 都有超时时间的设置.
# master 检测到 slave 上次发送的时间超过 repl-timeout, 即认为 slave 离线, 清除该 slave 信息.
# slave 检测到上次和 master 交互的时间超过 repl-timeout, 则认为 master 离线.
# 需要注意的是 repl-timeout 需要设置一个比 repl-ping-slave-period 更大的值,
# 不然会经常检测到超时.
#
# 以下情境将使用到复制超时阈值:
# 1) 从节点在执行 SYNC 期间, 检测块文件传输超时.
# 2) 从节点检测主节点离线(data、pings).
# 3) 主节点检测从节点离线(REPLCONF ACK).
# 
# 必须要确保复制超时阈值 (repl-timeout) 大于 slaves 定时向 master 发送 PING 的时间片(repl-ping-slave-period),
# 否则将总会检测到复制超时(当 slave 发送 PING 的时间片大于复制超时阈值时, slave 还未发送 ping 就会被定性为复制超时).
# repl-timeout 60

# 执行完 SYNC 后, 是否要禁用 TCP_NODELAY.
#
# 当禁用该功能后, Redis 会使用占用更少带宽的小 TCP 包向从节点发送数据.
# 但是这样做将会增大从节点端数据传输延时. 在 Linux 下禁用 TCP_NODELAY 功能将导致 40 微秒的延迟.
# 
# 当启动该功能后, 在进行复制时将会减少数据传输延迟, 但是会占用更大的带宽.
# 
# 默认情况下, 我们优先选择低延迟, 但是在高速网络或主从节点存在多 hops 路径时, 建议禁用 TCP_NODELAY 功能.
repl-disable-tcp-nodelay no

# 设置复制积压缓冲区 (replication backlog) 大小. 当 slaves 断开与节点连接后, Redis 使用复制积压缓冲区记录需要未发送给 slave 的数据.
# 当从节点重连后, 仅需执行一次部分同步, 将从节点缺失数据补全.
# 
# 复制积压缓冲区 (replication backlog) 越大, Redis 可以支持的 slave 离线时间就越长. 复制积压缓冲区用于部分重同步.
# 
# 复制缓冲区只有在有 slave 连接时才分配内存. 没有 slave 时, 该内存会被释放出来, 默认大小为 1m.
#
# repl-backlog-size 1mb

# 当主节点不再有新连接的从节点后, 复制积压缓冲区将会被释放.
# 为避免因从节点频繁掉线后上线而频繁的进行复制积压缓冲区的释放与申请, Redis 提供复制积压缓冲区释放时间片 (repl-backlog-ttl) 参数, 保证主节点在检测到从节点掉线后的规定时间内不会释放该缓冲区.
# 
# 值为零时表示不会释放该复制积压缓冲区, 单位为秒.
# 单位为秒, 配置如下:
# repl-backlog-ttl 3600

# 使用整数表示从节点优先级.
# 
# 当主节点无法正常工作后, Sentinel 将使用该优先级在从节点中推选出新的主节点.
# 
# 优先级对应的整数值越小, 被推选成主节点的可能性更大. 但是当优先级的值为零时表示该从节点不具备成为主节点的身份.
# 
# 默认优先级为 100.
slave-priority 100

# 当主节点的已连接从节点数小于 N 且这些从节点延迟均大于 M 秒, 该主节点将停止接收写请求.
# 
# 从节点处于 “online” 状态, 当且仅当延迟 (通过计算距离上一次接收从节点的 ping 消息的时间间隔获得) 小于指定的阈值.
# 这个选项配置不是用来保证 N 个部分接收写信息, 而是为了在没有足够的从节点可用时, 限制写丢失.
# 
# 如需要至少需要 3 个从节点并在 10s 内可用, 则设置:
# 
# 延迟小于 min-slaves-max-lag 秒的 slave 才认为是健康的 slave.
# min-slaves-to-write 3
# 设置 1 或另一个设置为 0 禁用这个特性.
# min-slaves-max-lag 10
# 
# 一旦对这两个中的一个赋值为零, 则该功能失效.
# 默认 min-slaves-to-write 参数设置为 0, 即该功能默认不启用.

# Redis 主节点可以通过多种途径显示已连接从节点的 IP 和 port. 如 Sentinel 可以使用 “INFO replication” 命令来发现从节点实例；
# Master 可以使用 “ROLE” 命令显示从节点 IP 和 port 信息等.
# 
# slave 获取 IP 和 port 的方式是:
# 	IP: 自动检测获取. 当从节点连接主节点时, 通过检查对应套接字地址获取.
#
#	Port: 从节点在复制中和主节点握手时需要使用到 port. 通常情况下, port 即为连接时的 port.
# 
# 但是, 当发生端口转发(port forwarding, 转发一个网络端口从一个网络节点到另一个网络节点的行为)
# 或使用 NAT(Network Address Translation, 网络地址转换)技术是, 从节点需要被分配不同 IP 和 port 后才能被访问.
# 接下来的两个配置用来设置从节点的 IP 和 port, 用来告知主节点所指定的 IP 和 port, 这样 INFO 和 ROLE 才能继续返回结果.
# 
# 当需要重写 IP 和 port 时, 则无需配置该选项.
# slave-announce-ip 5.5.5.5
# slave-announce-port 1234

################################## SECURITY ###################################

# Server 在处理客户端命令前, 该客户端需要提供提供认证密码. 这在非可信网络环境中很有用.
# 
# 为减少后台执行复杂度, 这个选项一般都会被注释掉. 因为大多数用户不需要授权.(如用户使用自己的服务器)
# 
# Warning: 由于 Redis 执行高效, 所以外部用户每秒可以尝试认证 15w 次.
# 也就是说, 为避免密码被快送攻破, 用户需要使用一个极其复杂的密码.
#
# requirepass foobared

# 重命名命令.
# 
# 在一个共享环境中有必要对危险命令进行重命令, 从而避免危险命令的滥用、无用.
# 如给 CONFIG 命令重新设置一个难以猜测的命令, 这样这个命令就很难被普通用户使用的, 但仍能被内部工具使用.
# 
# 例如:
# 
# rename-command CONFIG b840fc02d524045429941cc15f59e41cb7be6c52
#
# 设置成一个空的值, 可以禁止一个命令.
# rename-command CONFIG ""
# 
# 注意, 一定要避免重命名那些写 AOF 文件或传输数据给 slaves 的命令, 否则将会导致各种难以预料的错误.

################################### CLIENTS ####################################

# 设置能连上 redis 的最大客户端连接数量. 默认是 10000 个客户端连接.
# 由于 redis 不区分连接是客户端连接还是内部打开文件或者和 slave 连接等,
# 所以 maxclients 最小建议设置到 32. 如果超过了 maxclients,
# redis 会给新的连接发送’max number of clients reached’, 并关闭连接.
#
# maxclients 10000

############################## MEMORY MANAGEMENT ################################

# redis 配置的最大内存容量. 不要再内存超过指定限制时仍然使用内存.
# 当达到内存上限时, Redis 会根据选定的过期键策略移除一些 key.
# 
# 如果根据过期键策略仍不能移除一些键或者过期键策略设置成 “noeviction”(不启用过期键策略),
# 那么 Redis 会向如 SET、LPUSH 等使用内存的命令返回错误, 向诸如 GET 等读命令正常返回结果.
# 
# 这个配置通常在将 Redis 当过 LRU 缓存或对以设置硬性的内存上限的 Redis 很适用.
# 
# WARNING: slaves 的输出缓冲区不在主节点的 maxmemory 计算中, 所以设置的 maxmemory 不宜过大.
# 如果过大, 可能导致主机的剩余内存过小, 从而不能预留足够的内存用于创建 slaves 的输出缓冲区.
# 
# 简言之, 如果当前节点存在已连接的从节点, 建立设置一个较小的 maxmemory 上限, 这样系统就可以有多余的 RAM 用与创建从节点输出缓存.(当过期键策略设置成'noeviction'时, 则没有必要这么做)
#
# maxmemory <bytes>

# 内存容量超过 maxmemory 后的处理策略. Redis 提供五种内存淘汰策略:
#
# volatile-lru -> 利用 LRU 算法移除设置过过期时间的 key.
# allkeys-lru -> 利用 LRU 算法移除任何 key.
# volatile-lfu -> 利用 LFU 算法移除设置过过期时间的 key.
# allkeys-lfu -> 利用 LFU 算法移除任何 key.
# volatile-random -> 随机移除设置过过期时间的 key.
# allkeys-random -> 随机移除任何 key.
# volatile-ttl -> 移除即将过期的 key, 根据最近过期时间来删除 (辅以 TTL)
# noeviction -> 不移除任何 key, 只是返回一个写错误.
# 
# 上面的这些驱逐策略, 如果 redis 没有合适的 key 驱逐, 对于写命令, 还是会返回错误.
# redis 将不再接收写请求, 只接收 get 请求. 写命令包括: set setnx
#
# maxmemory-policy noeviction

# lru 检测的样本数. 使用 lru 或者 ttl 淘汰算法, 从需要淘汰的列表中随机选择 sample 个 key,
# 选出闲置时间最长的 key 移除.
# 
# 默认情况下, Redis 会从五个键中选择一个最近最久未使用的键进行淘汰. 可以通过配置该选择设置检测基数.
# 一般情况下, 五个检测样本可以获得足够好的结果. 10 个样本的结果更接近 LRU 算法, 但是会消耗更多的 CPU.
# 3 个样本可以获得较高的执行速度但是不够精确.
#
# maxmemory-samples 5

# 从 Redis 5 开始, 默认情况下, replica 节点会忽略 maxmemory 设置(除非在发生 failover 后, 此节点被提升为 master 节点).
# 这意味着只有 master 才会执行过期删除策略, 并且 master 在删除键之后会对 replica 发送 DEL 命令.
#
# 这个行为保证了 master 和 replicas 的一致性, 并且这通常也是你需要的, 但是若你的 replica 节点是可写的,
# 或者你希望 replica 节点有不同的内存配置, 并且你确保所有到 replica 写操作都幂等的, 那么你可以修改这个默认的行为(请确保你明白你在做什么).
#
# 需要注意的是默认情况喜爱 replica 节点不会执行过期策略, 它有可能使用了超过 maxmemory 设定的值的内存.
# 因此你需要监控 replicas 节点所在的机器并且确保在 master 节点到达配置的 maxmemory 大小时, replicas 节点不会超过物理内存的大小.
#
# replica-ignore-maxmemory yes

############################# LAZY FREEING ####################################

# Redis 有两种方式删除键. 一种是使用如 DEL 这样的命令进行的同步删除. 
# 同步删除意味着删除过程中服务端会停止处理新进来的命令. 若要删除的 key 关联了一个小的 object 删除耗时会很短.
# 若要删除的 key 管理了一个很大的 object, 比如此对象有上百万个元素, 服务端会阻塞相同长一段时间(甚至超过一秒).
#
# 由于以上原因, Redis 同时提供了一种非阻塞的方式用于删除,
# 比如 UNLINK(非阻塞的 DEL)以及用于 FLUSHALL 和 FLUSHDB 的 ASYNC 选项, 这些命令能在后台回收内存.
# 这些命令能在常数时间内执行完毕. 其他线程会在后台尽快回收内存.
# 
# DEL,UNLINK 以及用于 FLUSHALL 和 FLUSHDB 的 ASYNC 选项是用户可以控制的. 
# 根据应用的设计, 用户可以选择使用阻塞或者非阻塞的方式. 
# 但是作为某些命令的副作用 Redis 服务端有时会删除某些 object 或者 flush 整个数据库. 
# 特别是以下独立于用户操作的情形: 
# 1. 由于 maxmemory 和 maxmemory policy 配置导致的内存回收动作 
# 2. 由于过期, 当一个 key 过期后(可以查看 EXPIRE 命令获取相关信息), 必须回收其内存 
# 3. 由于某些命令的副作用, 比如 STORE 命令, 执行 STORE 命令可能需要删除已有的键. SET 命令需要删除已有的旧内容.
# 4. 在复制过程中, 当一个 replica 节点执行一个全量同步时, replica 需要删除整个数据库的内容以加载传输过来的 RDB 文件.
#
# 在上述所有情形中, 删除 object 的默认行为都是以阻塞方式删除. 当然你可以配置上述四个选项来改变这种默认行为:

lazyfree-lazy-eviction no
lazyfree-lazy-expire no
lazyfree-lazy-server-del no
replica-lazy-flush no

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

# 默认 redis 使用的是 rdb 方式持久化, 这种方式在许多应用中已经足够用了.
# 但是 redis 如果中途宕机, 会导致可能有几分钟的数据丢失, 根据 save 来策略进行持久化,
# Append Only File 是另一种持久化方式, 可以提供更好的持久化特性.
# Redis 会把每次写入的数据在接收后都写入 appendonly.aof 文件,
# 每次启动时 Redis 都会先把这个文件的数据读入内存里, 先忽略 RDB 文件.
# 
# 默认情况下, Redis 会异步将数据集快照到磁盘上. 尽管这种模式对许多应用友好, 但是当 Redis 进程崩溃或发生掉电时,
# 几分钟内的写信息将丢失(根据快照执行的粒度).
# 
# AOF 作为一种可替换的持久化策略, 能够提供更好的耐久性.
# 如使用默认的 fsync 策略, Redis 仅会丢失 1s 的写信息, 当发生突发事件(服务器掉电、服务器进程崩溃但 OS 运行正常).
# 
# AOF 持久化和 RDB 持久化可以同时开启. 如果在启动 Redis 时已经存在 AOF 文件, 则会直接加载 AOF 文件(考虑到 AOF 文件相比 RDB 文件有更好的耐久性).
# 关于 AOF 的更多讯息见: http://redis.io/topics/persistence 
appendonly no

# 指定 AOF 文件名称, 默认是 appendonly.aof.
appendfilename "appendonly.aof"

# 调用 fsync() 系统函数用来告知 OS 将数据写入磁盘, 而不是在输出缓冲区等待数据. 有些 OS 将直接 flush 数据到磁盘, 有些其他的 OS 仅会尝试去 flush.
# 
# Redis 支持三种 fsync() 调用模式:
# no: 不执行 fsync, 由 OS 决定 flush 数据的频率. 高效. Linux 下默认是每 30s 执行一次 flush.
# always: 每写入一次 AOF 就调用一次 fsync. 慢, 最安全.
# everysec: 每秒调用一次 fsync, 可能会导致丢失这 1s 数据.
# 
# 默认 fsync 的调用频率是 “everysec”, 这种策略在执行速度和数据安全进行折中.
# 当可以容忍一定程度数据丢失并期望更高的性能时, 可以使用 “no” 策略(由操作系统决定 flush 的频率).
# 相反的, 如果不能容忍数据丢失, 可以使用 “always” 获得更好的安全性, 尽管执行更慢.
# 
# 在无法确定 fsync 调用频率时, 推荐使用 “everysec” 策略.
# 在开启 AOF 持久化功能后, 该配置才会生效.
# appendfsync always
appendfsync everysec
# appendfsync 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 秒数据.

# 当 AOF 执行 fsync 的策略是 always 和 everysec 时, 如果此时有一个后台进程 (BGSAVE 进程或 AOF rewrite 进程) 正在执行大量的 I/O 操作到磁盘,
# 在一些 Linux 系统中, 执行 fsync 会造成较长的阻塞. 当前对这种情况还没有很好的解决策略, 即使在不同的线程中执行 fsync 也会导致调用同步 write(2) 阻塞.
# 
# 为了缓解上述问题, 可以通过配置下述选项来避免在主线程调用 fsync() 时执行 BGSAVE 或 BGREWRITEAOF 带来的阻塞.
# 
# 也就是说, 默认情况下, 当子进程执行 BGSAVE 或 BGREWRITEAOF 时, Redis 的耐久性将默认转变成 "appendfsync none".
# 在实际的应用中就意味着在最坏的场景下将丢失 30s 的数据, 即使配置了 fsync 调用频率为 always 或 everysec.(默认情况下, Linux 每 30s 自动调用一次 fsync 将缓存数据 flush 到磁盘)
# 
# 如果当前应用已考虑延迟问题, 则将该配置设置成 “yes”. 否则使用默认配置(“no”), 这是从耐久性角度考虑的最安全的选择.
no-appendfsync-on-rewrite no 

# aof 自动重写配置. 当目前 aof 文件大小超过上一次重写的 aof 文件大小的百分之多少进行重写,
# 即当 aof 文件增长到一定大小的时候 Redis 能够调用 bgrewriteaof 对日志文件进行重写.
# 当前 AOF 文件大小是上次日志重写得到 AOF 文件大小的二倍 (设置为 100) 时,
# 自动启动新的日志重写过程.
auto-aof-rewrite-percentage 100
# 设置允许重写的最小 aof 文件大小, 避免了达到约定百分比但尺寸仍然很小的情况还要重写
auto-aof-rewrite-min-size 64mb

# 设置 AOF 重写的触发条件.
# 当 AOF 日志按照指定的比例增长时, 可以通过调用 BGREWRITEAOF 执行自动的 AOF rewrite.
# 
# 工作原理: Redis 通过对比上一次执行 rewrite 时 AOF 文件的大小与当前 AOF 文件大小(在重启时将没有上一次执行 rewrite 的记录, 这时将使用 startup 时的 AOF 文件大小), 决定是否进行 rewrite.
# 如果当前 AOF 对于上一次执行 rewrite 的 AOF 文件的增长比率大于指定的比率, 将会触发一次 rewrite.
# 当然, 还需指定一个 AOF 进行重写的最小单位. 这样做可以避免增长比率已经达到要求, 但对应的 AOF 仍很小的情况 (这种情况下没有必要进行 rewrite) 的发生.
# 
# 如果想要关闭自动 AOF rewrite 功能, 可将进行 rewrite 要求的增长比率设置 0.
# 
# 默认当 AOF 大于 64MB 且相比于上一次 rewrite,AOF 以扩充了两倍时会触发一次 rewrite 执行. 默认配置如下:
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

# aof 文件可能在尾部是不完整的, 当 redis 启动的时候, aof 文件的数据被载入内存.
# 重启可能发生在 redis 所在的主机操作系统宕机后,
# 尤其在 ext4 文件系统没有加上 data=ordered 选项 (redis 宕机或者异常终止不会造成尾部不完整现象.)
# 出现这种现象, 可以选择让 redis 退出, 或者导入尽可能多的数据. 如果选择的是 yes,
# 当截断的 aof 文件被导入的时候, 会自动发布一个 log 给客户端然后 load.
# 如果是 no, 用户必须手动 redis-check-aof 修复 AOF 文件才可以.
aof-load-truncated yes

# 在将 AOF 文件加载到内存时(重启 Redis), 可能会出现 AOF 被截断的情况.
# 
# 如当 Redis 运行所在系统突然崩溃(当 ext4 文件系统在安装时没有配置成数据按序存储), 会出现 AOF 被截断情况.
# 如果 Redis 程序发生崩溃或异常, 但操作系统仍能正常工作, 则不会出现 AOF 被截断的情况.
# 
# 出现 AOF 被截断后, Redis 要么直接退出并返回错误, 要么加载被截断 AOF 中尽可能多的数据(当前默认方式).
# 可以通过 aof-load-truncated 选项进行配置:
# 当 aof-load-truncated 设置成 “yes”,Redis 仍会加载一个被截断的 AOF 文件, 同时向用户报告 AOF 文件被截断.
# 如果设置成 “no”,Redis 会直接返回错误并拒绝启动, 这时用户需要使用 "redis-check-aof" 程序修复 AOF, 只有这样才能重启 Server.
# 
# 注意, 如果 AOF 文件在执行一半时就出现问题, 即使设置 aof-load-truncated 为 “yes”,Redis 也会直接退出并返回错误.
# 这个配置仅在 Redis 尝试从 AOF 文件读更多数据但发现没有足够字计数存在时有意义.
aof-load-truncated yes

# 当重写 AOF 文件时, Redis 可以使用 RDB 文件作为 AOF 文件的前导, 这样可以更快地进行重写和恢复. 
# 当启用这个功能时 AOF 文件由两部分组成:
#
#   [RDB file][AOF tail]
#
# 当加载 AOF 文件时, Redis 通过以 “REDIS” 字符串开头的 AOF 文件识别出此文件是由 RDB 和 AOF 组合而成的,
# Redis 会先加载 RDB 部分, 然后再加载 AOF 部分.
aof-use-rdb-preamble yes

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

# 设置 Lua 脚本执超时的时间上限, 单位是毫秒, milliseconds.
#
# 当 Lua 脚本执行超时, Redis 会记录脚本执行之后的结果 (超时后) 并向查询返回错误.
# 当一个长时脚本执行时间超过最大执行时间时, 只有 SCRIPT KILL 和 SHUTDOWN NOSAVE 命令可用.
# 停止这类脚本运行的第一个方法是调用一个非写命令. 第二种方法是 shut down 这个 server, 如果已经发送了一个写命令但用户并不想等待脚本自然终止.
# 
# 如果想不限制脚本的执行时间并且不需要返回 warning, 可以将该参数设置成 0 或负数.
lua-time-limit 5000

################################ REDIS CLUSTER  ###############################

# 正常情况下, 启动的 Redis 实例为非集群模式. 只有当节点配置成集群模式时才能成为集群节点.
# 如需以集群模式启动, 取消下述配置的注释即可:
#
# cluster-enabled yes

# 集群配置文件的名称, 每个节点都有一个集群相关的配置文件, 持久化保存集群的信息.
# 这个文件并不需要手动配置, 这个配置文件有 Redis 生成并更新,
# 每个 Redis 集群节点需要一个单独的配置文件, 请确保与实例运行的系统中配置文件名称不冲突.
#
# cluster-config-file nodes-6379.conf

# 集群节点超时阈值用来作为节点不可达并被标记为失效状态的超时上限, 单位是毫秒(millisecond)
# 大部分其他内部时间将其基本参考数.
#
# cluster-node-timeout 15000

# 在进行故障转移的时候, 全部 slave 都会请求申请为 master,
# 但是有些 slave 可能与 master 断开连接一段时间了, 导致数据过于陈旧,
# 这样的 slave 不应该被提升为 master. 该参数就是用来判断 slave 节点与 master 断线的时间是否过长.
# 
# 没有简单的方式可以直接准确判定从节点的”data age”, 可以通过下面两个方面的检测实现:
# 
# 1) 如果有多个从节点可以发起故障转移, 可以让他们交换信息以选出数据状态最节点主节点的从节点.
# 从节点可以通过 offset 进行排名并通过该排名延迟发起故障转移的时机.
# 
# 2) 每个独立的从节点计算最近一次与主节点交互的时间.
# 这里的交互可以是最近一次 PING、最近一次接收到来自主节点的命令、与主节点断开连接的时间(当复制链接已经 down 掉时).
# 如果最近一次与主节点的交互已经足够久远, 那么这个从节点将放弃进行故障转移.
# 
# 在 2) 中的时间阈值可以由用户设定. 特别地, 当从节点的最近一次与主节点的交互远大于 (node-timeout * slave-validity-factor) + repl-ping-slave-period 时, 这个从节点将不会执行故障转移.
# 
# 例如假设 node-timeout 为 30 秒, slave-validity-factor 参数为 10,repl-ping-slave-period 为 10 秒, 当从节点距离最近一次与主节点的交互时间大于 310 秒 (30*10+10) 时, 该从节点不能进行故障转移.
# 
# 一个过大的从节点有效因子 (slave-validity-factor) 会允许存储过旧数据的从节点进行故障转移, 而一个过小的从节点有效因子将会妨碍集群选择从节点成为新的主节点.
# 所以合理的设置从节点有效因子很重要.
# 
# 为了获得最大的可用性, 可以将从节点有效因子 (slave-validity-factor) 赋值为 0.
# 也就是说, 从节点忽略距离最近一次与主节点交互的时间段, 则是直接点尝试发起故障转移.(但是这种策略下, 这些从节点仍会根据 offset 的排名来推迟发起故障转移的时间)
# 
# 从节点有效因子 (slave-validity-factor) 值为 0 是唯一可以保证网络分区消失后, 集群仍继续工作的值.
#
# cluster-replica-validity-factor 10

# Redis 集群支持将从节点迁移到孤立主节点(orphaned masters), 没有可以工作从节点的主节点.
# 该功能减少了集群孤立主节点故障但没有可工作从节点进行故障转移的情况的发生.
# 
# 从节点可以迁移到孤立主节点当且仅当原来的主节点的剩余可工作从节点个数大于等于指定的可工作从节点数.
# 这个数称为从节点迁移屏蔽因子(migration barrier).
# 当迁移屏蔽因子设置为 1 时, 当且仅当主节点拥有至少两个可工作的从节点才允许其中从节点迁移到孤立主节点(orphaned masters).
# 该因子通常用来表明使用者需要为集群中的主节点配置从节点个数.
# 
# 默认迁移屏蔽因子是 1(从节点可以执行迁移当前仅当其主节点在该节点迁移后仍保有至少一个从节点).
# 如果想关闭该功能, 只需将该参数设置成一个极大值即可.
# 允许将迁移屏蔽因子置零. 这种行为仅在调试时有用, 且在生产环境中存在极大风险.
# cluster-migration-barrier 1

# 默认情况下, Redis 集群将停止接收客户端请求 (停止服务) 当集群检测到存在哈希槽没有对应负责的节点.
# 也就是说, 如果集群部分 down(如有一部分哈希槽没有对应的节点), 整个集群最终将会不可用.(集群信息传播遵循最终一致性)
# 当所有的槽都再次有对应负责的节点后, 集群将会自动再次可用.
# 
# 但是有时希望即使集群只有部分槽有对应的节点, 集群也能继续接受客户端请求并处理对应的键空间.
# 为了达到上述目的, 将 ecluster-require-full-coverage 设置为 “no” 即可.
# cluster-require-full-coverage yes

# 这个选项用于控制 master 发生故障时是否自动进行 failover.
#
# 当设置为 yes 后 master 发生故障时不会自动进行 failover, 这时你可以进行手动的 failover 操作.
#
# cluster-replica-no-failover no

# In order to setup your cluster make sure to read the documentation
# available at http://redis.io web site.

########################## CLUSTER DOCKER/NAT support  ########################

# 在某些部署环境下, Redis 集群的节点地址不能被自动发现, 这是因为这些节点是部署在 NAT 网络或者端口是转发的 (典型的情况就是使用了 Docker 或者其他容器).
#
# 为了能让 Redis 集群工作在这种环境下, 我们需要进行相关配置让各个节点知道相互之间的外部地址,
# 这可以通过设置以下选项做到:
#
# * cluster-announce-ip: 表示节点的外部地址
# * cluster-announce-port: 表示节点的客户端口
# * cluster-announce-bus-port: 表示集群消息总线端口
#
# Each instruct the node about its address, client port, and cluster message
# bus port. The information is then published in the header of the bus packets
# so that other nodes will be able to correctly map the address of the node
# publishing the information.
#
# 若以上选项未配置, 则将会启用正常的 Redis 集群自动检测机制. 
# 若 bus port 未设置, 则会将其设置为 port + 10000.
#
# Example:
#
# cluster-announce-ip 10.1.1.5
# cluster-announce-port 6379
# cluster-announce-bus-port 6380

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

# Redis 慢日志系统用来记录执行时间较长的查询.
# 这里的执行时间 (“execution time”) 不包括 IO 操作时间, 如接收客户端的请求, 返回请求结果等,
# 而是实际执行命令的时间(此时线程处于阻塞状态, 仅能执行该命令, 不能同时处理其他请求).
# 
# 可以使用两个参数配置慢日志: 一个参数告知 Redis 执行时间超时阈值(单位是微秒, microseconds), 这样一旦某个执行时间超过指定上限, 将会被记录到慢日志中；
# 另一个参数是慢日志的长度. 慢日志使用环式结构存储超时命令.(当慢日志满后, 新命令添加进去后, 最老的命令将被踢出)
# 
# 单位是微秒(microsecon). 注意, 负数时间会禁用慢查询日志, 而 0 则会强制记录所有命令.
# 默认慢日志功能是开启的.
slowlog-log-slower-than 10000

# 慢查询日志长度. 当一个新的命令被写进日志的时候, 最老的那个记录会被删掉.
# 这个长度没有限制. 只要有足够的内存就行. 你可以通过 SLOWLOG RESET 来释放内存.
slowlog-max-len 128

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

# Redis 延迟监测自系统通过对执行期间的操作的检测来收集与延迟相关的数据.
# 
# 通过使用 LATENCY 命令, Redis 用户可以获得延迟相关的图形、报告等信息.
# 延迟系统只会记录大于等于设置的 latency-monitor-threshold 值的操作. 当该值为零时,
# 则表明关闭 latency monitor.
#
# 默认情况下, latency monitor 功能是关闭的, 因为大多数场景下并不需要该功能.
# latency monitor 可以在 Redis 运行时通过 "CONFIG SET latency-monitor-threshold <milliseconds>" 启动.
latency-monitor-threshold 0

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

# Redis 可以通知那些已 Pub/Sub 客户端键空间发生的事件.
# 
# 例如, 如果开启键空间通知功能且一个客户端对 0 号数据库上的 “foo”key 执行 DEL 操作, 那么 Redis 将使用 Pub/Sub 发送两条消息:
# PUBLISH __keyspace@0__:foo del
# PUBLISH __keyevent@0__:del foo
# 
# Redis 对通知的事件进行了分类, 每一类都使用唯一的字符标记:
#  K 	 键空间 (Key) 通知, 前缀为:__keyspace@<db>__ 
#  E     键事件 (Event) 通知, 前缀为:__keyevent@<db>__ 对于所有命令类型和非键事件, 均使用小写字母表示, 且没有前缀.
#  g     一般命令(Generic commands), 如 DEL, EXPIRE, RENAME 等
#  $     字符串 (String) 命令
#  l     列表 (list) 命令
#  s     集合 (set) 命令
#  h     哈希 (hash) 命令
#  z     有序集合 (sorted set) 命令
#  x     过期事件(过期键产生的事件)
#  e     驱逐事件(因 maxmemory 而驱逐的事件)
#  A     g$lshzxe 等类型的别称(Alias), 如此一来就可以使用 "AKE" 代表所有的事件类型
#
# notify-keyspace-events 可以指定多个字符组成的字符串或空串. 其中空串代表关闭通知功能.
# 
# 例 1: 为了开启 List 事件和 Genetic 事件(从事件名称分类来说), 可以使用如下设置:
# notify-keyspace-events Elg
# 
# 例 2: 为了获取过期键的信息并发送到订阅的频道, 即__keyevent@0__:expired use 信息, 可设置如下:
# notify-keyspace-events Ex
# 
# 默认情况下, 事件通知功能是关闭的, 因为大多数用户并不需要这个功能且这个功能会带来额外的性能开销.
# 注意, 如果没有指定键空间 (K) 通知还是键事件 (E) 通知, 那么任何事件通知都不会被传送.
notify-keyspace-events ""

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

# Hash 数据类型的底层实现有压缩链表 (ziplist) 和哈希表(hash).
# 当且仅当存储的数据量小于 hash-max-ziplist-entries 且节点占用的容量小于 hash-max-ziplist-value 时才使用小数据量存储高效的 ziplist 结构存储.
# 否则, 使用哈希结构存储.
hash-max-ziplist-entries 512
hash-max-ziplist-value 64

# List 类型也可以通过特殊的方式来节省空间.
# 每个内部 list 节点允许存储的 entries 数量可以指定为已修订最大数量或最大元素数.
# 如指定 - 5 到 - 1, 其含义是:
# -5: max size: 64 Kb  <-- 对于普通的工作负载, 不建议使用
# -4: max size: 32 Kb  <-- 不建议使用
# -3: max size: 16 Kb  <-- 有时不建议使用
# -2: max size: 8 Kb   <-- good
# -1: max size: 4 Kb   <-- good
# 整数代表每个 list 节点准确存储指定数量的 elements
# 最高效的参数设置是 - 2 (8 Kb size) 或 -1 (4 Kb size)
# 但是, 如果需求很特殊, 则应根据需要调整参数:
list-max-ziplist-size -2

# List 可以实现压缩.
#
# 压缩深度是划定 quicklist、ziplist 等 list 在压缩时的节点范围.
# 为了进行快速的 push/pop 操作, 不会对 list 的 head 和 tail 进行压缩, 只会对中间节点进行压缩.
# 
# 参数设置如下:
# 0: 关闭 list 压缩功能
# 1: 深度为 1 表示只有当 list 添加一个节点 (无论从 head 还是 tail 添加该节点) 后才开始进行压缩.
# 	 所以对于 [head]->node->node->...->node->[tail]
# 	 只有黑体部分加入才会执行压缩操作.
# 2: 深度为 2
# 	 对于链表:[head]->[next]->node->node->...->node->[prev]->[tail]
# 	 不会压缩 head 或 head->next 或 tail->prev 或 tail, 而仅压缩剩余部分.
# 3: 深度为 3
#  	 [head]->[next]->[next]->node->node->...->node->[prev]->[prev]->[tail]
list-compress-depth 0

# Set 数据类型的底层实现默认是 intSet, 也可以是 hash.
# Set 使用 hash 编码格式当且仅当字符串组成的 set 变成底数为 10 的整数, 且其值范围在 64 位整数中.
# 下面的配置设置用来指定 set 可以使用特殊编码格式的阈值:
set-max-intset-entries 512

# Sorted Set 默认使用 ziplist 实现, 也可通过 skiplist 编码实现来节省空间.
# 当且仅当 Sorted Set 中元素值大于 zset-max-ziplist-value、元素数量大于 zset-max-ziplist-entries 时, 才使用 skiplist 实现 Sorted Set.
zset-max-ziplist-entries 128
zset-max-ziplist-value 64

# value 大小小于等于 hll-sparse-max-bytes 使用稀疏数据结构 (sparse),
# 大于 hll-sparse-max-bytes 使用稠密的数据结构 (dense).
# 一个比 16000 大的 value 是几乎没用的, 建议的 value 大概为 3000.
# 如果对 CPU 要求不高, 对空间要求较高的, 建议设置到 10000 左右.
hll-sparse-max-bytes 3000

# HyperLogLog 稀疏表示阈值.
# 16 位的 header 部分也在 limit 中. 当使用稀疏表示的 HyperLogLog 存储的字节超过了指定的阈值, 它将转变成稠密表示.
# 不建议使用大于 16000 的值. 当小于 16000 时能够获得较高存储效率.
# 建议的值是 3000, 该值可以在较少 PFADD(在执行稀疏编码时时间复杂度是 O(N))操作执行的同时获得极高空间使用收益. 当 CPU 问题无需考虑时, 可将该值提升到 10000, 但其值不应超过 15000.
hll-sparse-max-bytes 3000

# Streams macro node max size / items. The stream data structure is a radix
# tree of big nodes that encode multiple items inside. Using this configuration
# it is possible to configure how big a single node can be in bytes, and the
# maximum number of items it may contain before switching to a new node when
# appending new stream entries. If any of the following settings are set to
# zero, the limit is ignored, so for instance it is possible to set just a
# max entires limit by setting max-bytes to 0 and max-entries to the desired
# value.
# 用于设定 Streams 单个节点的最大大小和最多能保存多个个元素.
stream-node-max-bytes 4096
stream-node-max-entries 100

# 激活的 rehash 会占用每 100 毫秒的 1 millisecond 的 CPU 时间来对 Redis hash table(存储数据库的键值对的 hash table)执行 rehash.
# 在 Redis 中 hash table 使用惰性 rehash: 在 rehashing 时, hash table 中执行的操作越多, rehash 执行的步骤也越多.
# 所以当 server 很空闲时, rehash 将很简单, hash table 也会有更多的内存可以使用.
# 
# 为了在条件许可的情况下对 hash table 进行 rehash, 从而节省内存空间, 默认情况下, rehash 功能会每 100 毫秒中 1 毫秒被调用一次.
# 
# 如果不确定:
# 使用 "activerehashing no" 如果当前应用环境很注重延迟、Redis 仅允许 2 毫秒的延迟应答.
# 使用 "activerehashing yes" 如果当前应用环境不是太注重延迟且想要尽可能块的释放内存空间.
activerehashing yes

# 客户端输出缓冲区可以用来强制断开那些不能够快速读取服务器数据的客户端连接.(如在 Pub/Sub 模式中, 客户端不能够快速的处理 publisher 发送过来的消息)
# 客户端类型可以细分为三类:
# 	normal -> 普通客户端(包括 MONITOR 客户端)
# 	slave  -> 从节点客户端
# 	pubsub -> 订阅至少一个 pubsub 通道或模式的客户端
# 
# client-output-buffer-limit 设置的通用格式如下:
# 	client-output-buffer-limit <class> <hard limit> <soft limit> <soft seconds>
# 
# 一旦 hard limit 达到, 客户端将直接断开连接. 如果 soft limit 达到, 客户端连接将会持续 soft seconds 后才断开连接.
# 
# 例如, 当 hard limit 是 32 MB(megabytes)、soft limit 在 10 秒内持续超过 16MB,
# 如果客户端输出缓冲区 (clients output buffer) 超过 32 MB 或客户客户端输出缓冲区 (clients output buffer) 超过 16MB, 并在接下来的 10 秒都高于 16MB, 客户端连接将马上断开.
# 
# 默认情况下, 不需对 normal 级别的 clients 进行约束因为这些客户端如果没有发起询问就不会接受数据.
# 所以, 只需对异步客户端进行约束因为异步客户端会出现请求速度大于 read 速度的情况.
# 
# 因为订阅者和从节点使用推的方式接受数据, 所以需要对 pubsub 客户端和 slave 客户端设置默认的客户端输出缓冲区约束.
# 将 hard limit 或 soft limit 置零表示关闭对应的功能.
client-output-buffer-limit normal 0 0 0
client-output-buffer-limit slave 256mb 64mb 60
client-output-buffer-limit pubsub 32mb 8mb 60

# 客户端查询缓冲区会累加新的命令. 
# 默认情况下, 他们会限制在一个固定的数量避免协议同步失效 (比如客户端的 bug) 导致查询缓冲区出现未绑定的内存.
# 但是, 如果有类似于巨大的 multi/exec 请求的时候可以修改这个值以满足你的特殊需求.
#
# client-query-buffer-limit 1gb

# 在 Redis 协议中, 批量请求通常限制在 512 mb 内, 可以通过修改 proto-max-bulk-len 选项改变这个限制.
#
# proto-max-bulk-len 512mb

# Redis 调用一个内部函数来执行后台任务, 如在 timeout 时关闭客户端连接, 清除从未被请求的过期键, 等等.
# 
# 虽然并不是所有的 tasks 都使用同样的频率执行, 但是 Redis 会根据指定的频率值来检测 tasks 的执行.
# 
# 默认设置的值为 10, 即每秒执行 10 次.
# 在 Redis 处于空闲提升该值时, 将会消耗更多的 CPU.
# 但是, 提升该值也会使 Redis 更精确的处理超时问题, 并检测到更多的过期键.
# 
# 该值设置范围是 1 到 500. 但是不建议将其设置大于 100.
# 大多数的用户建议使用默认的值(10), 并根据应用环境的低延迟需求适当提升该值(峰值建议不要大于 100).
hz 10

# 通常来说根据连接上来的客户端数量对 HZ 的值按比例进行调整是有用的.
# 这很有用, 例如, 为了避免每次后台任务处理太多的客户端, 从而避免高延迟峰值.
#
# 默认情况下 HZ 的值为 10, 启用 dynamic-hz 后, 当有大量客户端连接进来时 HZ 的值会临时性地调高.
#
# 启用 dynamic-hz 后, HZ 的配置值将作为基线, 当有大量的客户端连接进来时, Redis 会将 HZ 的实际值设置为 HZ 的配置值的整数倍.
# 通过这种方式, 空闲的 Redis 实例只会占用非常小的 CPU 时间, 当实例变得繁忙时 Redis 能更快地进行响应(相对未启用 dynamic-hz 的情况).
dynamic-hz yes

# 当子进程进行 AOF 的重写时, 如果启用了 aof-rewrite-incremental-fsync, 子进程会每生成 32 MB 数据就进行一次 fsync 操作.
# 通过这种方式将数据分批提交到硬盘可以避免高延迟峰值.
aof-rewrite-incremental-fsync yes

# 当 Redis 保存 RDB 文件时, 如果启用了 rdb-save-incremental-fsync 功能, Redis 会每生成 32 MB 数据就执行一次 fsync 操作. 
# 通过这种方式将数据分批提交到硬盘可以避免高延迟峰值.
rdb-save-incremental-fsync yes

# Redis LFU eviction (see maxmemory setting) can be tuned. However it is a good
# idea to start with the default settings and only change them after investigating
# how to improve the performances and how the keys LFU change over time, which
# is possible to inspect via the OBJECT FREQ command.
#
# There are two tunable parameters in the Redis LFU implementation: the
# counter logarithm factor and the counter decay time. It is important to
# understand what the two parameters mean before changing them.
#
# The LFU counter is just 8 bits per key, it's maximum value is 255, so Redis
# uses a probabilistic increment with logarithmic behavior. Given the value
# of the old counter, when a key is accessed, the counter is incremented in
# this way:
#
# 1. A random number R between 0 and 1 is extracted.
# 2. A probability P is calculated as 1/(old_value*lfu_log_factor+1).
# 3. The counter is incremented only if R < P.
#
# The default lfu-log-factor is 10. This is a table of how the frequency
# counter changes with a different number of accesses with different
# logarithmic factors:
#
# +--------+------------+------------+------------+------------+------------+
# | factor | 100 hits   | 1000 hits  | 100K hits  | 1M hits    | 10M hits   |
# +--------+------------+------------+------------+------------+------------+
# | 0      | 104        | 255        | 255        | 255        | 255        |
# +--------+------------+------------+------------+------------+------------+
# | 1      | 18         | 49         | 255        | 255        | 255        |
# +--------+------------+------------+------------+------------+------------+
# | 10     | 10         | 18         | 142        | 255        | 255        |
# +--------+------------+------------+------------+------------+------------+
# | 100    | 8          | 11         | 49         | 143        | 255        |
# +--------+------------+------------+------------+------------+------------+
#
# NOTE: The above table was obtained by running the following commands:
#
#   redis-benchmark -n 1000000 incr foo
#   redis-cli object freq foo
#
# NOTE 2: The counter initial value is 5 in order to give new objects a chance
# to accumulate hits.
#
# The counter decay time is the time, in minutes, that must elapse in order
# for the key counter to be divided by two (or decremented if it has a value
# less <= 10).
#
# The default value for the lfu-decay-time is 1. A Special value of 0 means to
# decay the counter every time it happens to be scanned.
#
# lfu-log-factor 10
# lfu-decay-time 1

########################### ACTIVE DEFRAGMENTATION #######################
#
# 警告: 这个功能是实验性的. 当然此功能已经在包括生产环境在内的环境中通过压力测试. 
# 并且被多名工程师手工测过一段时间.
#
# What is active defragmentation?
# -------------------------------
#
# 活动碎片整理允许 Redis 服务器压缩内存中由于申请和释放数据块导致的碎片, 从而回收内存. 
# 碎片是每次申请内存 (幸运的是 Jemalloc 出现碎片的几率小很多) 的时候会自然发生的. 
# 通常来说, 为了降低碎片化程度需要重启服务, 或者至少需要清除所有的数据然后重新创建. 
# 得益于 Oran Agra 在 Redis 4.0 实现的这个特性, 进程可以在服务运行时以 “热” 方式完成这些目的.
#
# 通常来说当碎片化达到一定程度(查看下面的配置)Redis 会使用 Jemalloc 的特性创建连续的内存空间, 
# 并在此内存空间对现有的值进行拷贝, 拷贝完成后会释放掉旧的数据. 
# 这个过程会对所有的导致碎片化的 key 以增量的形式进行.
#
# 需要重点理解的是: 
# 1. 这个特性默认是关闭的, 并且只有在编译 Redis 时使用我们代码中的 Jemalloc 版本才生效.(这是 Linux 下的默认行为)
# 2. 如果没有碎片问题, 你永远不需要启用这项特性 
# 3. 如果你需要试验这项特性, 可以通过命令 CONFIG SET activefrag yes 来启用
#
# 相关的配置参数可以很好的调整碎片整理过程. 如果你不知道这些选项的作用最好使用默认值.

# 启用碎片整理.
# activedefrag yes

# 有至少多少碎片时才开始碎片整理.
# active-defrag-ignore-bytes 100mb

# 有至少多少比例的碎片时才开始碎片整理.
# active-defrag-threshold-lower 10

# 有多少比例的碎片时才开始以最大努力进行碎片整理.
# active-defrag-threshold-upper 100

# 进行碎片整理时至少使用多少比例的 CPU 时间.
# active-defrag-cycle-min 5

# 最大努力进行碎片整理时使用多少 CPU 时间.
# active-defrag-cycle-max 75

# 进行主字典扫描时处理的 set/hash/zset/list 字段的最大数量
# (就是说在进行主字典扫描时 set/hash/zset/list 的长度小于这个值才会处理, 大于这个值的会放在一个列表中延迟处理).
# active-defrag-max-scan-fields 1000

---

参考博文

[1]. Redis 配置文件 redis.conf
[2]. Redis 命令
[3]. 阿里云 Redis 开发规范

---

Redis 深度探险系列

• Redis 深度探险（一）：那些绕不过去的 Redis 知识点
• Redis 深度探险（二）：Redis 深入之道
• Redis 深度探险（三）：Redis 单机环境搭建以及配置说明
• Redis 深度探险（四）：Redis 高可用性解决方案之哨兵与集群

---