学习redis的途中，碰上了redis.conf，突发奇想，想着来进行一波翻译输出。
源码之前，了无秘密。
@[toc]
redis集群
原文
################################ REDIS CLUSTER ###############################
# 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 replica of a failing master will avoid to start a failover if its data
# looks too old.
#
# There is no simple way for a replica to actually have an exact measure of
# its "data age", so the following two checks are performed:
#
# 1) If there are multiple replicas able to failover, they exchange messages
# in order to try to give an advantage to the replica with the best
# replication offset (more data from the master processed).
# Replicas 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 replica 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 replica will not try to failover
# at all.
#
# The point "2" can be tuned by user. Specifically a replica will not perform
# the failover if, since the last interaction with the master, the time
# elapsed is greater than:
#
# (node-timeout * replica-validity-factor) + repl-ping-replica-period
#
# So for example if node-timeout is 30 seconds, and the replica-validity-factor
# is 10, and assuming a default repl-ping-replica-period of 10 seconds, the
# replica will not try to failover if it was not able to talk with the master
# for longer than 310 seconds.
#
# A large replica-validity-factor may allow replicas with too old data to failover
# a master, while a too small value may prevent the cluster from being able to
# elect a replica at all.
#
# For maximum availability, it is possible to set the replica-validity-factor
# to a value of 0, which means, that replicas 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-replica-validity-factor 10
# Cluster replicas are able to migrate to orphaned masters, that are masters
# that are left without working replicas. 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 replicas.
#
# Replicas migrate to orphaned masters only if there are still at least a
# given number of other working replicas for their old master. This number
# is the "migration barrier". A migration barrier of 1 means that a replica
# will migrate only if there is at least 1 other working replica for its master
# and so forth. It usually reflects the number of replicas you want for every
# master in your cluster.
#
# Default is 1 (replicas migrate only if their masters remain with at least
# one replica). 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
# This option, when set to yes, prevents replicas from trying to failover its
# master during master failures. However the master can still perform a
# manual failover, if forced to do so.
#
# This is useful in different scenarios, especially in the case of multiple
# data center operations, where we want one side to never be promoted if not
# in the case of a total DC failure.
#
# cluster-replica-no-failover no
# This option, when set to yes, allows nodes to serve read traffic while the
# the cluster is in a down state, as long as it believes it owns the slots.
#
# This is useful for two cases. The first case is for when an application
# doesn't require consistency of data during node failures or network partitions.
# One example of this is a cache, where as long as the node has the data it
# should be able to serve it.
#
# The second use case is for configurations that don't meet the recommended
# three shards but want to enable cluster mode and scale later. A
# master outage in a 1 or 2 shard configuration causes a read/write outage to the
# entire cluster without this option set, with it set there is only a write outage.
# Without a quorum of masters, slot ownership will not change automatically.
#
# cluster-allow-reads-when-down no
# In order to setup your cluster make sure to read the documentation
# available at http://redis.io web site.译文
普通的Redis实例不能成为Redis集群的一部分，只有作为集群节点启动的节点可以。为了启动一个有集群支持的Redis实例，可以把下面这行取消注释:
# cluster-enabled yes每个集群节点都有一个集群配置文件。此文件不用于手工编辑。它是由Redis节点创建和更新的。
每个集群节点的配置文件都不一样。
确保同一系统下的任意两集群节点的集群配置文件不重名。
如：
# cluster-config-file nodes-6379.conf群集节点超时是指一个节点无法被访问的毫秒数，从而将其视为处于故障状态。大多数其他内部时间限制是节点超时的多倍。
# cluster-node-timeout 15000如果发生故障的主机的数据看起来太旧，它的副本将避免启动故障转移。
没有一种简单的方法可以让副本真正精确地测量它的“数据年龄”，因此执行以下两个检查：
1)如果有多个副本可以进行故障转移，它们会交换消息，使副本具有最好的复制偏移(更多来自主处理的数据)。副本将尝试通过偏移量获得它们的级别，并对故障转移的启动应用与它们的级别成比例的延迟。
2)每个副本计算最后一次与主机交互的时间。这可以是接收到的最后一个ping或命令(如果主服务器仍然处于“connected”状态)，或者是自与主服务器断开连接以来所经过的时间(如果复制链接当前处于关闭状态)。
如果最后一个交互太久远，副本根本不会尝试故障转移。第二点可以由使用者调优。具体来说，如果自上次与主服务器交互以来，经过的时间大于:# (node-timeout * replica-validity-factor) + repl-ping-replica-period，
因此，例如，如果node-timeout为30秒，复制有效性因子（replica-validity-factor）为10，并假设默认的repl-ping-replica-period为10秒，那么如果副本无法与主服务器对话的时间超过310秒，则不会尝试进行故障转移。
较大的副本有效性因子可能会使数据太旧的副本无法转移主服务器，而太小的值可能会使集群根本无法选择副本。
为了获得最大的可用性，可以将副本有效性因子设置为0，这意味着副本将始终尝试对主服务器进行故障转移，而不管它们上一次与主服务器交互是什么时候。(然而，他们总是试图应用一个与他们的偏移秩成比例的延迟)。
0是唯一能够保证所有分区恢复后集群始终能够继续运行的值。
集群副本能够迁移到孤立的主服务器，即没有工作副本的主服务器。这提高了集群抵抗故障的能力，否则，在出现故障时，如果孤立的主服务器没有工作副本，则无法进行故障转移。
只有当它们的旧主服务器仍然至少有给定数量的其他工作副本时，副本才会迁移到孤立的主服务器。这个数字就是“迁移障碍”。迁移障碍为1意味着一个副本只有在其主副本至少有1个工作副本时才会迁移，以此类推。它通常反映集群中每个主服务器所需的副本数量。
默认值是1(只有当它们的主副本保留至少一个副本时，副本才会迁移)。要禁用迁移，只需将其设置为一个非常大的值。
可以设置值0，但这只对调试有用，在生产中会有危险。
默认情况下，如果Redis集群节点检测到至少有一个散列槽未覆盖(没有可用节点为其服务)，则停止接受查询。
这样，如果集群部分关闭(例如不再覆盖一段散列槽)，那么最终所有集群都将不可用。当所有插槽再次被覆盖时，它自动返回可用。
但是，有时您希望正在工作的集群子集继续接受仍然覆盖的键空间部分的查询。为此，只需将cluster-require-full-coverage选项设置为no。
# cluster-require-full-coverage yes当将此选项设置为yes时，可防止副本在主服务器出现故障时试图转移其主服务器。但是，如果被迫，主服务器仍然可以执行手动故障转移。
这在不同的场景中非常有用，特别是在多个数据中心操作的情况下，如果在完全DC故障的情况下，我们希望其中一侧永远不会得到提升。
# cluster-replica-no-failover no当将此选项设置为yes时，只要集群认为自己拥有这些槽，就允许节点在集群处于down状态时提供读流量。
这在两种情况下有用。
第一种情况是应用程序在节点故障或网络分区期间不需要数据一致性。
其中一个例子就是缓存，只要节点拥有数据，它就应该能够提供数据。
第二个用例用于不满足推荐的三个切分，但希望启用集群模式并稍后扩展的配置。1或2分片配置中的主中断会导致整个集群在没有设置此选项的情况下出现读/写中断，设置此选项后，只有写中断。没有主控的法定人数，插槽所有权将不会自动更改。# cluster-allow-reads-when-down no为了设置您的集群，请阅读http://redis.io网站提供的文档。
集群 DOCKER/NAT 支持
原文
########################## CLUSTER DOCKER/NAT support ########################
# In certain deployments, Redis Cluster nodes address discovery fails, because
# addresses are NAT-ted or because ports are forwarded (the typical case is
# Docker and other containers).
#
# In order to make Redis Cluster working in such environments, a static
# configuration where each node knows its public address is needed. The
# following two options are used for this scope, and are:
#
# * 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.
#
# If the above options are not used, the normal Redis Cluster auto-detection
# will be used instead.
#
# Note that when remapped, the bus port may not be at the fixed offset of
# clients port + 10000, so you can specify any port and bus-port depending
# on how they get remapped. If the bus-port is not set, a fixed offset of
# 10000 will be used as usually.
#
# Example:
#
# cluster-announce-ip 10.1.1.5
# cluster-announce-port 6379
# cluster-announce-bus-port 6380译文
在某些部署中，Redis集群节点地址发现失败，原因是地址是NAT的，或者是端口被转发（典型的情况是Docker和其他容器）。
为了让Redis集群在这样的环境下工作，需要一个静态配置，每个节点都知道自己的公共地址。以下两个选项用于此范围，它们是:
# * cluster-announce-ip
# * cluster-announce-port
# * cluster-announce-bus-port每个节点指示其地址、客户端端口和集群消息总线端口。然后在总线包的头中发布信息，以便其他节点能够正确地映射发布信息的节点的地址。
如果不使用以上选项，将使用正常的Redis集群自动检测代替。
请注意，在重新映射时，总线端口可能不在客户端端口+ 10000的固定偏移量处，因此您可以根据重新映射的方式指定任何端口和总线端口。如果总线端口没有设置，则通常使用10000的固定偏移量。
例如
# Example:
#
# cluster-announce-ip 10.1.1.5
# cluster-announce-port 6379
# cluster-announce-bus-port 6380慢查询日志
原文
################################## SLOW LOG ###################################
# The Redis Slow Log is a system to log queries that exceeded a specified
# execution time. The execution time does not include the I/O operations
# like talking with the client, sending the reply and so forth,
# but just the time needed to actually execute the command (this is the only
# stage of command execution where the thread is blocked and can not serve
# other requests in the meantime).
#
# You can configure the slow log with two parameters: one tells Redis
# what is the execution time, in microseconds, to exceed in order for the
# command to get logged, and the other parameter is the length of the
# slow log. When a new command is logged the oldest one is removed from the
# queue of logged commands.
# The following time is expressed in microseconds, so 1000000 is equivalent
# to one second. Note that a negative number disables the slow log, while
# a value of zero forces the logging of every command.
slowlog-log-slower-than 10000
# There is no limit to this length. Just be aware that it will consume memory.
# You can reclaim memory used by the slow log with SLOWLOG RESET.
slowlog-max-len 128译文
Redis慢日志是一个记录超过指定执行时间的查询的系统。执行时间不包括I / O操作,比如与客户端,发送应答等等,但就实际执行命令所需的时间(这是命令执行的唯一阶段，线程被阻塞，不能同时为其他请求服务)。
你可以用两个参数来配置慢日志:一个参数告诉Redis执行时间(以微秒为单位)，以便命令能够被记录下来，另一个参数是慢日志的长度。记录新命令时，将从已记录的命令队列中删除最老的命令。
下面的时间用微秒表示，所以1000000等于一秒。注意，负数禁用慢日志，而值为0则强制记录每个命令。
slowlog-log-slower-than 10000这个长度没有限制。只是要知道它会消耗内存。使用SLOWLOG复位，您可以回收慢日志使用的内存。
slowlog-max-len 128延迟监控
原文
################################ 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译文
Redis延迟监控子系统在运行时对不同的操作进行采样，以便收集Redis实例延迟可能来源的相关数据。
通过延迟命令，用户可以通过打印图形和获取报告获得这些信息。
系统只记录在时间等于或大于通过延迟监视器阈值配置指令指定的毫秒数的时间内执行的操作。当它的值设置为0时，将关闭延迟监视器。
默认情况下，延迟监视是禁用的，因为如果没有延迟问题，那么通常不需要进行延迟监视，而且收集数据会对性能产生影响，尽管影响很小，但在大负载下可以度量出来。
如果需要，可以在运行时使用命令“CONFIG SET delay -monitor-threshold ”轻松启用延迟监视。
订阅发布
原文
############################# 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)
# t Stream commands
# m Key-miss events (Note: It is not included in the 'A' class)
# A Alias for g$lshzxet, so that the "AKE" string means all the events
# (Except key-miss events which are excluded from 'A' due to their
# unique nature).
#
# 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 ""
译文
Redis可以通知Pub/Sub客户端在key space发生的事件，该特性在http://redis.io/topics/notifications上可以找到。
例如，如果启用了keyspace事件通知，客户端对数据库0中存储的key "foo"执行DEL操作，将通过Pub/Sub发布两条消息：
# PUBLISH __keyspace@0__:foo del
# PUBLISH __keyevent@0__:del foo可以在一组类中选择Redis将通知的事件。每个类都由一个字符标识：
# K Keyspace 命令, 以__keystpace@<db>__ 前缀发布.
# E Keyevent 命令, 以__keyevent@<db>__ 前缀发布.
# g Generic 命令(non-type specific) like DEL, EXPIRE, RENAME, ...
# $ String 命令
# l List 命令
# s Set 命令
# h Hash 命令
# z set排序命令
# x 过期事件(键每次到期时生成的事件)
# e 驱逐事件(从maxmemory中驱逐键时生成的事件)
# t 流命令
# m Key-miss 事件(Note: It is not included in the 'A' class)
# A g$lshzxet的别名，因此“AKE”字符串表示所有的事件(除了由于其独特性而被排除在“A”之外的键错过事件)。"notify-keyspace-events"接受一个由0个或多个字符组成的字符串作为参数。空字符串表示禁用通知。
示例:从事件名称的角度来看，要启用列表和通用事件，请使用:
# notify-keyspace-events Elg示例2：获取订阅通道名称的过期密钥流__keyevent@0__：过期使用：
# notify-keyspace-events Ex默认情况下，所有通知都被禁用，因为大多数用户不需要此功能，而且该功能有一些开销。请注意，如果不指定K或E中的任何一个，则不会传递任何事件。
