Redis 配置文件解读
+ 默认配置打开，- 默认配置关闭
# network 网络
# + bind
# 绑定IP
bind 127.0.0.1
2
默认是 127.0.0.1，修改的 IP 如果不为本机 IP 是无法启动的。可以直接注释 bind，这样所有机器可连，但会受 protected-mode 参数影响。
# + protected-mode
# 受保护的 默认开启
protected-mode yes
2
保护模式下，无论 bind 是否被注释都无法远程访问。想允许外网或局域网访问需要关闭保护模式，且注释 bind。
# + port
### 端口默认
port 6379
2
# + tcp-backlog
tcp-backlog 511
Linux 内核为每个 TCP 服务器程序维护两条 backlog 队列，一条是 TCP 层的未连接队列，一条是应用层的已连接队列，分别对应 net.ipv4.tcp_max_syn_backlog 和 net.core.somaxconn 两个内核参数。
一个客户端连接在完成 TCP 3 次握手之前首先进入到未连接队列，完成握手之后正式建立连接，进入已连接队列，交付给应用程序处理。应用程序调用 accept () 函数从已连接队列取出连接进行处理。应用层在调用 listen () 函数时指定的 backlog 是已连接队列大小，如果大于 somaxconn 将被设为 somaxconn。
如果应用层不调用 accept () 函数处理一个连接，或者处理不及时的话，将会导致已连接队列堆满。已连接队列已满的话会导致未连接队列在处理完 3 次握手之后无法进入已连接队列，最终也导致未连接队列堆满，在服务器看到处于未连接队列中的连接状态为 SYN_RECV。 新进来的客户端连接将会一直处于 SYN_SENT 状态等待服务器的 ACK 应答，最终导致连接超时。
# 查看队列大小
查看未连接队列默认值：
cat /proc/sys/net/ipv4/tcp_max_syn_backlog
查看已连接队列默认值：
cat /proc/sys/net/core/somaxconn
# 修改队列大小
可以直接改写这两个文件的值。要永久修改这两个内核参数的话可以写到 /etc/sysctl.conf
net.ipv4.tcp_max_syn_backlog = 1024
net.core.somaxconn = 1024
2
改完后执行 sysctl -p 让修改立即生效。
# timeout
timeout 0
客户端闲置 N 秒后关闭连接（0 禁用）
# tcp-keepalive
tcp-keepalive 300
向客户端发送 TCP ACK 检测连接是否断开，保证连接活跃。单位秒，默认 300 秒发送一次，如果等于 0 就是禁用。
# general 一般
# daemonize
daemonize no
默认情况下，Redis 不会作为守护程序运行。如果需要，请设置为 yes。请注意，Redis 守护进程将在 /var/run/redis.pid 中写入一个 pid 文件。
# supervised
supervised 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 回复。
# pidfile
pidfile /var/run/redis_6379.pid
当 Redis 服务器已守护进程启动时，如果指定了配置文件，则直接使用，如果没有指定，则创建 /var/run/redis.pid 作为配置文件。
# loglevel
loglevel notice
指定服务器的 verbosity 级别。Redis 提供四种级别：
- debug 包含大量信息，用于开发和测试
- verbose 包含一些稀有的有用信息，但没有 debug 级别混乱
- notice 适量提示信息，用于生产环境
- warning 只包含非常重要和关键的信息
# logfile
logfile ""
指定日志文件名称。指定为空时将输出到标准输出设备中。如果 Redis 以守护进程启动，当日志文件名称为空时，日志将会输出到 /dev/null。
# databases
databases 16
设置数据库的数量。默认使用 0 号数据库。可以在每一个连接上使用 SELECT <dbid> 来指定另外的数据库，但是这个值必须在 0 到 database -1 之间。
# always-show-logo
always-show-logo yes
redis 启动的时候显示 日志。
# snapshotting 快照
# save
save 900 1
save 300 10
save 60 10000
2
3
过了 900 秒并且有 1 个 key 发生了改变，触发 save 动作
过了 300 秒并且有 10 个 key 发生了改变，触发 save 动作
过了 60 秒并且至少有 10000 个 key 发生了改变，触发 save 动作
# stop-writes-on-bgsave-error
stop-writes-on-bgsave-error yes
默认值为 yes。当启用了 RDB 且最后一次后台保存数据失败，Redis 是否停止接收数据。这会让用户意识到数据没有正确持久化到磁盘上，否则没有人会注意到灾难（disaster）发生了。如果 Redis 重启了，那么又可以重新开始接收数据了
# rdbcompression
rdbcompression yes
默认值是 yes。对于存储到磁盘中的快照，可以设置是否进行压缩存储。如果是的话，redis 会采用 LZF 算法进行压缩。如果你不想消耗 CPU 来进行压缩的话，可以设置为关闭此功能，但是存储在磁盘上的快照会比较大。
# rdbchecksum
rdbchecksum yes
在存储快照后，我们还可以让 redis 使用 CRC64 算法来进行数据校验，但是这样做会增加大约 10% 的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能。
# dbfilename
dbfilename dump.rdb
rdb 文件得文件名称
# rdb-del-sync-files
rdb-del-sync-files no
rdb 文件是否删除同步锁
dir ./
设置 rdb 文件存放得路径
# 创建 rdb 文件机制
fork 出一个子进程来处理，它和父进程共享内存里面的代码段和数据段。这时你可以把父子进程想象成一个连体婴儿，他们在共享身体。这就是 Linux 操作系统的机制，为了节约内存资源，所以尽可能让他们共享起来。在进程分离的一瞬间，内存的增长几乎没有明显变化。
子进程做数据持久化，不会修改现有的内存数据结构，它只是对数据结构进行遍历读取，然后序列化到磁盘中。但是父进程不一样，它必须持续服务客户请求，然后堆内存数据结构进行不间断的修改。
这个时候就会使用操作系统的 COW (copy on write) 机制来进行数据段页面的分离。数据段是由很多操作系统的页面组合而成，当父进程对其中一个页面的数据进行修改时，会将被共享的页面复制一份分离出来，然后对这个复制的页面进行修改。这时子进程相应的页面是没有变化的，还是进程产生那一瞬间的数据。
随着父进程修改操作的持续进行，越来越多的共享页面被分离出来，内存就会持续增长，但是也不会超过原有数据内存的 2 倍大小。另外，Redis 实例里冷数据占的比例往往是比较高的，所以很少会出现所有的页面都被分离的情况，被分离的往往只有其中一部分页面。每个页面的大小只有 4KB，一个 Redis 实例里面一般都会有成千上万个页面。
子进程因为数据没有变化，它能看到内存里的数据在进程产生的一瞬间就凝固了，再也不会改变，这也时为什么 redis 的持久化叫 快照 的原因。接下来子进程就可以非常安心地便利数据，进行序列化磁盘了。
# replication 主从复制
# replica-serve-stale-data
replica-serve-stale-data yes
当一个 slave 与 master 失去联系时，或者复制正在进行的时候，slave 应对请求的行为:
- 如果为 yes（默认值），slave 仍然会应答客户端请求，但返回的数据可能是过时，或者数据可能是空的在第一次同步的时候
- 如果为 no ，在你执行除了 info 和 salveof 之外的其他命令时，slave 都将返回一个 "SYNC with master in progress" 的错误。
# replica-read-only
replica-read-only yes
设置 slave 是否是只读的。从 2.6 版起，slave 默认是只读的
# repl-diskless-sync
repl-diskless-sync no
主从数据复制是否使用无硬盘复制功能。
# repl-diskless-sync-delay
repl-diskless-sync-delay 5
无磁盘 (diskless) 方式在进行数据传递之前会有一个时间的延迟，以便 slave 端能够进行到待传送的目标队列中，这个时间默认是 5 秒
# repl-diskless-load
repl-diskless-load disabled
# repl-disable-tcp-nodelay
repl-disable-tcp-nodelay no
是否启用 TCP_NODELAY，如果启用则会使用少量的 TCP 包和带宽去进行数据传输到 slave 端，当然速度会比较慢；如果不启用则传输速度比较快，但是会占用比较多的带宽。
# replica-priority
replica-priority 100
当 master 不能正常工作的时候，Redis Sentinel 会从 slaves 中选出一个新的 master，这个值越小，就越会被优先选中，但是如果是 0 ， 那是意味着这个 slave 不可能被选中。 默认优先级为 100。
# - keys tracking 键追踪
tracking-table-max-keys 1000000
# security 安全
# + acllog-max-len
acllog-max-len 128
# - aclfile
aclfile /etc/redis/users.acl
# - requirepass
requirepass foobared
# - rename-command
rename-command CONFIG ""
# clients 客户
# maxclients
maxclients 10000
设置最大连接客户端数。默认情况下，此限制设置为 10000 个客户端，但是，如果 Redis 服务器无法将进程文件限制配置为允许指定的限制，则允许的最大客户端数将设置为当前文件限制减去 32（因为 Redis 保留了内部使用的文件描述符很少）
达到限制后，Redis 将关闭所有新连接，并发送错误消息 “已达到最大客户端数。
当使用 Redis Cluster 时，最大连接数也会与集群总线共享：集群中的每个节点将使用两个连接，一个进入，另一个向外。对于非常大的集群，重要的是相应地调整限制大小。
# memory management 内存管理
# maxmemory
maxmemory <bytes>
将内存使用限制设置为指定的字节数。当达到内存限制时，Redis 将尝试根据所选的策略来删除 key（请参见 maxmemory-policy）。
如果 Redis 无法根据该策略删除 key，或者如果该策略设置为 'noeviction'，则 Redis 将开始对将使用更多内存的命令（例如 SET，LPUSH 等）进行错误答复，并将继续答复诸如 GET 之类的只读命令。(不支持写，只支持读)
如果是主从复制，建议您为 maxmemory 设置一个下限，以便系统上有一些可用内存用于 ‘从’ 输出缓冲区（但是如果策略为 'noeviction'，则不需要这样做）。
# maxmemory-policy
maxmemory-policy noeviction
maxmemory 策略：达到 maxmemory 时，Redis 将如何选择要删除的内容。您可以从以下行为中选择一种：
- volatile-lru：利用 LRU 算法移除过期 keys。
- allkeys-lru：利用 LRU 算法移除 keys。
- volatile-random：随机移除过期 keys。
- allkeys-random：随机移除 keys。
- volatile-ttl：按照最近过期时间来删除（辅以 TTL），移除即将过期的 keys。
- noeviction：不移除任何 key，只是返回一个写错误。
# maxmemory-samples
maxmemory-samples 5
Redis 中的 LRU 不是严格意义上的 LRU 算法实现，是一种近似的 LRU 实现，主要是为了节约内存占用以及提升性能。
Redis 的 LRU 是取出 配置的数目的 key (5)，然后从中选择一个最近最不经常使用的 key 进行置换。
对 LRU 来说 5 是比较合适的。10 已经很接近于真正的 LRU，但会消耗更多的 CPU。3 会更快但没有那么精确。
# replica-ignore-maxmemory
replica-ignore-maxmemory yes
从 Redis 5 开始，默认情况下，replica 节点会忽略 maxmemory 设置（除非在发生 failover 后，此节点被提升为 master 节点）。 这意味着只有 master 才会执行过期删除策略，并且 master 在删除键之后会对 replica 发送 DEL 命令。
这个行为保证了 master 和 replicas 的一致性，并且这通常也是你需要的，但是若你的 replica 节点是可写的， 或者你希望 replica 节点有不同的内存配置，并且你确保所有到 replica 写操作都幂等的，那么你可以修改这个默认的行为 （请确保你明白你在做什么）。
需要注意的是默认情况下 replica 节点不会执行过期策略，它有可能使用了超过 maxmemory 设定的值的内存。 因此你需要监控 replicas 节点所在的机器并且确保在 master 节点到达配置的 maxmemory 大小时， replicas 节点不会超过物理内存的大小。
# active-expire-effort
active-expire-effort 1
# lazy freeing 懒惰释放
lazy free 应用于被动删除中，目前有 4 种场景，每种场景对应一个配置参数； 默认都是关闭。
lazyfree-lazy-eviction no
lazyfree-lazy-expire no
lazyfree-lazy-server-del no
replica-lazy-flush no
2
3
4
# lazyfree-lazy-eviction
针对 redis 内存使用达到 maxmeory，并设置有淘汰策略时；在被动淘汰键时，是否采用 lazy free 机制；
因为此场景开启 lazy free, 可能使用淘汰键的内存释放不及时，导致 redis 内存超用，超过 maxmemory 的限制。此场景使用时，请结合业务测试。
# lazyfree-lazy-expire
针对设置有 TTL 的键，达到过期后，被 redis 清理删除时是否采用 lazy free 机制；
此场景建议开启，因 TTL 本身是自适应调整的速度。
# lazyfree-lazy-server-del
针对有些指令在处理已存在的键时，会带有一个隐式的 DEL 键的操作。rename 命令当目标键已存在，redis 会先删除目标键，如果这些目标键是一个 big key, 那就会引入阻塞删除的性能问题。 此参数设置就是解决这类问题，建议可开启。
# slave-lazy-flush
针对 slave 进行全量数据同步，slave 在加载 master 的 RDB 文件前，会运行 flushall 来清理自己的数据场景，参数设置决定是否采用异常 flush 机制。如果内存变动不大，建议可开启。可减少全量同步耗时，从而减少主库因输出缓冲区爆涨引起的内存使用增长。
# lazyfree-lazy-user-del
对于不容易用 UNLINK 调用替换用户代码 DEL 调用的情况，也可以使用 lazyfree-lazy-user-del yes 配置指令将 DEL 命令的默认行为修改为与 UNLINK 完全相同。
# threaded I/O 线程
默认情况下，线程是禁用的，我们建议仅在具有至少 4 个或更多内核的计算机上启用它，而至少保留一个备用内核。使用 8 个以上的线程不太可能有很大帮助。我们还建议在确实存在性能问题时再使用线程 I / O，Redis 实例会使用很大一部分 CPU 时间，否则就没有必要使用此功能。
io-threads 4
因此，如果您有四个核的，请尝试使用 2 或 3 个 I / O 线程，如果您有 8 个核，请尝试使用 6 个线程。
# io-threads-do-reads
io-threads-do-reads no
通常，将 io-threads 设置为 1 只会使用主线程。启用 I / O 线程后，我们仅将线程用于写操作，即对 write 系统调用进行线程化，并将客户端缓冲区传输到套接字。但是，也可以通过 io-threads-do-reads yes 来启用读取线程和协议解析。通常，线程读取没有太大帮助。
无法在运行时通过 CONFIG SET 更改此配置指令。启用 SSL 时，Aso 此功能当前不起作用。
# kernel oom control 内核 oom 控制
这个 oom-score-adj 参数是用来 Linux 内核控制调优的，在 Linux 系统中，当内存溢出时，可以提示内核 OOM killer 应该首先杀死哪些进程。
oom-score-adj no
启用此功能可使 Redis 根据其进程主动控制其所有进程的 oom_score_adj 值。默认分数将尝试使后台子进程在所有其他进程之前被杀死，而 replicas 在主数据库之前被杀死。
oom-score-adj-values 0 200 800
默认 oom-score-adj-values 不设置的情况下会优先杀死后台子进程，然后主从节点优先优先杀死从节点。
所以这 3 个值分别用来设置主、从、后台子进程的分值的，分值范围从 -1000 ~ 1000，分值越高越有可能被先杀死。
# append only mode AOF 追加模式
Redis 可以实现数据的持久化存储，即将数据保存到磁盘上。
Redis 的持久化存储提供两种方式：RDB 与 AOF。RDB 是默认配置。AOF 需要手动开启。
现在 Redis 的配置中默认是关闭 AOF 模式的。
# appendonly
appendonly no
是否开启 AOF
# appendfilename
appendfilename "appendonly.aof"
保存数据的 AOF 文件名称
# appendfsync
# appendfsync always
appendfsync everysec
# appendfsync no
2
3
Redis 支持 3 种不同的模式：
- no：不即时同步，由操作系统控制何时刷写到磁盘上，这种模式速度最快；
- always：每次只写日志，速度较慢，但最安全；
- everysec：每秒钟同步一次，折中的方案。
# no-appendfsync-on-rewrite
no-appendfsync-on-rewrite no
当使用 AOF 的 appendfsync 设置为 always 或 everysec 时，后台的存储进程会执行大量的磁盘 I/O 操作，在一些 Linux 架构中，Redis fsync () 调用时可能会阻塞很久。这个问题当前并没有修复，即使是在一个不同的线程执行 fsync 也会阻塞我们的同步写调用。
为了缓解这个问题，可以使用以下选项，它将会在有一个 BGSAVE 或 BGREWRITEAOF 正在运行时，阻止主进程调用 fsync ()。
这意味着有另一个子进程在存储时，Redis 的持久性等同于 appendfsync no。在实践中，意味着在最坏的情况下它可能丢失多达 30 秒的日志（默认的 Linux 设置）。
如果你有潜在的问题需要更改它为 “yes”。否则从持久性的观点来看 “no” 是最安全的选择。
# auto-aof-rewrite-percentage auto-aof-rewrite-min-size
auto-aof-rewrite-percentage 100
aof 文件增长比例，指当前 aof 文件比上次重写的增长比例大小。aof 重写即在 aof 文件在一定大小之后，重新将整个内存写到 aof 文件当中，以反映最新的状态 (相当于 bgsave)。这样就避免了，aof 文件过大而实际内存数据小的问题 (频繁修改数据问题).
# auto-aof-rewrite-min-size
auto-aof-rewrite-min-size 64mb
aof 文件重写最小的文件大小，即最开始 aof 文件必须要达到这个文件时才触发，后面的每次重写就不会根据这个变量了 (根据上一次重写完成之后的大小). 此变量仅初始化启动 redis 有效。如果是 redis 恢复时，则 lastSize 等于初始 aof 文件大小。
# rewrite 机制
其实 Redis oaf 机制包括了两件事，rewrite 和 AOF。rewrite 类似于普通数据库管理系统日志恢复点，当 AOF 文件随着写命令的运行膨胀时，当文件大小触碰到临界时，rewrite 会被运行。
rewrite 会像复制一样，fork 出一个子进程，创建一个临时文件，遍历数据库，将每个 key、value 对输出到临时文件。输出格式就是 Redis 的命令，但是为了减小文件大小，会将多个 key、value 对集合整理用一条命令表达。在 rewrite 期间的写操作会保存在内存的 rewrite buffer 中，rewrite 成功后这些操作也会复制到临时文件中，在最后临时文件会代替 AOF 文件。
简单来说：aof 里存放了所有的 redis 操作指令，当 aof 文件达到一定条件或者手动 bgrewriteaof 命令都可以触发 rewrite。rewrite 之后 aof 文件会保存 keys 的最后的状态，清除掉之前冗余的，来缩小这个文件。这里所谓的缩小就是 整理指令 ，比如客户端发送过三个命令：
lpush key 1 2 3
# 移出左边第一个元素，也就是把上面的元素 1 移出
lpop key
lpush key 4 5 6
2
3
4
整理后的指令文件是
lpush key 4 5 6 2 3
# aof-load-truncated
aof-load-truncated yes
指 redis 在恢复时，会忽略最后一条可能存在问题的指令。默认值 yes。即在 aof 写入时，可能存在指令写错的问题 (突然断电，写了一半)，这种情况下，yes 会 log 并继续，而 no 会直接恢复失败.
# aof-use-rdb-preamble
aof-use-rdb-preamble yes
混合持久化同样也是通过 bgrewriteaof 完成的，不同的是当开启混合持久化时，fork 出的子进程先将共享的内存副本全量的以 RDB 方式写入 aof 文件，然后在将重写缓冲区的增量命令以 AOF 方式写入到文件，写入完成后通知主进程更新统计信息，并将新的含有 RDB 格式和 AOF 格式的 AOF 文件替换旧的的 AOF 文件。简单的说：新的 AOF 文件前半段是 RDB 格式的全量数据后半段是 AOF 格式的增量数据。
# lua scripting lua 脚本
Redis 提供了 Lua 脚本功能来让用户实现自己的原子命令，但也存在着风险，编写不当的脚本可能阻塞线程导致整个 Redis 服务不可用。
lua-time-limit 5000
Redis 的配置文件中提供了如下配置项来规定最大执行时长。
但这里有个坑，当一个脚本达到最大执行时长的时候，Redis 并不会强制停止脚本的运行，仅仅在日志里打印个警告，告知有脚本超时。
因为 Redis 必须保证脚本执行的原子性，中途停止可能导致内存的数据集上只修改了部分数据。
如果时长达到 Lua-time-limit 规定的最大执行时间，Redis 只会做这几件事情：
- 日志记录有脚本运行超时
- 开始允许接受其他客户端请求，但仅限于 SCRIPT KILL 和 SHUTDOWN NOSAVE 两个命令
- 其他请求仍返回 busy 错误
# - cluster 集群
cluster-enabled yes
开启集群模式
cluster-config-file nodes-6379.conf
1、这个配置文件不是要我们去配的，而是 Redis 运行时保存配置的文件，所以我们也不可以修改这个文件。
2、Redis 集群节点每次发生更改时自动保留集群配置（基本上为状态）的文件，以便能够 在启动时重新读取它。
3、该文件列出了集群中其他节点，它们的状态，持久变量等等信息。 由于某些消息的接收，通常会将此文件重写并刷新到磁盘上。
4、生成的文件在 dir 指定路径下
cluster-node-timeout 15000
超时时间是集群中各节点相互通讯时，允许 "失联" 的最大毫秒数，上面的配置为 15 秒，如果超过 15 秒某个节点没向其它节点汇报成功，认为该节点挂了。
cluster-replica-validity-factor 10
1、如果设置为 0，无论主节点和从节点之间的链路断开连接的时间长短，从节点都将尝试故障切换为主节点。
2、 如果该值为正值，则计算最大断开时间作为节点超时值乘以此选项提供的系数，如果该节点是从节点，则在主链路断开连接的时间超过指定的超时值时，它不会尝试启动故障切换。 例如，如果节点超时设置为 5 秒，并且有效因子设置为 10，则与主节点断开连接超过 50 秒的从节点将不会尝试对其主节点进行故障切换。
3、请注意，如果没有从服务器节点能够对其进行故障转移，则任何非零值都可能导致 Redis 集群在主服务器出现故障后不可用。 在这种情况下，只有原始主节点重新加入集群时，集群才会返回可用。
cluster-migration-barrier 1
主节点将保持连接的最小从节点数量，以便另一个从节点迁移到不受任何从节点覆盖的主节点。
cluster-require-full-coverage yes
当 cluster-require-full-coverage 为 no 时，表示当负责一个插槽的主库下线且没有相应的从库进行故障恢复时，集群仍然可用。
当 cluster-require-full-coverage 为 yes 时，表示当负责一个插槽的主库下线且没有相应的从库进行故障恢复时，集群不可用。
cluster-replica-no-failover no
设置为 yes 时，此选项可防止从服务器在主服务器故障期间尝试对主服务器进行故障转移。但是，主服务器仍然可以执行手动故障转移（如果被迫执行）。
cluster-allow-reads-when-down no
默认为 no, 表示当集群因主节点数量达不到最小值或有散列槽没有分配而被标记为失效时，节点将停止所有的客户端通讯。 这样可以避免从一个不知道集群状态变化的节点读到不一致数据的危险。 设为 yes 则允许集群失效时仍可以由节点中读取数据。 这样既保证读操作的高可用性， 也避免不一致写操作，同时当 Redis Cluster 仅包含 1 至 2 个节点，而某个节点失效后无可用从节点替代，且因节点数量不足，无法自动重新分配散列槽，则该参数设为 yes 可保证节点仍然可执行读操作。
# slow log 慢日志
slowlog-log-slower-than 1000
其中 slowlog-log-slower-than 表示 slowlog 的划定界限，只有 query 执行时间大于 slowlog-log-slower-than 的才会定义成慢查询，才会被 slowlog 进行记录。slowlog-log-slower-than 设置的单位是微妙，默认是 10000 微妙，也就是 10ms
slowlog-max-len 128
slowlog-max-len 表示慢查询最大的条数，当 slowlog 超过设定的最大值后，会将最早的 slowlog 删除，是个 FIFO 队列
# latency monitor 延迟监视器
latency-monitor-threshold 0
redis 延时监控系统在运行时会采样一些操作，以便收集可能导致延时的数据根源。
通过 LATENCY 命令 可以打印一些图样和获取一些报告，方便监控
这个系统仅仅记录那个执行时间大于或等于预定时间（毫秒）的操作，
这个预定时间是通过 latency-monitor-threshold 配置来指定的，
当设置为 0 时，这个监控系统处于停止状态
# event notification 事件通知
notify-keyspace-events ""
# advanced config 高级配置
当哈希条目只有少量条目且最大条目未超过给定阈值时，将使用内存高效的数据结构对其进行编码
hash-max-ziplist-entries 512
数据量小于等于 hash-max-ziplist-entries 的用 ziplist，大于 hash-max-ziplist-entries 用 hash
hash-max-ziplist-value 64
value 大小小于等于 hash-max-ziplist-value 的用 ziplist，大于 hash-max-ziplist-value 用 hash。