# Redis配置文件解析

# Redis configuration file example.
#
# 当你需要为某个配置项指定内存大小的时候，必须要带上单位，
# 通常的格式就是 1k 5gb 4m 等：
#
# 1k => 1000 bytes
# 1kb => 1024 bytes
# 1m => 1000000 bytes
# 1mb => 1024*1024 bytes
# 1g => 1000000000 bytes
# 1gb => 1024*1024*1024 bytes
#
#单位不区分大小写
######################### INCLUDES ##########################
#
# 假如说你有一个可用于所有的 redis server 的标准配置模板，
# 但针对某些 server 又需要一些个性化的设置，
# 你可以使用 include 来包含一些其他的配置文件，这对你来说是非常有用的。
#
# 但是要注意哦，include 是不能被 config rewrite 命令改写的
# 由于 redis 总是以最后的加工线作为一个配置指令值，
# 所以你最好是把 include 放在这个文件的最前面，
# 以避免在运行时覆盖配置的改变，相反，你就把它放在后面。
#
# include /path/to/local.conf
# include /path/to/other.conf

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

# 默认情况下，redis 在 server 上所有有效的网络接口上监听客户端连接。
# 你如果只想让它在一个网络接口上监听，那你就绑定一个IP或者多个IP。
#
# Examples:
#
# bind 192.168.1.100 10.0.0.1
# bind 127.0.0.1 ::1
#
# 默认只有本机可以连接，如果需要其他机器连接，可以将下面配置注释掉~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
bind 127.0.0.1

#安全模式 yes开启 no 关闭
#开启情况下不管是否配置了密码、bind，都仅本机（127.0.0.1）可以访问

protected-mode yes

#监听端口号，默认为 6379，如果你设为 0 ，redis 将不在 socket 上监听任何客户端连接。

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

#配置unix socket来让redis支持监听本地连接。
# unixsocket /tmp/redis.sock
#配置unix socket使用文件的权限
# unixsocketperm 700

# Close the connection after a client is idle for N seconds (0 to disable)

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

#tcp keepalive参数。如果设置不为0，就使用配置tcp的SO_KEEPALIVE值，
#使用keepalive有两个好处:检测挂掉的对端。
#降低中间设备出问题而导致网络看似连接却已经与对端端口的问题。
#在Linux内核中，设置了keepalive，redis会定时给对端发送ack。
#检测到对端关闭需要两倍的设置值。
#推荐一个合理的值就是300秒
tcp-keepalive 300

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

#redis默认不是后台运行的，如果需要后台运行可以将其改为yes
#后台运行的pid会写入/var/run/redis.pid
daemonize yes

# If you run Redis from upstart or systemd, Redis can interact with your
# supervision tree. Options:
#   supervised no      - no supervision interaction
#   supervised upstart - signal upstart by putting Redis into SIGSTOP mode
#   supervised systemd - signal systemd by writing READY=1 to $NOTIFY_SOCKET # supervised auto - detect upstart or systemd method based on # UPSTART_JOB or NOTIFY_SOCKET environment variables # Note: these supervision methods only signal "process is ready." # They do not enable continuous liveness pings back to your supervisor. supervised no #指定redis的进程文件 pidfile /var/run/redis_6379.pid #指定了服务端日志的级别。级别包括： #debug（很多信息，方便开发、测试）， #verbose（许多有用的信息，但是没有debug级别信息多）， #notice（适当的日志级别，适合生产环境）， #warn（只有非常重要的信息） loglevel notice #指定了记录日志的文件。空字符串的话，日志会打印到标准输出设备。 #后台运行的redis标准输出是/dev/null。 logfile "" #是否打开记录syslog功能 # syslog-enabled no #syslog的标识符。 # syslog-ident redis #日志的来源、设备LOCAL0-LOCAL7 # syslog-facility local0 #数据库的数量，默认使用的数据库是DB 0。可以通过”SELECT “命令选择一个db databases 16 ###################### SNAPSHOTTING ###################### # # 快照配置 # 注释掉“save”这一行配置项就可以让保存数据库功能失效 # 设置sedis进行数据库镜像的频率。 # 900秒（15分钟）内至少1个key值改变（则进行数据库保存--持久化） # 300秒（5分钟）内至少10个key值改变（则进行数据库保存--持久化） # 60秒（1分钟）内至少10000个key值改变（则进行数据库保存--持久化） # save "" save 900 1 save 300 10 save 60 10000 #当RDB持久化出现错误后，是否依然进行继续进行工作， #yes：不能进行工作，no：可以继续进行工作， #可以通过info中的rdb_last_bgsave_status了解RDB持久化是否有错误 stop-writes-on-bgsave-error yes #对于存储到磁盘中的快照，可以设置是否进行压缩存储。如果是的话， #redis会采用LZF算法进行压缩。如果你不想消耗CPU来进行压缩的话，可以设置为关闭此功能 rdbcompression yes #在存储快照后，还可以让redis使用CRC64算法来进行数据校验， #但是这样做会增加大约10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能 rdbchecksum yes # The filename where to dump the DB #rdb文件的名称 dbfilename dump.rdb #数据目录，数据库的写入会在这个目录。rdb、aof文件也会写在这个目录 dir ./ ######################## REPLICATION ######################### # #slave复制对应的master。 # slaveof <masterip> <masterport> #如果master设置了requirepass，那么slave要连上master，需要有master的密码才行。 #masterauth就是用来配置master的密码，这样可以在连上master后进行认证。 # masterauth <master-password> #当从库同主机失去连接或者复制正在进行，从机库有两种运行方式： #1) 如果slave-serve-stale-data设置为yes(默认设置)，从库会继续响应客户端的请求。 #2) 如果slave-serve-stale-data设置为no，除去INFO和SLAVOF命令之外的任何请求 #都会返回一个错误”SYNC with master in progress”。 slave-serve-stale-data yes #作为从服务器，默认情况下是只读的（yes），可以修改成NO，用于写（不建议）。 slave-read-only yes #是否使用socket方式复制数据。目前redis复制提供两种方式，disk和socket。 #如果新的slave连上来或者重连的slave无法部分同步，就会执行全量同步，master会生成rdb文件。 #有2种方式：disk方式是master创建一个新的进程把rdb文件保存到磁盘，再把磁盘上的rdb文件传递给slave。 #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 #slave根据指定的时间间隔向服务器发送ping请求。 #时间间隔可以通过 repl_ping_slave_period 来设置，默认10秒 # repl-ping-slave-period 10 #复制连接超时时间。master和slave都有超时时间的设置。 #master检测到slave上次发送的时间超过repl-timeout，即认为slave离线，清除该slave信息。 #slave检测到上次和master交互的时间超过repl-timeout，则认为master离线。 #需要注意的是repl-timeout需要设置一个比repl-ping-slave-period更大的值， #不然会经常检测到超时。 # repl-timeout 60 #是否禁止复制tcp链接的tcp nodelay参数，可传递yes或者no。默认是no #如果master设置了yes来禁止tcp nodelay设置，在把数据复制给slave的时候， #会减少包的数量和更小的网络带宽。但是这也可能带来数据的延迟。 #默认我们推荐更小的延迟，但是在数据量传输很大的场景下，建议选择yes。 repl-disable-tcp-nodelay no #复制缓冲区大小，这是一个环形复制缓冲区，用来保存最新复制的命令。这样在slave离线的时候， #不需要完全复制master的数据，如果可以执行部分同步，只需要把缓冲区的部分数据复制给slave， #就能恢复正常复制状态。缓冲区的大小越大，slave离线的时间可以更长， #复制缓冲区只有在有slave连接的时候才分配内存。 #没有slave的一段时间，内存会被释放出来，默认1m。 # repl-backlog-size 1mb #master没有slave一段时间会释放复制缓冲区的内存， #repl-backlog-ttl用来设置该时间长度。单位为秒。 # repl-backlog-ttl 3600 #当master不可用，Sentinel会根据slave的优先级选举一个master。 #最低的优先级的slave，当选master。而配置成0，永远不会被选举 slave-priority 100 #redis提供了可以让master停止写入的方式，如果配置了min-slaves-to-write， #健康的slave的个数小于N，mater就禁止写入。 #master最少得有多少个健康的slave存活才能执行写命令。 #这个配置虽然不能保证N个slave都一定能接收到master的写操作， #但是能避免没有足够健康的slave的时候，master不能写入来避免数据丢失。 #设置为0是关闭该功能。 # min-slaves-to-write 3 #延迟小于min-slaves-max-lag秒的slave才认为是健康的slave。 # min-slaves-max-lag 10 #slave向master提供自己的IP和端口 # # slave-announce-ip 5.5.5.5 # slave-announce-port 1234 ####################### SECURITY ######################### #requirepass配置可以让用户使用AUTH命令来认证密码，才能使用其他命令。 #使用requirepass的时候需要注意，因为redis太快了，每秒可以认证15w次密码， #简单的密码很容易被攻破，所以最好使用一个更复杂的密码。 # requirepass foobared #把危险的命令给修改成其他名称。比如CONFIG命令可以重命名为一个很难被猜到的命令， #这样用户不能使用，而内部工具还能接着使用。 #设置成一个空的值，可以禁止一个命令 # # rename-command CONFIG "" # # 别修改登录命令的名称，那样会使aof和slave不起作用 ########################## LIMITS ############################ #设置能连上redis的最大客户端连接数量。默认是10000个客户端连接。 #由于redis不区分连接是客户端连接还是内部打开文件或者和slave连接等， #所以maxclients最小建议设置到32。如果超过了maxclients， #redis会给新的连接发送’max number of clients reached’，并关闭连接。 # # maxclients 10000 #redis配置的最大内存容量。当内存满了，需要配合maxmemory-policy策略进行处理。 #注意slave的输出缓冲区是不计算在maxmemory内的。 #所以为了防止主机内存使用完，建议设置的maxmemory需要更小一些。 # # maxmemory <bytes> #内存容量超过maxmemory后的处理策略。 #volatile-lru：利用LRU算法移除设置过过期时间的key。 #volatile-random：随机移除设置过过期时间的key。 #volatile-ttl：移除即将过期的key，根据最近过期时间来删除（辅以TTL） #allkeys-lru：利用LRU算法移除任何key。 #allkeys-random：随机移除任何key。 #noeviction：不移除任何key，只是返回一个写错误。 # # maxmemory-policy noeviction #lru检测的样本数。使用lru或者ttl淘汰算法，从需要淘汰的列表中随机选择sample个key，选出闲置时间最长的key移除。 # # maxmemory-samples 5 ###################### APPEND ONLY MODE ######################## #是否开启aof appendonly no #aof文件名 appendfilename "appendonly.aof" #aof持久化策略的配置 #no表示不执行fsync，由操作系统保证数据同步到磁盘，速度最快。 #always表示每次写入都执行fsync，以保证数据同步到磁盘。 #everysec表示每秒执行一次fsync，可能会导致丢失这1s数据。 # 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秒数据。 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文件可能在尾部是不完整的，当redis启动的时候，aof文件的数据被载入内存。#重启可能发生在redis所在的主机操作系统宕机后，尤其在ext4文件系统没有加上data=ordered选项 #（redis宕机或者异常终止不会造成尾部不完整现象。）出现这种现象， #可以选择让redis退出，或者导入尽可能多的数据。如果选择的是yes， #当截断的aof文件被导入的时候，会自动发布一个log给客户端然后load。 #如果是no，用户必须手动redis-check-aof修复AOF文件才可以。 aof-load-truncated yes ########################## SLOW LOG ############################ #slog log是用来记录redis运行中执行比较慢的命令耗时。 #当命令的执行超过了指定时间，就记录在slow log中，slog log保存在内存中，所以没有IO操作。 #执行时间比slowlog-log-slower-than大的请求记录到slowlog里面，单位是微秒， #所以1000000就是1秒。注意，负数时间会禁用慢查询日志，而0则会强制记录所有命令。 slowlog-log-slower-than 10000 #慢查询日志长度。当一个新的命令被写进日志的时候，最老的那个记录会被删掉。这个长度没有限制。只要有足够的内存就行。你可以通过 SLOWLOG RESET 来释放内存。 slowlog-max-len 128 ######################## LUA SCRIPTING ######################## # 如果达到最大时间限制（毫秒），redis会记个log，然后返回error。 #当一个脚本超过了最大时限。只有SCRIPT KILL和SHUTDOWN NOSAVE可以用。 #第一个可以杀没有调write命令的东西。要是已经调用了write，只能用第二个命令杀。 lua-time-limit 5000 ######################## LATENCY MONITOR ##################### #延迟监控功能是用来监控redis中执行比较缓慢的一些操作， #用LATENCY打印redis实例在跑命令时的耗时图表。 #只记录大于等于下边设置的值的操作。 #0的话，就是关闭监视。 #默认延迟监控功能是关闭的，如果你需要打开，也可以通过CONFIG SET命令动态设置。 latency-monitor-threshold 0 ####################### REDIS CLUSTER ####################### # # ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ # WARNING EXPERIMENTAL: Redis Cluster is considered to be stable code, however # in order to mark it as "mature" we need to wait for a non trivial percentage # of users to deploy it in production. # ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ # # Normal Redis instances can't be part of a Redis Cluster; only nodes that are # started as cluster nodes can. In order to start a Redis instance as a # cluster node enable the cluster support uncommenting the following: # # cluster-enabled yes # Every cluster node has a cluster configuration file. This file is not # intended to be edited by hand. It is created and updated by Redis nodes. # Every Redis Cluster node requires a different cluster configuration file. # Make sure that instances running in the same system do not have # overlapping cluster configuration file names. # # cluster-config-file nodes-6379.conf # Cluster node timeout is the amount of milliseconds a node must be unreachable # for it to be considered in failure state. # Most other internal time limits are multiple of the node timeout. # # cluster-node-timeout 15000 # A slave of a failing master will avoid to start a failover if its data # looks too old. # # There is no simple way for a slave to actually have a exact measure of # its "data age", so the following two checks are performed: # # 1) If there are multiple slaves able to failover, they exchange messages # in order to try to give an advantage to the slave with the best # replication offset (more data from the master processed). # Slaves will try to get their rank by offset, and apply to the start # of the failover a delay proportional to their rank. # # 2) Every single slave computes the time of the last interaction with # its master. This can be the last ping or command received (if the master # is still in the "connected" state), or the time that elapsed since the # disconnection with the master (if the replication link is currently down). # If the last interaction is too old, the slave will not try to failover # at all. # # The point "2" can be tuned by user. Specifically a slave will not perform # the failover if, since the last interaction with the master, the time # elapsed is greater than: # # (node-timeout * slave-validity-factor) + repl-ping-slave-period # # So for example if node-timeout is 30 seconds, and the slave-validity-factor # is 10, and assuming a default repl-ping-slave-period of 10 seconds, the # slave will not try to failover if it was not able to talk with the master # for longer than 310 seconds. # # A large slave-validity-factor may allow slaves with too old data to failover # a master, while a too small value may prevent the cluster from being able to # elect a slave at all. # # For maximum availability, it is possible to set the slave-validity-factor # to a value of 0, which means, that slaves will always try to failover the # master regardless of the last time they interacted with the master. # (However they'll always try to apply a delay proportional to their # offset rank). # # Zero is the only value able to guarantee that when all the partitions heal # the cluster will always be able to continue. # # cluster-slave-validity-factor 10 # Cluster slaves are able to migrate to orphaned masters, that are masters # that are left without working slaves. This improves the cluster ability # to resist to failures as otherwise an orphaned master can't be failed over # in case of failure if it has no working slaves. # # Slaves migrate to orphaned masters only if there are still at least a # given number of other working slaves for their old master. This number # is the "migration barrier". A migration barrier of 1 means that a slave # will migrate only if there is at least 1 other working slave for its master # and so forth. It usually reflects the number of slaves you want for every # master in your cluster. # # Default is 1 (slaves migrate only if their masters remain with at least # one slave). To disable migration just set it to a very large value. # A value of 0 can be set but is useful only for debugging and dangerous # in production. # # cluster-migration-barrier 1 # By default Redis Cluster nodes stop accepting queries if they detect there # is at least an hash slot uncovered (no available node is serving it). # This way if the cluster is partially down (for example a range of hash slots # are no longer covered) all the cluster becomes, eventually, unavailable. # It automatically returns available as soon as all the slots are covered again. # # However sometimes you want the subset of the cluster which is working, # to continue to accept queries for the part of the key space that is still # covered. In order to do so, just set the cluster-require-full-coverage # option to no. # # cluster-require-full-coverage yes # In order to setup your cluster make sure to read the documentation # available at http://redis.io web site. ####################### LATENCY MONITOR ###################### # The Redis latency monitoring subsystem samples different operations # at runtime in order to collect data related to possible sources of # latency of a Redis instance. # # Via the LATENCY command this information is available to the user that can # print graphs and obtain reports. # # The system only logs operations that were performed in a time equal or # greater than the amount of milliseconds specified via the # latency-monitor-threshold configuration directive. When its value is set # to zero, the latency monitor is turned off. # # By default latency monitoring is disabled since it is mostly not needed # if you don't have latency issues, and collecting data has a performance # impact, that while very small, can be measured under big load. Latency # monitoring can easily be enabled at runtime using the command # "CONFIG SET latency-monitor-threshold <milliseconds>" if needed. latency-monitor-threshold 0 ################### EVENT NOTIFICATION ###################### # Redis can notify Pub/Sub clients about events happening in the key space. # This feature is documented at http://redis.io/topics/notifications # # For instance if keyspace events notification is enabled, and a client # performs a DEL operation on key "foo" stored in the Database 0, two # messages will be published via Pub/Sub: # # PUBLISH __keyspace@0__:foo del # PUBLISH __keyevent@0__:del foo # # It is possible to select the events that Redis will notify among a set # of classes. Every class is identified by a single character: # # K Keyspace events, published with __keyspace@<db>__ prefix. # E Keyevent events, published with __keyevent@<db>__ prefix. # g Generic commands (non-type specific) like DEL, EXPIRE, RENAME, ... #$     String commands
#  l     List commands
#  s     Set commands
#  h     Hash commands
#  z     Sorted set commands
#  x     Expired events (events generated every time a key expires)
#  e     Evicted events (events generated when a key is evicted for maxmemory)
#  A     Alias for g\$lshzxe, so that the "AKE" string means all the events.
#
#  The "notify-keyspace-events" takes as argument a string that is composed
#  of zero or multiple characters. The empty string means that notifications
#  are disabled.
#
#  Example: to enable list and generic events, from the point of view of the
#           event name, use:
#
#  notify-keyspace-events Elg
#
#  Example 2: to get the stream of the expired keys subscribing to channel
#             name __keyevent@0__:expired use:
#
#  notify-keyspace-events Ex
#
#  By default all notifications are disabled because most users don't need
#  this feature and the feature has some overhead. Note that if you don't
#  specify at least one of K or E, no events will be delivered.
notify-keyspace-events ""

# Hashes are encoded using a memory efficient data structure when they have a
# small number of entries, and the biggest entry does not exceed a given
# threshold. These thresholds can be configured using the following directives.
hash-max-ziplist-entries 512
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.
list-max-ziplist-size -2

# Lists may also be compressed.
# Compress depth is the number of quicklist ziplist nodes from *each* side of
# the list to *exclude* from compression.  The head and tail of the list
# are always uncompressed for fast push/pop operations.  Settings are:
# 0: disable all list compression
# 1: depth 1 means "don't start compressing until after 1 node into the list,
#    going from either the head or tail"
#    [head], [tail] will always be uncompressed; inner nodes will compress.
#    2 here means: don't compress head or head->next or tail->prev or tail,
#    but compress all nodes between them.
# etc.
list-compress-depth 0

# Sets have a special encoding in just one case: when a set is composed
# of just strings that happen to be integers in radix 10 in the range
# of 64 bit signed integers.
# The following configuration setting sets the limit in the size of the
# set in order to use this special memory saving encoding.
set-max-intset-entries 512

# Similarly to hashes and lists, sorted sets are also specially encoded in
# order to save a lot of space. This encoding is only used when the length and
# elements of a sorted set are below the following limits:
zset-max-ziplist-entries 128
zset-max-ziplist-value 64

# HyperLogLog sparse representation bytes limit. The limit includes the
# 16 bytes header. When an HyperLogLog using the sparse representation crosses
# this limit, it is converted into the dense representation.
#
# A value greater than 16000 is totally useless, since at that point the
# dense representation is more memory efficient.
#
# The suggested value is ~ 3000 in order to have the benefits of
# the space efficient encoding without slowing down too much PFADD,
# which is O(N) with the sparse encoding. The value can be raised to
# ~ 10000 when CPU is not a concern, but space is, and the data set is
# composed of many HyperLogLogs with cardinality in the 0 - 15000 range.
hll-sparse-max-bytes 3000

# Active rehashing uses 1 millisecond every 100 milliseconds of CPU time in
# order to help rehashing the main Redis hash table (the one mapping top-level
# keys to values). The hash table implementation Redis uses (see dict.c)
# performs a lazy rehashing: the more operation you run into a hash table
# that is rehashing, the more rehashing "steps" are performed, so if the
# server is idle the rehashing is never complete and some more memory is used
# by the hash table.
#
# The default is to use this millisecond 10 times every second in order to
# actively rehash the main dictionaries, freeing memory when possible.
#
# If unsure:
# use "activerehashing no" if you have hard latency requirements and it is
# not a good thing in your environment that Redis can reply from time to time
# to queries with 2 milliseconds delay.
#
# use "activerehashing yes" if you don't have such hard requirements but
# want to free memory asap when possible.
activerehashing yes

# The client output buffer limits can be used to force disconnection of clients
# that are not reading data from the server fast enough for some reason (a
# common reason is that a Pub/Sub client can't consume messages as fast as the
# publisher can produce them).
#
# The limit can be set differently for the three different classes of clients:
#
# normal -> normal clients including MONITOR clients
# slave  -> slave clients
# pubsub -> clients subscribed to at least one pubsub channel or pattern
#
# The syntax of every client-output-buffer-limit directive is the following:
#
# client-output-buffer-limit <class> <hard limit> <soft limit> <soft seconds>
#
# A client is immediately disconnected once the hard limit is reached, or if
# the soft limit is reached and remains reached for the specified number of
# seconds (continuously).
# So for instance if the hard limit is 32 megabytes and the soft limit is
# 16 megabytes / 10 seconds, the client will get disconnected immediately
# if the size of the output buffers reach 32 megabytes, but will also get
# disconnected if the client reaches 16 megabytes and continuously overcomes
# the limit for 10 seconds.
#
# By default normal clients are not limited because they don't receive data
# without asking (in a push way), but just after a request, so only
# asynchronous clients may create a scenario where data is requested faster
#
# Instead there is a default limit for pubsub and slave clients, since
# subscribers and slaves receive data in a push fashion.
#
# Both the hard or the soft limit can be disabled by setting them to zero.
client-output-buffer-limit normal 0 0 0
client-output-buffer-limit slave 256mb 64mb 60
client-output-buffer-limit pubsub 32mb 8mb 60

# Redis calls an internal function to perform many background tasks, like
# closing connections of clients in timeout, purging expired keys that are
# never requested, and so forth.
#
# Not all tasks are performed with the same frequency, but Redis checks for
# tasks to perform according to the specified "hz" value.
#
# By default "hz" is set to 10. Raising the value will use more CPU when
# Redis is idle, but at the same time will make Redis more responsive when
# there are many keys expiring at the same time, and timeouts may be
# handled with more precision.
#
# The range is between 1 and 500, however a value over 100 is usually not
# a good idea. Most users should use the default of 10 and raise this up to
# 100 only in environments where very low latency is required.
hz 10

# When a child rewrites the AOF file, if the following option is enabled
# the file will be fsync-ed every 32 MB of data generated. This is useful
# in order to commit the file to the disk more incrementally and avoid
# big latency spikes.
aof-rewrite-incremental-fsync yes

• 广告
• 抄袭
• 版权
• 政治
• 色情
• 无意义
• 其他

120