Redis学习(二)：Redis的配置文件详解

# Redis配置说明
#
# Note that in order to read the configuration file, Redis must be
# started with the file path as first argument:
#
# ./redis-server /path/to/redis.conf

# Note on units: when memory size is needed, it is possible to specify
# it in the usual form of 1k 5GB 4M and so forth:
#
# 1k => 1000 bytes
# 1kb => 1024 bytes
# 1m => 1000000 bytes
# 1mb => 1024*1024 bytes
# 1g => 1000000000 bytes
# 1gb => 1024*1024*1024 bytes
#
# units are case insensitive so 1GB 1Gb 1gB are all the same.

################################## INCLUDES ###################################
#### 这在你有标准配置模板但是每个redis服务器又需要个性设置的时候很有用。
# include /path/to/local.conf
# include /path/to/other.conf


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


################################
# bind 192.168.1.100 10.0.0.1
# bind 127.0.0.1 ::1
#### 默认情况,如果没有bind配置,Redis服务端会监听外界所有的可用的连接。如果可以的话,最好
#### 用bind配置一个或多个确定的地址。
# bind 127.0.0.1


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


################################
#### 监听端口
port 6379


#################################
#### 此参数确定了TCP连接中已完成队列(完成三次握手之后)的长度,此值必须不大于linux系统定义的
#### /proc/sys/net/core/somaxconn值,默认是511,而linux的默认参数值是128,当系统并发量并且客户端
#### 速度缓慢的时候,可以将这两个参数一起参考设定,该内核参数默认值一般是128,对于负载很大的程序来说
#### 不能满足,一般会将它修改为2048或者更大,在/etc/sysctl.conf中添加：net.core.somaxconn=2048,然后
#### 使用：sysctl -p使该设定生效
tcp-backlog 511


###############################
#### redis的unix socket路径 
# unixsocket /tmp/redis.sock
# unixsocketperm 700


###############################
#### 当一个redis-client一直没有请求发向server端，那么server端有权主动关闭这个连接，可以通过timeout来设置“空闲超时时限”，0表示永不关闭。
timeout 0


###############################
#### TCP 心跳包
#### TCP连接保活策略，可以通过tcp-keepalive配置项来进行设置，单位为秒.
#### 假如设置为60秒，则server端会每60秒向连接空闲的客户端发起一次ACK请求，以检查客户端是否已经挂掉，对于无响应的客户端则会关闭其连接。
#### 所以关闭一个连接最长需要120秒的时间。如果设置为0，则不会进行保活检测。
#### 推荐一个合理的值就是60秒
tcp-keepalive 0


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


###############################
#### 是否后台执行
daemonize yes


###############################
#### 一个监听redis的东西（不懂）
supervised no


###############################
#### 如果没设置后台守护进程,且没指定pidfile,则没有pid文件被创建
#### 如果设置了后台守护进程,则会创建/var/run/redis.pid
#### 如果没设置后台守护进程,且指定了pidfile,则以pidfile为准
#### 创建pid文件是尽力服务行为,意思就是如果没创建成功也无所谓不耽误Redis正常启动和运行
#pidfile /var/run/redis.pid
pidfile /usr/local/redis/run/redis_6379.pid


##############################
#### redis支持通过loglevel配置项设置日志等级
#### 共分四级,可以是下面的这些值：
#### debug (适用于开发或测试阶段)
#### verbose (比debug少点,但是也不少)
#### notice (适用于生产环境)
#### warning (仅仅一些重要的消息被记录)
loglevel notice


##############################
#### 指定日志文件位置
#logfile ""
logfile /usr/local/redis/log/redis.log


##############################
#### 要想把日志记录到系统日志,就把它改成 yes,
#### 也可以可选择性的更新其他的syslog 参数以达到你的要求
# syslog-enabled no


#### syslog-ident可以让你指定syslog里的日志标志
# syslog-ident redis


#### 而且还支持指定syslog设备，值可以是USER或LOCAL0-LOCAL7。具体可以参考syslog服务本身的用法
# syslog-facility local0


##############################
#### 数据库数量,可以使用SELECT 命令来切换数据库。默认使用的数据库是0号库。默认16个库
databases 16


################################ SNAPSHOTTING  ################################


############################
#### 持久化相关配置
#### 格式：save <间隔时间（秒）> <写入次数>
#### 根据给定的时间间隔和写入次数将数据保存到磁盘
#### 下面的例子的意思是：
#### 900 秒内如果至少有 1 个 key 的值变化,则保存
#### 300 秒内如果至少有 10 个 key 的值变化,则保存
#### 60 秒内如果至少有 10000 个 key 的值变化,则保存
#### 注意：你可以注释掉所有的 save 行来停用保存功能。
#### 也可以直接一个空字符""串来实现停用：
save 900 1
save 300 10
save 60 10000


###############################
#### 如果用户开启了RDB快照功能，那么在redis持久化数据到磁盘时如果出现失败，默认情况下，redis会停止接受所有的写请求。
#### 这样做的好处在于可以让用户很明确的知道内存中的数据和磁盘上的数据已经存在不一致了。
#### 如果redis不顾这种不一致，一意孤行的继续接收写请求，就可能会引起一些灾难性的后果。
#### 如果下一次RDB持久化成功，redis会自动恢复接受写请求。
#### 当然，如果你不在乎这种数据不一致或者有其他的手段发现和控制这种不一致的话，你完全可以关闭这个功能，以便在快照写入失败时，也能确保redis继续接受新的写请求。
stop-writes-on-bgsave-error yes


##############################
#### 对于存储到磁盘中的快照，可以设置是否进行压缩存储。
#### 如果是的话，redis会采用LZF算法进行压缩。如果你不想消耗CPU来进行压缩的话，可以设置为关闭此功能，但是存储在磁盘上的快照会比较大。
rdbcompression yes


##############################
#### 在存储快照后，我们还可以让redis使用CRC64算法来进行数据校验，但是这样做会增加大约10%的性能消耗，如果你希望获取到最大的性能提升，可以关闭此功能
rdbchecksum yes


##############################
#### 设置快照文件的名称,默认是这样配置的
dbfilename dump.rdb


##############################
#### 快照文件存放的路径
#### 但是它会写入到这个目录下。这个配置项一定是个目录,而不能是文件名。
#dir ./
dir /usr/local/redis/rdb


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


##############################
#### redis提供了主从同步功能。
#### 通过slaveof配置项可以控制某一个redis作为另一个redis的从服务器，通过指定IP和端口来定位到主redis的位置。
#### 一般情况下，我们会建议用户为从redis设置一个不同频率的快照持久化的周期，或者为从redis配置一个不同的服务端口等等。
# slaveof <masterip> <masterport>


##############################
#### 如果主redis设置了验证密码的话（使用requirepass来设置），则在从redis的配置中要使用masterauth来设置校验密码
#### 否则的话，主redis会拒绝从redis的访问请求
# masterauth <master-password>


##############################
#### 当从redis失去了与主redis的连接，或者主从同步正在进行中时，redis该如何处理外部发来的访问请求呢？这里，从redis可以有两种选择：
#### 第一种选择：如果slave-serve-stale-data设置为yes（默认），则从redis仍会继续响应客户端的读写请求。
#### 第二种选择：如果slave-serve-stale-data设置为no，
#### 则从redis会对客户端的请求返回“SYNC with master in progress”，当然也有例外，当客户端发来INFO请求和SLAVEOF请求，从redis还是会进行处理。
slave-serve-stale-data yes


##############################
#### 你可以控制一个从redis是否可以接受写请求。将数据直接写入从redis，一般只适用于那些生命周期非常短的数据.
#### 因为在主从同步时，这些临时数据就会被清理掉。自从redis2.6版本之后，默认从redis为只读。
slave-read-only yes


##############################
#### 是否使用socket方式复制数据，目前redis复制提供两种凡是，disk和socket，
#### 如果新的slave连上来或者重连的slave无法部分同步，就会执行全量同步，master会生成rdb文件
#### 有两种方式：
#### (1):disk方式是master创建一个新的进程把rdb文件保存到磁盘，再把磁盘上的rdb文件传送给slave
#### (2):socket是master创建一个新的进程，直接把rdb文件以socket的方式给slave
#### disk方式的时候当一个rdb保存的过程中，多个slave都能共享这个rdb文件，socket的方式就是一个个slave顺序复制
#### 在磁盘速度缓慢，网速快的情况下建议使用socket方式
repl-diskless-sync no


##############################
#### diskless复制的延迟时间，防止设置为0，一旦开始复制，节点不会再接受新的slave的复制请求
#### 直到下一个rdb传输，所以最好等待一段时间，等更多的slave连上来
repl-diskless-sync-delay 5


##############################
#### 从redis会周期性的向主redis发出PING包。你可以通过repl_ping_slave_period指令来控制其周期。默认是10秒。
# repl-ping-slave-period 10


##############################
#### 在主从同步时，可能在这些情况下会有超时发生：
#### 以从redis的角度来看，当有大规模IO传输时。
#### 以从redis的角度来看，当数据传输或PING时，主redis超时
#### 以主redis的角度来看，在回复从redis的PING时，从redis超时
#### 用户可以设置上述超时的时限，不过要确保这个时限比repl-ping-slave-period的值要大，否则每次主redis都会认为从redis超时。
# repl-timeout 60


##############################
#### 我们可以控制在主从同步时是否禁用TCP_NODELAY。
#### 如果开启TCP_NODELAY，那么主redis会使用更少的TCP包和更少的带宽来向从redis传输数据。
#### 但是这可能会增加一些同步的延迟，大概会达到40毫秒左右。
#### 如果你关闭了TCP_NODELAY，那么数据同步的延迟时间会降低，但是会消耗更多的带宽。
repl-disable-tcp-nodelay no


##############################
#### 设置同步队列长度。
#### 队列长度（backlog)是主redis中的一个缓冲区，在与从redis断开连接期间，主redis会用这个缓冲区来缓存应该发给从redis的数据。
#### 这样的话，当从redis重新连接上之后，就不必重新全量同步数据，只需要同步这部分增量数据即可
# repl-backlog-size 1mb


##############################
#### 如果主redis等了一段时间之后，还是无法连接到从redis，那么缓冲队列中的数据将被清理掉。
#### 我们可以设置主redis要等待的时间长度。如果设置为0，则表示永远不清理。默认是1个小时
# repl-backlog-ttl 3600


##############################
#### 我们可以给众多的从redis设置优先级，在主redis持续工作不正常的情况，优先级高的从redis将会升级为主redis。
#### 而编号越小，优先级越高。比如一个主redis有三个从redis，优先级编号分别为10、100、25，那么编号为10的从redis将会被首先选中升级为主redis。
#### 当优先级被设置为0时，这个从redis将永远也不会被选中。默认的优先级为100
slave-priority 100


##############################
#### 假如主redis发现有超过M个从redis的连接延时大于N秒，那么主redis就停止接受外来的写请求。
#### 这是因为从redis一般会每秒钟都向主redis发出PING，而主redis会记录每一个从redis最近一次发来PING的时间点，
#### 所以主redis能够了解每一个从redis的运行情况
# min-slaves-to-write 3
# min-slaves-max-lag 10


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


##############################
#### 我们可以要求redis客户端在向redis-server发送请求之前，先进行密码验证。
#### 当你的redis-server处于一个不太可信的网络环境中时，相信你会用上这个功能。
#### 由于redis性能非常高，所以每秒钟可以完成多达15万次的密码尝试，所以你最好设置一个足够复杂的密码，否则很容易被黑客破解
# requirepass foobared


##############################
#### 这里我们通过requirepass将密码设置成“芝麻开门”。
#### redis允许我们对redis指令进行更名，比如将一些比较危险的命令改个名字，避免被误执行。
#### 比如可以把CONFIG命令改成一个很复杂的名字，这样可以避免外部的调用，同时还可以满足内部调用的需要
# rename-command CONFIG b840fc02d524045429941cc15f59e41cb7be6c52


##############################
#### 我们甚至可以禁用掉CONFIG命令，那就是把CONFIG的名字改成一个空字符串
#### 但需要注意的是，如果你使用AOF方式进行数据持久化，或者需要与从redis进行通信，那么更改指令的名字可能会引起一些问题。
# rename-command CONFIG ""


################################### LIMITS ####################################


##############################
#### 我们可以设置redis同时可以与多少个客户端进行连接。
#### 默认情况下为10000个客户端。当你无法设置进程文件句柄限制时，redis会设置为当前的文件句柄限制值减去32，因为redis会为自身内部处理逻辑留一些句柄出来。
#### 如果达到了此限制，redis则会拒绝新的连接请求，并且向这些连接请求方发出“max number of clients reached”以作回应。
# maxclients 10000


##############################
#### 我们甚至可以设置redis可以使用的内存量。一旦到达内存使用上限，redis将会试图移除内部数据，移除规则可以通过maxmemory-policy来指定。
#### 如果redis无法根据移除规则来移除内存中的数据，或者我们设置了“不允许移除”，那么redis则会针对那些需要申请内存的指令返回错误信息，
#### 比如SET、LPUSH等。但是对于无内存申请的指令，仍然会正常响应，比如GET等
# maxmemory <bytes>


##############################
#### 需要注意的一点是，如果你的redis是主redis（说明你的redis有从redis），那么在设置内存使用上限时，需要在系统中留出一些内存空间给同步队列缓存，
#### 只有在你设置的是“不移除”的情况下，才不用考虑这个因素。
#### 对于内存移除规则来说，redis提供了多达6种的移除规则。他们是：
#### volatile-lru：使用LRU算法移除过期集合中的key
#### allkeys-lru：使用LRU算法移除key
#### volatile-random：在过期集合中移除随机的key
#### allkeys-random：移除随机的key
#### volatile-ttl：移除那些TTL值最小的key，即那些最近才过期的key。
#### noeviction：不进行移除。针对写操作，只是返回错误信息。
# maxmemory-policy noeviction


##########################
#### LRU算法和最小TTL算法都并非是精确的算法，而是估算值。
#### 所以你可以设置样本的大小。假如redis默认会检查三个key并选择其中LRU的那个，那么你可以改变这个key样本的数量。
#### 5是缺省值产生足够好的结果。
#### 10非常接近真正的LRU但会使用成本更多的CPU
#### 3是很快，但不是很准确
# maxmemory-samples 5


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


##########################
#### 默认情况下，redis会异步的将数据持久化到磁盘。
#### 这种模式在大部分应用程序中已被验证是很有效的，但是在一些问题发生时，比如断电，则这种机制可能会导致数分钟的写请求丢失。
#### 如上半部分中介绍的，追加文件（Append Only File）是一种更好的保持数据一致性的方式。
#### 即使当服务器断电时，也仅会有1秒钟的写请求丢失，当redis进程出现问题且操作系统运行正常时，甚至只会丢失一条写请求。
#### 我们建议大家，AOF机制和RDB机制可以同时使用，不会有任何冲突
appendonly no


##########################
#### aof文件的名称
appendfilename "appendonly.aof"


##########################
#### fsync()调用，用来告诉操作系统立即将缓存的指令写入磁盘。一些操作系统会“立即”进行，而另外一些操作系统则会“尽快”进行。
#### redis支持三种不同的模式：
#### no：不调用fsync()。而是让操作系统自行决定sync的时间。这种模式下，redis的性能会最快。
#### always：在每次写请求后都调用fsync()。这种模式下，redis会相对较慢，但数据最安全。
#### everysec：每秒钟调用一次fsync()。这是性能和安全的折衷
# appendfsync no


##########################
#### 当fsync方式设置为always或everysec时，如果后台持久化进程需要执行一个很大的磁盘IO操作，那么redis可能会在fsync()调用时卡住。
#### 目前尚未修复这个问题，这是因为即使我们在另一个新的线程中去执行fsync()，也会阻塞住同步写调用。
#### 为了缓解这个问题，我们可以使用下面的配置项，这样的话，当BGSAVE或BGWRITEAOF运行时，fsync()在主进程中的调用会被阻止。
#### 这意味着当另一路进程正在对AOF文件进行重构时，redis的持久化功能就失效了，就好像我们设置了“appendsync none”一样。
#### 如果你的redis有时延问题，那么请将下面的选项设置为yes。否则请保持no，因为这是保证数据完整性的最安全的选择
no-appendfsync-on-rewrite no


##########################
#### 我们允许redis自动重写aof。当aof增长到一定规模时，redis会隐式调用BGREWRITEAOF来重写log文件，以缩减文件体积。
#### redis是这样工作的：redis会记录上次重写时的aof大小。
#### 假如redis自启动至今还没有进行过重写，那么启动时aof文件的大小会被作为基准值。
#### 这个基准值会和当前的aof大小进行比较。如果当前aof大小超出所设置的增长比例，则会触发重写。
#### 如果设置auto-aof-rewrite-percentage为0，则会关闭此重写功能
auto-aof-rewrite-percentage 100
#### 设置允许重写的最小aof文件大小，是为了防止在aof很小时就触发重写
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

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


#########################
#### lua脚本运行的最大时间
lua-time-limit 5000


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


#########################
#### 配置redis做为一个集群节点来启动
# cluster-enabled yes


#########################
#### 每个集群节点都有一个集群配置文件，这个文件不需要编辑，它由redis节点来创建和更新。每个redis节点的集群配置文件不可以相同
# cluster-config-file nodes-6379.conf


#########################
#### 设置集群节点超时时间，如果超过了指定的超时时间后仍不可达，则节点被认为是失败状态，单位为毫秒。 
#### 一个属于失效的master端的slave，如果它的数据较旧，将不会启动failover。 
#### 现在来讲并没有一个简单的方法去解决如何判定一个slave端的数据的时效性问题，所以可以执行以下两个选择： 
#### 1:如果有多个slave可用于failover，它们会交换信息以便选出一个最优的进行主从复制的offset，slave端会尝试依据offset去获取每个slave的rank，
#### 	这样在启动failover时对每个slave的利用就与slave端的rank成正比。 
#### 2:每个slave端和它的master端进行最后交互的时间，这可能是最近的ping或指令接收时间，或自与master端失连的过时时间。
#### 	如果最近的交互时间太久，slave就不会尝试去进行failover。 
#### 第2点可以由用户来进行调整，明确一个slave不会进行failover。自最近一次与master端进行交互，过时时间有一个计算公式：
####（node-timeout * slave-validity-factor）+ repl-ping-slave-period
#### 一个比较大的slave-validity-factor参数能够允许slave端使用比较旧的数据去failover它的master端，而一个比较小的值可能会阻止集群去选择slave端。 
#### 为获得最大的可用性，可以设置slave-validity-factor的值为0，这表示slave端将会一直去尝试failover它的master端而不管它与master端的最后交互时间。
# cluster-slave-validity-factor 10


#########################
#### 集群中的slave可以迁移到那些没有可用slave的master端，这提升了集群处理故障的能力。
#### 毕竟一个没有slave的master端如果发生了故障是没有办法去进行failover的。 
#### 要将一个slave迁移到别的master，必须这个slave的原master端有至少给定数目的可用slave才可以进行迁移，
#### 这个给定的数目由migration barrier参数来进行设置，默认值为1，表示这个要进行迁移的slave的原master端应该至少还有1个可用的slave才允许其进行迁移，
#### 要禁用这个功能只需要将此参数设置为一个非常大的值。
# cluster-migration-barrier 1


#########################
#### 默认情况下当redis集群节点发现有至少一个hashslot未被covered时将会停止接收查询。 
#### 这种情况下如果有一部份的集群down掉了，那整个集群将变得不可用。 
#### 集群将会在所有的slot重新covered之后自动恢复可用。 
#### 若想要设置集群在部份key space没有cover完成时继续去接收查询，就将参数设置为no
# cluster-require-full-coverage yes


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


#########################
#### “慢操作日志”记录,单位:微秒(百万分之一秒,1000 * 1000),如果操作时间超过此值,将会把command信息”记录”起来.(内存,非文件)。
#### 其中”操作时间”不包括网络IO开支,只包括请求达到server后进行”内存实施”的时间.”0”表示记录全部操作。
slowlog-log-slower-than 10000


#########################
#### “慢操作日志”保留的最大条数,”记录”将会被队列化,如果超过了此长度,旧记录将会被移除。
#### 可以通过”SLOWLOG args”查看慢记录的信息(SLOWLOG get 10,SLOWLOG reset)
slowlog-max-len 128


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


#########################
#### 延迟监控(毫秒)，用于记录等于或超过了指定时间的操作，默认是关闭状态，即值为0
latency-monitor-threshold 0


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

####################
#### 键空间通知使得客户端可以通过订阅频道或模式，来接收那些以某种方式改动了 Redis 数据集的事件。因为开启键空间通知功能需要消耗一些 CPU 
#### ，所以在默认配置下，该功能处于关闭状态。
#### notify-keyspace-events 的参数可以是以下字符的任意组合，它指定了服务器该发送哪些类型的通知：
####  K 键空间通知，所有通知以 __keyspace@__ 为前缀
####  E 键事件通知，所有通知以 __keyevent@__ 为前缀
####  g DEL 、 EXPIRE 、 RENAME 等类型无关的通用命令的通知
####  $ 字符串命令的通知
####  l 列表命令的通知
####  s 集合命令的通知
####  h 哈希命令的通知
####  z 有序集合命令的通知
####  x 过期事件：每当有过期键被删除时发送
####  e 驱逐(evict)事件：每当有键因为 maxmemory 政策而被删除时发送
####  A 参数 g$lshzxe 的别名
####输入的参数中至少要有一个 K 或者 E，否则的话，不管其余的参数是什么，都不会有任何 通知被分发
notify-keyspace-events ""


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


####################
#### hash类型的数据结构在编码上可以使用ziplist和hashtable。
#### ziplist的特点就是文件存储(以及内存存储)所需的空间较小,在内容较小时,性能和hashtable几乎一样。
#### 因此redis对hash类型默认采取ziplist。如果hash中条目的条目个数或者value长度达到阀值,将会被重构为hashtable。
#### 这个参数指的是ziplist中允许存储的最大条目个数，，默认为512，建议为128
hash-max-ziplist-entries 512
#### ziplist中允许条目value值最大字节数，默认为64，建议为1024
hash-max-ziplist-value 64


##########################
#### 当取正值的时候，表示按照数据项个数来限定每个quicklist节点上的ziplist长度。比如，当这个参数配置成5的时候，表示每个quicklist节点的ziplist最多包含5个数据项。
#### 当取负值的时候，表示按照占用字节数来限定每个quicklist节点上的ziplist长度。这时，它只能取-1到-5这五个值，每个值含义如下：
####    -5: 每个quicklist节点上的ziplist大小不能超过64 Kb。（注：1kb => 1024 bytes）
####    -4: 每个quicklist节点上的ziplist大小不能超过32 Kb。
####    -3: 每个quicklist节点上的ziplist大小不能超过16 Kb。
####    -2: 每个quicklist节点上的ziplist大小不能超过8 Kb。（-2是Redis给出的默认值）
####   -1: 每个quicklist节点上的ziplist大小不能超过4 Kb。
list-max-ziplist-size -2


#########################
#### 这个参数表示一个quicklist两端不被压缩的节点个数。
#### 注：这里的节点个数是指quicklist双向链表的节点个数，而不是指ziplist里面的数据项个数。
#### 实际上，一个quicklist节点上的ziplist，如果被压缩，就是整体被压缩的。
#### 参数list-compress-depth的取值含义如下：
####    0: 是个特殊值，表示都不压缩。这是Redis的默认值。
####    1: 表示quicklist两端各有1个节点不压缩，中间的节点压缩。
####    2: 表示quicklist两端各有2个节点不压缩，中间的节点压缩。
####    3: 表示quicklist两端各有3个节点不压缩，中间的节点压缩。
####    依此类推…
#### 由于0是个特殊值，很容易看出quicklist的头节点和尾节点总是不被压缩的，以便于在表的两端进行快速存取
list-compress-depth 0


###############################
#### 数据量小于等于set-max-intset-entries用intset，大于set-max-intset-entries用set
set-max-intset-entries 512


###############################
#### 数据量小于等于zset-max-ziplist-entries用ziplist，大于zset-max-ziplist-entries用zset
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



##############################
#### Redis将在每100毫秒时使用1毫秒的CPU时间来对redis的hash表进行重新hash，可以降低内存的使用。
#### 当你的使用场景中，有非常严格的实时性需要，不能够接受Redis时不时的对请求有2毫秒的延迟的话，把这项配置为no。
#### 如果没有这么严格的实时性要求，可以设置为yes，以便能够尽可能快的释放内存
activerehashing yes


#############################
#### 对客户端输出缓冲进行限制可以强迫那些不从服务器读取数据的客户端断开连接，用来强制关闭传输缓慢的客户端。
#### 对于 normal client，第一个0表示取消hard limit，第二个0和第三个0表示取消soft limit，normal client默认取消限制，因为如果没有寻问，他们是不会接收数据的
client-output-buffer-limit normal 0 0 0


#############################
#### 对于slave client和MONITER client，如果client-output-buffer一旦超过256mb，又或者超过64mb持续60秒，那么服务器就会立即断开客户端连接。
client-output-buffer-limit slave 256mb 64mb 60


#############################
#### 对于pubsub client，如果client-output-buffer一旦超过32mb，又或者超过8mb持续60秒，那么服务器就会立即断开客户端连接。
client-output-buffer-limit pubsub 32mb 8mb 60


############################
#### redis执行任务的频率为1s除以hz
hz 10


#############################
#### 在aof重写的时候，如果打开了aof-rewrite-incremental-fsync开关，系统会每32MB执行一次fsync。
#### 这对于把文件写入磁盘是有帮助的，可以避免过大的延迟峰值
aof-rewrite-incremental-fsync yes