#绑定ip
bind 127.0.0.1 10.199.214.30

#since3.2安全策略，ip/密码
protected-mode yes

#tcp端口
port 6379

# TCP 监听的最大容纳数量
# 在高并发的环境下，你需要把这个值调高以避免客户端连接缓慢的问题。
# Linux 内核会一声不响的把这个值缩小成 /proc/sys/net/core/somaxconn 对应的值，
# 所以你要修改这两个值才能达到你的预期。

tcp-backlog 511

# Unix socket.
#
# Specify the path for the Unix socket that will be used to listen for
# incoming connections. There is no default, so Redis will not listen
# on a unix socket when not specified.
# 指定 unix socket 的路径。
# unixsocket /tmp/redis.sock
# unixsocketperm 700

# 指定在一个 client 空闲多少秒之后关闭连接（0 就是不管它）
timeout 0

# TCP keepalive.
# 心跳包,推荐一个合理的值就是60秒
tcp-keepalive 300

# 默认情况下 redis 不是作为守护进程运行的，如果你想让它在后台运行，你就把它改成 yes。
# # 当redis作为守护进程运行的时候，它会写一个 pid 到 /var/run/redis.pid 文件里面。
daemonize yes

#可以通过upstart和systemd管理Redis守护进程
#选项：
#   supervised no - 没有监督互动
#   supervised upstart - 通过将Redis置于SIGSTOP模式来启动信号
#   supervised systemd - signal systemd将READY = 1写入$ NOTIFY_SOCKET
#   supervised auto - 检测upstart或systemd方法基于 UPSTART_JOB或NOTIFY_SOCKET环境变量
supervised no

# 当redis作为守护进程运行的时候，它会把 pid 默认写到 /var/run/redis.pid 文件里面，
# 但是你可以在这里自己制定它的文件位置
pidfile /var/run/redis_6379.pid

# 定义日志级别。
# 可以是下面的这些值：
# debug (适用于开发或测试阶段)
# verbose (many rarely useful info, but not a mess like the debug level)
# notice (适用于生产环境)
# warning (仅仅一些重要的消息被记录)
loglevel notice

# Specify the log file name. Also the empty string can be used to force
# Redis to log on the standard output. Note that if you use standard
# output for logging but daemonize, logs will be sent to /dev/null
# 指定日志文件的位置
logfile ""

# 设置数据库的数目。
# # 默认数据库是 DB 0，你可以在每个连接上使用 select <dbid> 命令选择一个不同的数据库，
# # 但是 dbid 必须是一个介于 0 到 databasees - 1 之间的值
databases 16

#redis启动时是否显示Logo
always-show-logo yes

################################ 快照  ################################
#
# Save the DB on disk:
#
#   save ""
# 过了900秒（15分钟）并且有1个key发生了改变，触发save动作
# 过了300秒（5分钟）秒并且有10个key发生了改变，触发save动作
# 过了60秒（1分钟）并且至少有10000个key发生了改变，触发save动作
save 900 1
save 300 10
save 60 10000

# 默认情况下，如果 redis 最后一次的后台保存失败，redis 将停止接受写操作，
# 这样以一种强硬的方式让用户知道数据不能正确的持久化到磁盘，
# 否则就会没人注意到灾难的发生。
# 如果后台保存进程重新启动工作了，redis 也将自动的允许写操作。
# 然而你要是安装了靠谱的监控，你可能不希望 redis 这样做，那你就改成 no 好了。
stop-writes-on-bgsave-error yes

# 是否在 dump .rdb 数据库的时候使用 LZF 压缩字符串
# 默认都设为 yes
# 如果你希望保存子进程节省点 cpu ，你就设置它为 no ，
# 不过这个数据集可能就会比较大
rdbcompression yes

# Since version 5 of RDB a CRC64 checksum is placed at the end of the file.
# This makes the format more resistant to corruption but there is a performance
# hit to pay (around 10%) when saving and loading RDB files, so you can disable it
# for maximum performances.
#
# RDB files created with checksum disabled have a checksum of zero that will
# tell the loading code to skip the check.
#是否校验rdb文件
rdbchecksum yes

# The filename where to dump the DB
# 快照名称
dbfilename dump.rdb

# 工作目录
# 例如上面的 dbfilename 只指定了文件名，
# 但是它会写入到这个目录下。这个配置项一定是个目录，而不能是文件名。
dir ./

################################# 主从复制 #################################
#
# 主从复制。使用 slaveof 来让一个 redis 实例成为另一个reids 实例的副本。
# 注意这个只需要在 slave 上配置。
#
# slaveof <masterip> <masterport>
#
# 如果 master 需要密码认证，就在这里设置
# masterauth <master-password>
#
# 当一个 slave 与 master 失去联系，或者复制正在进行的时候，
# slave 可能会有两种表现：
#
# 1) 如果为 yes ，slave 仍然会应答客户端请求，但返回的数据可能是过时，
#   或者数据可能是空的在第一次同步的时候
#
# 2) 如果为 no ，在你执行除了 info he salveof 之外的其他命令时，
#   slave 都将返回一个 "SYNC with master in progress" 的错误，
#
slave-serve-stale-data yes

#如果为 yes，代表为只读状态，但并不表示客户端用集群方式以从节点为入口连入集群时，
#不可以进行 set 操作，且 set 操作的数据不会被放在从节点的槽上，会被放到某主节点的槽上。
slave-read-only yes

# Replication SYNC strategy: disk or socket.
# 复制集同步策略：磁盘或者socket
# 新slave连接或者老slave重新连接时候不能只接收不同，得做一个全同步。需要一个新的RDB文件dump出来，然后从master传到slave。可以有两种情况：
# 1）基于硬盘（disk-backed）：master创建一个新进程dump RDB，完事儿之后由父进程（即主进程）增量传给slaves。
# 2）基于socket（diskless）：master创建一个新进程直接dump RDB到slave的socket，不经过主进程，不经过硬盘。
# 基于硬盘的话，RDB文件创建后，一旦创建完毕，可以同时服务更多的slave。基于socket的话， 新slave来了后，得排队（如果超出了repl-diskless-sync-delay还没来），完事儿一个再进行下一个。
# 当用diskless的时候，master等待一个repl-diskless-sync-delay的秒数，如果没slave来的话，就直接传，后来的得排队等了。否则就可以一起传。
# disk较慢，并且网络较快的时候，可以用diskless。（默认用disk-based）
repl-diskless-sync no

# 当启用无硬盘备份，服务器等待一段时间后才会通过socket向slave传送RDB文件，这个等待时间是可配置的。
# 这一点很重要，因为一旦传送开始，就不可能再为一个新到达的slave服务。slave则要排队等待下一次RDB传送。因此服务器等待一段时间以期更多的slave到达。
# 延迟时间以秒为单位，默认为5秒。要关掉这一功能，只需将它设置为0秒，传送会立即启动。
# it entirely just set it to 0 seconds and the transfer will start ASAP.
repl-diskless-sync-delay 5

# Slave发送ping给master。默认10s
# repl-ping-slave-period 10

# 接下来的选项为以下内容设置备份的超时时间： 
# 1）从slave的角度，同步期间的批量传输的I/O 
# 2）slave角度认为的master超时（数据，ping） 
# 3）master角度认为的slave超时（REPLCONF ACK pings) 
# 确认这些值比定义的repl-ping-slave-period要大，否则每次master和slave之间通信低速时都会被检测为超时。
# repl-timeout 60

# Disable TCP_NODELAY on the slave socket after SYNC?
# slave与master的连接,是否禁用TCP nodelay选项。
# "yes"表示禁用,那么socket通讯中数据将会以packet方式发送(packet大小受到socket buffer限制)。
# 可以提高socket通讯的效率(tcp交互次数),但是小数据将会被buffer,不会被立即发送,对于接受者可能存在延迟（linux内核默认配置情况下最多40毫秒的延时。 ）。
# "no"表示开启tcp nodelay选项,任何数据都会被立即发送,及时性较好,但是效率较低，建议设为no
# 默认情况下我们将潜在因素优化，但在高负载情况下或者在主从站都跳（比如微博）的情况下，把它切换为yes是个好主意。
repl-disable-tcp-nodelay no

# 复制积压缓冲区是redis维护的固定长度缓冲队列(由参数repl-backlog-size设置，默认1MB)，
# master的写入命令在同步给slaves的同时，会在缓冲区中写入一份(master只有1个积压缓冲区，所有slaves共享）。
# 当redis复制中断后，slave会尝试采用psync, 上报原master runid + 当前已同步master的offset(复制偏移量，类似mysql的binlog file和position)；
# 如果runid与master的一致，且复制偏移量在master的复制积压缓冲区中还有(即offset >= min(backlog值)，master就认为部分重同步成功，不再进行全量同步。
# 通过主库每秒增量的master复制偏移量master_repl_offset(info replication指令获取)大小，
# 如每秒offset增加是5MB,那么主实例复制积压缓冲区要保留最近60秒写入内容，backlog_size设置就得大于300MB(60*5)。
# 而从实例重启加载RDB文件是较耗时的过程，如重启某个重实例需120秒(RDB大小和CPU配置相关），那么主实例backlog_size就得设置至少600MB。
# repl-backlog-size 1mb

# 多久释放backlog，当确认master不再需要slave的时候，多久释放。0是永远不释放。
# repl-backlog-ttl 3600

# 当master不可用，Sentinel会根据slave的优先级选举一个master。最低的优先级的slave，当选master。而配置成0，永远不会被选举。（必须≥0）。默认是100
slave-priority 100

# slave小于几个，网络lag大于几秒的时候，master停止接受write请求。默认对slave数目无限制，给0。网络延迟给10s
# min-slaves-to-write 3
# min-slaves-max-lag 10

# 常用于端口转发或NAT场景下，对Master暴露真实IP和端口信息
# slave-announce-ip 5.5.5.5
# slave-announce-port 1234

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

# 多数情况下无需密码鉴别slave。同时，由于redis处理速度太快，所以爆破速率可达150K/S。10万/S。
# 所以如果你要设置密码，必须设置超强的密码，不然容易破解。
# requirepass foobared

# 命令重命名
# 在一个shared环境里，可以对危险的命令，比如CONFIG，进行重命名：也可以用空字符串，达到完全屏蔽此命令的目的。
# rename-command CONFIG b840fc02d524045429941cc15f59e41cb7be6c52
# rename-command CONFIG ""
# 记录进AOF或者传给slave的重命名操作可能会引发问题。


################################### 限制 ####################################

# redis服务器默认设置的最大连接数maxclients是10000，但是受服务器最大文件数影响，服务器默认最大文件数是1024，所以redis最大连接也为1024-32=992，
# 由于网络原因或连接未正常关闭导致redis服务器连接数接近990左右，应用程序连不上redis。
#######################处理说明############################
# 修改服务器最大文件数vi /etc/ scurity/ limits.conf  添加* soft    nofile  65536  * hard    nofile  65536设置最大文件数65536。
# 内核参数对文件描述符也有限制，如果设置的值大于内核的限制，也是不行的，需设置vi /etc/sysctl.conf fs.file-max=65535，sysctl -p生效，
# 设置好用ulimit -a 可以看到open files为65535。
# 但是用cat proc/pid/ limits查看redis的进程对应的max open files依然为992，
# 原因是centos6.2版本以下，已经运行的进程是无法修改limits的，但是centos6.2以上可以通过echo -n ‘Max open files=65535:65535’ > /proc/pid/ limits命令，
# 动态设置redis进程的最大连接数；正常情况下已经关闭客户端但没释放的ESTABLISHED off连接是清理不掉的，只能杀掉对应redis端口，
# 数据会丢失，但是redis有封装好的方法CLIENT命令，能够实现三种功能：检查连接的状态，杀掉某个连接以及为连接设置名字三种功能，CLIENT LIST 命令能够获取当前所有客户端的状态，
# CLIENT KILL 命令来杀死指定的连接了，所以可以通过CLIENT KILL来杀掉没用但无法释放的tcp连接，处理掉redis连接数过多无法连接的问题。
# maxclients 10000

############################## 内存管理 ################################

#如果redis用内存超过了设置的限制，开始用maxmemory-policy配置的策略往外删数据，如果配置成了noeviction（默认）。所有write都会拒绝，比如set，lpush等。所有读请求可以接受。
# maxmemory <bytes>

# 内存策略。
# 1.volatile-lru:从设置了过期时间的数据集中，选择最近最久未使用的数据释放
# 2.allkeys-lru:从数据集中(包括设置过期时间以及未设置过期时间的数据集中)，选择最近最久未使用的数据释放
# 3.volatile-random:从设置了过期时间的数据集中，随机选择一个数据进行释放
# 4.allkeys-random:从数据集中(包括了设置过期时间以及未设置过期时间)随机选择一个数据进行入释放
# 5.volatile-ttl：从设置了过期时间的数据集中，选择马上就要过期的数据进行释放操作
# 6.noeviction：不删除任意数据(但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
# The default is:
#
# maxmemory-policy noeviction

# 因为上面的策略代码实现的都是近似算法，所以不管是lru算法，还是ttl，
# 都并不是在数据库中所有的数据为基础的算法，因为当数据库的数据很多的时候，这样效率太低，
# 所以代码中都是基于maxmemory-samples个数据的近似算法。
# The default of 5 produces good enough results. 10 Approximates very closely
# true LRU but costs more CPU. 3 is faster but not very accurate.
#
# maxmemory-samples 5

############################# 延迟释放since 4.0 ####################################

#当删除键的时候,redis提供异步延时释放key内存的功能，
把key释放操作放在bio(Background I/O)单独的子线程处理中，
减少删除big key对redis主线程的阻塞。有效地避免删除big key带来的性能和可用性问题。
lazyfree-lazy-eviction no
lazyfree-lazy-expire no
lazyfree-lazy-server-del no
slave-lazy-flush no

############################## aof模型 ###############################

# aof开关
appendonly no

# 增量命令持久文件路径，The name of the append only file (default: "appendonly.aof")
appendfilename "appendonly.aof"


# aof触发时机
# 每一条指令都持久化（性能较低）
# appendfsync always
# 每秒把os cache中的指令刷入aof文件（通用，性能较好）
appendfsync everysec
# 虽然性能最优，但依靠操作系统持久机制，不可控，不稳定。
# appendfsync no

# rewrite操作：首先，redis会触发垃圾回收机制。
# 比如LRU算法，清除后的数据会重写成一个新的aof文件，
# 那么在rewirte过程中有新增的数据会先持久化到就aof文件上，
# 当新aof同步完，再把rewirte过程中新增的数据指令再同步给新的aof。

# no-appendfsync-on-rewrite的策略是 no。这就会导致在进行rewrite操作时，appendfsync会被阻塞。
# 如果当前AOF文件很大，那么相应的rewrite时间会变长，appendfsync被阻塞的时间也会更长。
# 将no-appendfsync-on-rewrite设置为yes。 这样可以避免与appendfsync争用文件句柄，但是在rewrite期间的AOF有丢失的风险。
no-appendfsync-on-rewrite no


# 触发rewrite条件：当前aof文件如上一次，aof文件对比的大小（多出100%，多出64mb）。
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

# AOF文件可能在尾部是不完整的（上次system关闭有问题，尤其是mount ext4文件系统时没有加上data=ordered选项。只会发生在os死时，redis自己死不会不完整）。
# 那redis重启时load进内存的时候就有问题了。
# 发生的时候，可以选择redis启动报错，或者load尽量多正常的数据。
# 如果aof-load-truncated是yes，会自动截掉末尾发给服务然后load（默认）。如果是no，用户必须手动redis-check-aof修复AOF文件才可以。
aof-load-truncated yes

# aof rdb混合
# 可以先以RDB格式写入全量数据，再追加增量日志。
# 这样既可以提高aof rewrite和恢复速度，也可以减少文件大小，还可以保证数据的完毕性。
# 整合RDB和AOF的优点那么现在4.0实现了这一特性——RDB-AOF混合持久化。
aof-use-rdb-preamble no

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

# Max execution time of a Lua script in milliseconds.
# 一个Lua脚本最长的执行时间，单位为毫秒，如果为0或负数表示无限执行时间，默认为5000。
# 当脚本运行时间超过这一限制后，Redis将开始接受其他命令但不会执行（以确保脚本的原子性，因为此时脚本并没有被终止），而是会返回“BUSY”错误。
lua-time-limit 5000

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

# redis 集群一致性hash cluster
cluster-enabled yes

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

# 节点互连超时的阀值。集群节点超时毫秒数。即节点与集群其他节点断开多长时间将被认定为超时。建议稍微大一点
# cluster-node-timeout 15000

# 在进行故障转移的时候，全部slave都会请求申请为master，但是有些slave可能与master断开连接一段时间了，
# 导致数据过于陈旧，这样的slave不应该被提升为master。该参数就是用来判断slave节点与master断线的时间是否过长。
# 判断方法是：比较slave断开连接的时间和(node-timeout * slave-validity-factor)+ repl-ping-slave-period如果节点超时时间为三十秒,
# 并且slave-validity-factor为10,假设默认的repl-ping-slave-period是10秒，即如果超过310秒slave将不会尝试进行故障转移
#
# cluster-slave-validity-factor 10

# master的slave数量大于该值，slave才能迁移到其他孤立master上，如这个参数若被设为2，
# 那么只有当一个主节点拥有2个可工作的从节点时，它的一个从节点才会尝试迁移。
# cluster-migration-barrier 1

# 默认情况下，集群全部的slot有节点负责，集群状态才为ok，才能提供服务。设置为no，可以在slot没有全部分配的时候提供服务。
# 不建议打开该配置，这样会造成分区的时候，小分区的master一直在接受写请求，而造成很长时间数据不一致。
# cluster-require-full-coverage yes

# 如果设置为yes，当master失败，slave不能实施故障转移，如果手动执行故障转移master仍然可以运行。用在特定场景。
# cluster-slave-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 since 4.0 ########################

# Redis会自动检测自己的IP和从配置中获取绑定的PORT，告诉客户端或者是其他节点。而在Docker环境中，
# 如果使用的不是host网络模式，在容器内部的IP和PORT都是隔离的，那么客户端和其他节点无法通过节点公布的IP和PORT建立连接。
# Example:
#
# cluster-announce-ip 10.1.1.5
# cluster-announce-port 6379
# cluster-announce-bus-port 6380

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

# 用于记录记录慢查询执行时间的日志系统。只有query执行时间大于slowlog-log-slower-than的才会定义成慢查询，才会被slowlog进行记录。
# 单位是微妙，默认是10000微妙，也就是10ms。
slowlog-log-slower-than 10000

# 表示慢查询最大的条数，当slowlog超过设定的最大值后，会将最早的slowlog删除，是个FIFO队列。
slowlog-max-len 128

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

# redis延时监控系统在运行时会采样一些操作，以便收集可能导致延时的数据根源。
# 通过 LATENCY命令 可以打印一些图样和获取一些报告，方便监控
# 这个系统仅仅记录那个执行时间大于或等于预定时间（毫秒）的操作,
# 这个预定时间是通过latency-monitor-threshold配置来指定的，
# 当设置为0时，这个监控系统处于停止状态
latency-monitor-threshold 0

############################# EVENT NOTIFICATION ##############################
# 在 Redis 里面有一些事件，比如键到期、键被删除等。然后我们可以通过配置一些东西来让 Redis 一旦触发这些事件的时候就往特定的 Channel 推一条消息。
# 默认地，Keyspace 时间通知功能是禁用的，因为它或多或少会使用一些CPU的资源。
# 这里需要配置 notify-keyspace-events 的参数为 “Ex”。x 代表了过期事件。notify-keyspace-events "Ex" 保存配置后，重启Redis服务，使配置生效。
notify-keyspace-events ""

############################### ADVANCED CONFIG ###############################
# 底层数据结构，压缩策略，好玩的在这里(*￣︶￣)！
# hash结构存储，哈希对象的编码可以是ziplist或者hashtable。
# 键值对的数量小于512个
hash-max-ziplist-entries 512
# 所有键和值的字符串长度小于64字节。
hash-max-ziplist-value 64

# Lists are also encoded in a special way to save a lot of space.
# The number of entries allowed per internal list node can be specified
# as a fixed maximum size or a maximum number of elements.
# For a fixed maximum size, use -5 through -1, meaning:
# -5: max size: 64 Kb  <-- not recommended for normal workloads
# -4: max size: 32 Kb  <-- not recommended
# -3: max size: 16 Kb  <-- probably not recommended
# -2: max size: 8 Kb   <-- good
# -1: max size: 4 Kb   <-- good
# Positive numbers mean store up to _exactly_ that number of elements
# per list node.
# The highest performing option is usually -2 (8 Kb size) or -1 (4 Kb size),
# but if your use case is unique, adjust the settings as necessary.
# 设置ziplist 长度，映射如上面说明。
list-max-ziplist-size -2

# list设计最容易被访问的是列表两端的数据，中间的访问频率很低，如果符合这个场景，list还有一个配置，可以对中间节点进行压缩（采用的LZF——一种无损压缩算法），进一步节省内存。配置如下
# list-compress-depth 0
# 含义：
#     0: 是个特殊值，表示都不压缩。这是Redis的默认值。
#     1: 表示quicklist两端各有1个节点不压缩，中间的节点压缩。
#     2: 表示quicklist两端各有2个节点不压缩，中间的节点压缩。

list-compress-depth 0

# set对象的编码可以是intset或者hashtable。当满足以下两个条件时使用intset编码：
#   ● 所有元素都是整数值
#   ● 元素数量不超过512个

set-max-intset-entries 512

# sortset有序集合对象的编码可以是ziplist或者skiplist。同时满足以下条件时使用ziplist编码：
#    ● 元素数量小于128个
#    ● 所有member的长度都小于64字节
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

# 分段rehash
# 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

# Client query buffers accumulate new commands. They are limited to a fixed
# amount by default in order to avoid that a protocol desynchronization (for
# instance due to a bug in the client) will lead to unbound memory usage in
# the query buffer. However you can configure it here if you have very special
# needs, such us huge multi/exec requests or alike.
#
# client-query-buffer-limit 1gb

# In the Redis protocol, bulk requests, that are, elements representing single
# strings, are normally limited ot 512 mb. However you can change this limit
# here.
#
# proto-max-bulk-len 512mb

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


# 在aof重写的时候，如果打开了aof-rewrite-incremental-fsync开关，
# 系统会每32MB执行一次fsync。这对于把文件写入磁盘是有帮助的，可以避免过大的延迟峰值。
aof-rewrite-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.
#
# since 4.0 基于LFU的热点key发现机制
# lfu-log-factor 10
# lfu-decay-time 1

########################### ACTIVE DEFRAGMENTATION #######################
#
# WARNING THIS FEATURE IS EXPERIMENTAL. However it was stress tested
# even in production and manually tested by multiple engineers for some
# time.
#
# What is active defragmentation?
# -------------------------------
#
# Active (online) defragmentation allows a Redis server to compact the
# spaces left between small allocations and deallocations of data in memory,
# thus allowing to reclaim back memory.
#
# Fragmentation is a natural process that happens with every allocator (but
# less so with Jemalloc, fortunately) and certain workloads. Normally a server
# restart is needed in order to lower the fragmentation, or at least to flush
# away all the data and create it again. However thanks to this feature
# implemented by Oran Agra for Redis 4.0 this process can happen at runtime
# in an "hot" way, while the server is running.
#
# Basically when the fragmentation is over a certain level (see the
# configuration options below) Redis will start to create new copies of the
# values in contiguous memory regions by exploiting certain specific Jemalloc
# features (in order to understand if an allocation is causing fragmentation
# and to allocate it in a better place), and at the same time, will release the
# old copies of the data. This process, repeated incrementally for all the keys
# will cause the fragmentation to drop back to normal values.
#
# Important things to understand:
#
# 1. This feature is disabled by default, and only works if you compiled Redis
#    to use the copy of Jemalloc we ship with the source code of Redis.
#    This is the default with Linux builds.
#
# 2. You never need to enable this feature if you don't have fragmentation
#    issues.
#
# 3. Once you experience fragmentation, you can enable this feature when
#    needed with the command "CONFIG SET activedefrag yes".
#
# The configuration parameters are able to fine tune the behavior of the
# defragmentation process. If you are not sure about what they mean it is
# a good idea to leave the defaults untouched.

# Enabled active defragmentation
# 碎片整理总开关
# activedefrag yes

# Minimum amount of fragmentation waste to start active defrag
# 内存碎片达到多少的时候开启整理
# active-defrag-ignore-bytes 100mb

# Minimum percentage of fragmentation to start active defrag
# 碎片率达到百分之多少开启整理
# active-defrag-threshold-lower 10

# Maximum percentage of fragmentation at which we use maximum effort
# 碎片率小余多少百分比开启整理
# active-defrag-threshold-upper 100

# Minimal effort for defrag in CPU percentage
# 清理内存碎片的最小占用CUP
# active-defrag-cycle-min 25

# Maximal effort for defrag in CPU percentage
# 清理内存碎片的最大占用CUP
# active-defrag-cycle-max 75
--------------------- 
作者：兵子object 
来源：CSDN 
原文：https://blog.csdn.net/zb6340430/article/details/84316217 
版权声明：本文为博主原创文章，转载请附上博文链接！