分类：Redis| 发布时间：2019-04-11 00:01:00
本文接着上一篇 Redis 配置详解（三） 继续讲解 Redis 的相关配置选项。
警告：Redis 集群可以认为是稳定的，但是在将其标记为 “成熟” 之前，我们需要等待相当部分的用户将其部署在生产环境。
cluster-enabled yes
只有那些以集群的模式启动的节点才能成为 Redis 集群的一部分，普通的 Redis 实例不能成为 Redis 集群的一部分。 为了让 Redis 实例成为集群的节点，需要将 cluster-enabled 设置为 yes。
cluster-config-file nodes-6379.conf
每个集群节点都有一个集群配置文件，这个文件不能手动修改，只能由 Redis 节点创建和更新。 每个 Redis 集群节点需要不同的集群配置文件，需要确保同一个系统运行的不同 Redis 实例使用了不同的名称的集群配置文件。
cluster-node-timeout 15000
集群节点的超时时间，以毫秒为单位，当一个节点无法连接超过此选项配置的时间后， 就可以认为此节点处于失败状态。
其他的内部时间限制是此配置值的整数倍。
cluster-replica-validity-factor 10
当一个 master 处于失败状态，而它的 replica 节点数据太旧的情况下不会进行 failover。
没有一个简单的方法判断 replica 节点的 "data age"，因此需要以下方法来检查：
第二点可以由用户进行调整。当 replicas 节点最后一个与 master 节点交互的时间超过以下时间时，replicas 不会进行 failover。
(node-timeout * replica-validity-factor) + repl-ping-replica-period
比如 node-timeout 为 30 秒，而 replica-validity-factor 为 10，并且假设 repl-ping-replica-period 为 10 秒， 当 replica 最后与 master 交互的时间超过 310 秒时，replica 不会尝试 failover。
replica-validity-factor 设置的过大会导致拥有陈旧数据的 replicas 通过 failover 成为 master， 当这个值太小则会阻止集群选出一个 replica。
为了最大的可用性，可以将 replica-validity-factor 设置为 0， 表示 replicas 总是尝试 failover 成为 master 而不管最后一次与 master 交互的时间。
0 是保证所有集群的所有分区总是能痊愈并且继续提供服务的唯一选择。
cluster-migration-barrier 1
集群的 replicas 节点可以迁移到裸奔的 master 节点（就是没有 replicas 节点的 master 节点）。 当裸奔的 master 节点发生故障后不能进行 failover，因此这个功能提高了整个集群的抗故障能力。
replicas 节点只有在迁移到裸奔的 master 节点后，旧的 master 依然有给定数量的 replicas 节点才能进行迁移。 这个给定数量就是 "migration barrier"，由 cluster-migration-barrier 设置。 cluster-migration-barrier 为 1 表示 replicas 只有在迁移后旧的 master 节点至少还有一个可工作的 replicas 节点才进行迁移。 这个值一般设定为你希望每个 master 需要多少个 replicas 节点。
这个选项的默认为 1。如果你想要禁止迁移只需要将这个选项的值设置为一个很大的数即可。 设置为 0 只有在调试的时候才有用，在生产环境使用这个值是很危险的。
cluster-require-full-coverage yes
默认情况下 Redis 集群只要发现有一个 hash slot 未被覆盖（没有可用的节点为其提供服务）则会停止提供查询服务。 因此当集群发生部分故障（比如部分的 hash slot 未被覆盖），则会导致整个集群都无法工作。 当所有的 slots 再次被覆盖后，集群会自动恢复到可用状态。
如果你希望在集群发生故障时可用的部分依然可以提供查询服务，可以将 cluster-require-full-coverage 的值设置为 no。
cluster-replica-no-failover no
这个选项用于控制 master 发生故障时是否自动进行 failover。
当设置为 yes 后 master 发生故障时不会自动进行 failover，这时你可以进行手动的 failover 操作。
# 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 集群自动检测机制。 若 bus port 未设置，则会将其设置为 port + 10000。
slowlog-log-slower-than 10000
slowlog-max-len 128
慢查询日志表示当一个查询的运行时间超过设置的时间时，系统会将其记录在慢查询日志中。 这个运行时间只包括执行命令需要的时间（只有这个阶段线程是处于阻塞状态并且无法为其他请求提供服务）， 不包括 I/O 操作，比如和客户端通讯，发送响应请求等。
你可以设置慢查询日志的两个参数：一个是以微秒为单位的执行时间，超过这个时间的命令将会被记录下来， 另一个选项是慢查询日志的大小（就是一共会保存多少条慢查询日志）。 当一个新的命令需要被记录到慢查询日志并且当前慢查询日志的条数已经到达限制时，会先将最旧的慢查询日志移出队列。
slowlog-log-slower-than 为负数时表示禁用慢查询日志，0 表示记录所有的命令。
slowlog-max-len 没有上限，因此需要注意设置此值的大小，以免消耗过多的内存。
可以通过 SLOWLOG RESET 回收慢查询日志所消耗的内存。
latency-monitor-threshold 0
Redis 延迟监视子系统收集的阀值，单位为毫秒，默认值为 0。 Redis 延迟监视子系统在运行时对不同的操作进行采样，以便收集与 Redis 实例延迟相关的数据。
用户可以通过 LATENCY 命令以图表和报告的形式获取延迟相关信息。
系统只会记录时间大于等于 latency-monitor-threshold 的操作。 当 latency-monitor-threshold 设置为 0 表示关闭 Redis 延迟监视子系统。
默认情况下 Redis 延迟监视子系统是处于关闭状态的，当你的系统没有延迟问题，数据收集工作反而会造成性能冲击。 可以通过以下命令在运行的 Redis 系统中启用Redis 延迟监视子系统：
CONFIG SET latency-monitor-threshold <milliseconds>
notify-keyspace-events ""
Redis 通过 Pub/Sub 机制向客户通知 keyspace 中发生的事件。 这个特性的更多信息可以查看文档： http://redis.io/topics/notifications
举例来说，如果 keyspace 事件通知是启用的，并且有一个客户在数据库 0 执行了如下命令：
DEL foo
这时 Redis 会通过 Pub/Sub 机制发送如下两条消息：
PUBLISH __keyspace@0__:foo del
PUBLISH __keyevent@0__:del foo
可以通过配置 "notify-keyspace-events" 选项来让 Redis 选择发送哪些事件：
notify-keyspace-events 的值由上面的 0 到 N 个字符组成。空字符串表示禁止发送通知， 这是 notify-keyspace-events 的默认值。
举个例子：
notify-keyspace-events Elg
表示启用 list 命令和通用命令相关的事件通知。
notify-keyspace-events Ex
表示启用过期事件通知。
需要注意的是如果要启用事件通知至少要包含 K 或者 E，否则不会有事件发布。