你用过哪些Redis集群？

前言

在数据爆炸的信息时代，为了防止数据库被巨大的流量所击垮，人们开始利用缓存，以此减少数据库的压力；而对于缓存的选型，redis则是深受人们青睐的佼佼者之一；为了保证redis在分布式环境中的高可用，目前我们常用的方式有有如下几种模式；下文会针对集群的搭建以及特性进行分析。

redis [单实例]

在介绍redis集群之前，我们先了解一下redis单实例的安装以及运用

• 编译安装的话需要提前安装gcc

$ wget http://download.redis.io/releases/redis-5.0.4.tar.gz
$ tar xzf redis-5.0.4.tar.gz
$ ln -s redis-5.0.4 redis
$ cd redis-5.0.4
$ make
$ make install

• 编译完成后，随后运行redis-server；使用默认配置文件

$ /src/redis-server

• 运行redis-cli

$ /src/redis-cli
127.0.0.1:6379> set hello world 
OK 
127.0.0.1:6379> get hello 
"world"

以上便是单实例的编译以及使用过程，这样的模式在开发过程中使用可能足够了，但是在生产环境运行还是有很大的隐患。

redis [主从模式]

在redis单实例中，redis实例既处理写请求，又处理读请求；当该实例宕机后，redis彻底失去读写的能力；为了减轻单一节点的读写压力，便发展产生了主从模式，相当于数据库的读写分离；这其中master主要用来处理写请求，slave则同步master的数据，用来处理读请求，一个master可以有多个slave节点。需要注意的是在这种模式中master节点只有一个。

主从模式

演示部署方案：

# 创建目录redis-msterslave，用于保存主从模式配置  
$ mkdir redis-msterslave  

新增master.conf配置

port 6379

新增slave01.conf配置

port 6380
slaveof 127.0.0.1 6379

新增slave02.conf配置

port 6381
slaveof 127.0.0.1 6379

依次启动master，slave节点

./src/redis-server ./redis-masterslave master.conf

./src/redis-server ./redis-masterslave slave01.conf

./src/redis-server ./redis-masterslave slave02.conf

master测试写入读取

$ ./src/redis-cli -p 6379
127.0.0.1:6379> set hello world
OK
127.0.0.1:6379> get hello
"world"

slave测试读取写入

$ ./src/redis-cli -p 6380
127.0.0.1:6380> get hello
"world"
127.0.0.1:6380> set hello world2
(error) READONLY You can't write against a read only replica.

主从模式中的master存在单点问题，当master宕机后，没有办法进行故障转移，导致整个集群不能正常的提供服务。

redis sentinel [哨兵模式]

主从模式的出现确实解决了redis单实例存在的问题，但是随之而来的便是新问题，主从模式无法进行故障转移，即master宕机后，虽然slave节点仍然能处理读请求，但是集群失去写入的能力；为实现故障转移，redis在2.8版本以后支持sentinel[哨兵模式];这种模式中用三个角色，分别是：master，slave，sentinel；其作用如下：

master：负责数据的读取写入
slave：负责数据的读取
sentinel：负责监控集群，当master宕机以后，从剩余的slave节点中选举一个成为master

哨兵模式

演示部署方案：

# 创建目录redis-sentinel，用于保存哨兵集群配置
$ mkdir redis-sentinel

新增master.conf为如下内容(演示集群，后续会有详细的配置文件说明)：

port 6379

新增slave01.conf;

port 6380
slaveof 127.0.0.1 6379

新增slave02.conf

port 6381
slaveof 127.0.0.1 6379

新增sentinel01.conf

port 26379
sentinel monitor mymaster 127.0.0.1 6379 2

新增sentinel02.conf

port 26380
sentinel monitor mymaster 127.0.0.1 6379 2

新增sentinel03.conf

port 26381
sentinel monitor mymaster 127.0.0.1 6379 2

其中：mymaster 为集群名称 ；127.0.0.1 6379 为master地址；2 为投票成员数量

依次启动master，slave，sentinel

./src/redis-server .s/redis-sentinel/master.conf

./src/redis-server ./redis-sentinel/slave01.conf

./src/redis-server ./redis-sentinel/slave02.conf

./src/redis-server ./redis-sentinel/sentinel01.conf --sentinel

./src/redis-server ./redis-sentinel/sentinel02.conf --sentinel

./src/redis-server ./redis-sentinel/sentinel03.conf --sentinel

启动客户端验证

根据集群名称从哨兵集群获取master地址

$ ./src/redis-cli -p 26379
127.0.0.1:26379> sentinel get-master-addr-by-name mymaster
1) "127.0.0.1"
2) "6379"

查看当前节点角色

$ ./src/redis-cli -p 6379
127.0.0.1:6379> info replication
role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=6380,state=online,offset=45616,lag=1
slave1:ip=127.0.0.1,port=6381,state=online,offset=45616,lag=1
master_repl_offset:45616
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:45615

我们发现6379节点有两个slave，那么我们对master停用，检查能否进行故障转移呢？

127.0.0.1:6379> shutdown save

查看6380节点的角色

$ ./src/redis-cli -p 6380
127.0.0.1:6380> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6381
master_link_status:up
master_last_io_seconds_ago:0
master_sync_in_progress:0
slave_repl_offset:2846344
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:d5f4ba1c6a2793478e5ea2bec07345c1f272068a
master_replid2:b44a368d0903b6ec965c340ce79bf8f8ba5c05ab
master_repl_offset:2846344
second_repl_offset:2844327
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1797769
repl_backlog_histlen:1048576

我们发现6381被选举成为master，而6380则变成了6381节点的slave；即完成了对6379的故障转移；我们重新启动6379节点，查看该节点的角色

$ ./src/redis-cli -p 6379
127.0.0.1:6379> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6381
master_link_status:up
master_last_io_seconds_ago:0
master_sync_in_progress:0
slave_repl_offset:2897404
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:d5f4ba1c6a2793478e5ea2bec07345c1f272068a
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:2897404
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2894974
repl_backlog_histlen:2431

从故障中恢复的6379节点重新以slave的身份加入集群。

这样的集群配置就真的万无一失了么？

redis cluster [集群模式]

通过搭建redis-sentinel集群，我们可以对master节点进行故障转移，但是master还是存在单点问题，如遇到写请求流量洪峰时，有可能逐个压垮master，导致集群失去服务能力；抑或是如遇网络抖动，master节点下线，新选举的slave节点并没有成功晋升为master，那么整个集群就会出去无主的状态，我们也称之为“脑裂”，导致整个集群失去写入能力。

为了能够解决以上问题，实现master的分布式部署以及负载均衡；redis3.0之后支持redis-cluster[集群模式]，集群总共定义了16384个槽位，数据通过哈希一致性算法，均匀的分布在集群的master上；例如现有3主3从的集群，master-A上分布着0-5460，master-B上分布着5461-10922，master-C上分布着10923-16383；而slave-A，slave-B，slave-C 分别作为其A、B、C的副本，当某个master下线以后，其对应的slave晋升成为master；进而保证数据的完整性。

集群模式

集群部署方案一：

我们可以利用redis下面的/utils/create-cluster来创建集群,它默认会创建三主三从的集群

$ cd /redis-5.0.4/utils/create-cluster
$ ./create-cluster start
$ ./create-cluster create
....

$ ./create-cluster stop

create-cluster start 会启动集群节点，这时所有节点都是master
create-cluster create 完成主从关系分配和数据槽位的分配
create-cluster stop 集群停止

集群部署方案二：

使用redis-trib.rb来创建管理集群，依赖Ruby环境

yum install ruby

创建redis-cluster目录用于存储配置文件

$ mkdir redis-cluster

节点的redis-n.conf基础配置文件

port 6379
cluster-enabled yes
cluster-config-file nodes-6379.conf
cluster-node-timeout 5000
appendonly yes

集群的运行至少需要3个master，我们创建对应的配置文件，修改以上配置文件的端口即可，如下

port 6380
cluster-enabled yes
cluster-config-file nodes-6380.conf
cluster-node-timeout 5000
appendonly yes

分别是redis-6379.conf，redis-6380.conf，redis-6381.conf，redis-6382.conf，redis-6383.conf，redis-6384.conf共计6个配置文件。

分别启动6个redis-server

../../src/redis-server ./redis-6379.conf

../../src/redis-server ./redis-6380.conf

../../src/redis-server ./redis-6381.conf

../../src/redis-server ./redis-6382.conf

../../src/redis-server ./redis-6383.conf

../../src/redis-server ./redis-6384.conf

随后使用redis-trib.rb来管理集群

../../src/redis-trib.rb create --replicas 1 127.0.0.1:6379 127.0.0.1:6380 127.0.0.1:6381 127.0.0.1:6382 127.0.0.1:6383 127.0.0.1:6384

--replicas 1 表示我们希望给每个master创建一个slave

如果你的Redis版本比较新的话，redis-trib.rb 管理集群的功能被redis-cli替代了；可以使用如下命令，则不需要依赖Ruby环境

./src/redis-cli --cluster create 127.0.0.1:6379 127.0.0.1:6380 127.0.0.1:6381 127.0.0.1:6382 127.0.0.1:6383 127.0.0.1:6384 --cluster-replicas 1

集群创建成功会输出

[OK] All 16384 slots covered

以上便是redis-cluster模式的演示方案，演示集群建立的是3主3从的集群，其中每个master对应一个slave；当master宕机后，slave会被选举成为master，旧的master从故障恢复后会以slave的角色加入集群。

redis 集群方案对比

对比要点	主从模式	哨兵模式	集群模式
写入单点	存在	存在	不存在
故障转移	不支持	支持	支持
是否分片	未分片	未分片	分片

通过对比我们发现，不管是主从模式还是哨兵模式，在写入上都存在单点问题；不过哨兵模式支持master故障转移（failover），而主从模式不支持；由于集群模式中每个master负责不同的槽位（slots），客户端在请求时根据key通过CRC16计算出所属的槽位，然后再请求到具体的redis实例，以此实现了分片，而主从模式，哨兵模式则没有实现。

综上，当业务场景中写请求较少，读请求较多时可以选用redis-sentinel模式；而当业务场景中写请求频繁，同时读取也比较频繁时可以选取redis-cluster模式。

以上便是Redis原生的集群搭建方式，当然业内还有其他的集群方式，例如Twitter利用代理服务器Twemproxy + Redis Sentinel 实现Redis集群，感兴趣的读者可以自行去查阅相关资料，我们这里就不做过多的描述。

redis 常用配置

以下是常用配置介绍，了解这些常用配置对你理解主从复制，以及数据持久化有很大的帮助
英文全量：https://raw.githubusercontent.com/antirez/redis/4.0/redis.conf
中文全量：https://github.com/sexylowrie/redis-teach/blob/master/redis-cn.conf

# Redis 配置文件示例
# Redis configuration file example.
# 启动使用配置文件
# ./redis-server /path/to/redis.conf

# 注意单位
# 1k => 1000 bytes
# 1kb => 1024 bytes
# 1m => 1000000 bytes
# 1mb => 1024*1024 bytes
# 1g => 1000000000 bytes
# 1gb => 1024*1024*1024 bytes
# 单位对于大小写是不敏感的 1GB 1Gb 1gB 是相同的

################ INCLUDES #################
# 可以引入一个或多个配置文件，引入文件也可以包含其他的文件
#
# 注意include 不会被命令 "CONFIG REWRITE" from admin 或者哨兵，你最好在启动时就引# 入，而避免在运行时重写配置
#
# 如果想让include 覆盖配置文件中的配置，你最好将include置于配置文件的最后一行
# include /path/to/local.conf
# include /path/to/other.conf

################# MODULES ##################
#
# 在启动时加载模块，如果加载失败，redis会启动失败；可用可能是因为使用了多个加载模块指令
#
# loadmodule /path/to/my_module.so
# loadmodule /path/to/other_module.so

################# NETWORK ##################
# 默认的如果没有指定bind配置，redis将允许所有网络接入
# 允许多个地址使用bind配置
# bind 192.168.1.100 10.0.0.1
# bind 127.0.0.1 ::1
bind 127.0.0.1


# 保护模式是一种安全措施，为了防止redis实例暴露在互联网中，被随意的访问
# 以下条件将触发保护模式：
# 1) 没有设置bind 配置
# 2) 没有配置密码
#  redis server 将只接受IPV4，IPV6  127.0.0.1 and ::1 的连接
#
# 保护模式默认是开启的，如果你想使用其他地址访问，又不想配置密码，可以使用bind配置
protected-mode yes

# 连接监听端口，默认6379；设置为0将不监听
port 6379

# TCP 监听缓冲区
# 在高并发环境中，你需要设定更高的值来避免客户端连接缓慢的问题；
# 需要注意的是Linux内核默认配置也会影响该指标，所以你需要确保同时调高
# /proc/sys/net/core/somaxconn 与tcp_max_syn_backlogn 的值
tcp-backlog 511

# Unix socket.
# 指定Unix socket 请求连接地址，没有默认值；没有指定则不会监听
# unixsocket /tmp/redis.sock
# unixsocketperm 700

# 超时时间大于timeout，则关闭空闲连接；设置为0则不关闭
timeout 0

# TCP keepalive.
# 当值为非0时，用于发送ACKS用于保持通讯；主要有如下两个原因：
# 1） 发现掉线客户端
# 2） 保持与客户端的连接
# 
# 在Linux环境下，用指定的值作为单位去发送ACKS（心跳）
# 注意关闭连接需要双倍的时间
# 在其他内核环境下，发送的频率依赖内核参数的设置
# 从3.2.1开始，默认值是300
tcp-keepalive 300

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

# Redis默认不会后台运行，通过设置为yes可以使其后台运行
# 注意Redis后台运行时将会在/var/run/创建一个名为redis.pid的文件
daemonize no

# 指定pid文件，Redis启动时创建，退出时移除
# 非后台运行状态不会创建，后台运行则会创建，没有指定默认是：/var/run/redis.pid
#
# 即使Redos不能成功创建pid文件，服务也会正常启动
pidfile /var/run/redis_6379.pid

# 指定日志级别
# 可以被指定为如下值：
# debug 用于开发、测试(a lot of information, useful for development/testing)
# verbose 详细
# notice 适用于生产环境，日志级别比较合适
# warning 只重要的，警告信息会被记录
loglevel notice

# 指定日志名称，也可以指定为空字符串
logfile ""

# 开启系统日志，只需设定syslog-enabled yes
# syslog-enabled no

# 设置系统日志id.
# syslog-ident redis

# 设置系统日志工具，必须为 USER 或者 LOCAL0-LOCAL7
# syslog-facility local0

# 设置数据库的数量，默认的数据库序列是0 ，可以通过 select<dbid>来切换
# dbid的取值范围是0 到 databases-1
databases 16

# 展示Redis LOGO
always-show-logo yes

################# SNAPSHOTTING ##################
# 数据快照:
#   save <秒数><改变值数量>
#   save <seconds> <changes>
# 
#   save 900 1 900秒内有1个key改变则保存
#   save 300 10 300秒内有10个key改变则保存
#   save 60 10000 60秒内有10000个key改变则保存
#   
#   你也可以通过注释掉save，来使其失效
#  
#   你也可以通过设置为空字符串来移除预先的配置，如下：
#   save ""
save 900 1
save 300 10
save 60 10000

# 当Redis进行写RDB快照失败后是否继续工作，yes：不继续工作；no：继续工作
stop-writes-on-bgsave-error yes

# 是否使用LZF压缩dump.rdb
# 默认使用yes会一直压缩，但是会有CPU消耗
# 设置为no，不会消耗CPU，但是需要更多的磁盘空间
rdbcompression yes

# Redis 5.0 版本开始，RDB文件末尾会防止一个CRC64 的校验数，一次来保证容错性，
#但是会有大约10%的性能损耗；如果你追求更高的性能，则可以关闭这项设置；它会创建一个
#0的检验数，以此来跳过检查
rdbchecksum yes

# rdb文件名称
dbfilename dump.rdb

# 工作目录
# RDB 跟 AOF 文件都会保存在该路径下
dir ./

################# REPLICATION ##################
# 主从复制，使用slaveof 可以指定一个Redis实例作为另一个节点的slave.
# 关于主从复制，有如下几点你需要知道：
# 1) Redis复制是异步的，但是你可以配置当一个master的slave节点数少于某个数值时，停止接收写入 
# 2) 如果复制链接断开较短的时间，Redis Slave能够与master重新同步，你可以根据自己的需要设置积压值
# 3) 复制是自动的，不需要用户接入；当网络故障结束后，slave会自动重连的朱接单，并且跟master保持同步
#
# slaveof <masterip> <masterport>

# 如果master需要密码验证，那么slave访问master是需要进行密码验证
# masterauth <master-password>

# slave如果与master断开，它可能会有如下两种表现：
# 1) 如果slave-serve-stale-data 设置为yes (默认)，slave仍会响应客户端请求，
#但是可能会响应过期数据
# 2) if slave-serve-stale-data 设置为no，slave将会响应异常“SYNC with master #in progress”
#
slave-serve-stale-data yes

# 设置slave只读
slave-read-only yes

# 两种复制策略: disk or socket.
#
# -------------------------------------------------------
# WARNING: SOCKET 复制是实验性的
# -------------------------------------------------------
# 新增slave或者slave重新连接不能执行继续复制，需要执行全量复制，有如下两种方式
#
# 1) Disk: master会创建一个新的进程在硬盘上写RDB文件，然后将RDB文件传输给slave
# 2) Socket: master会创建一个新的进程通过socket传输给slave，而不使用磁盘
repl-diskless-sync no

# socket slave复制延迟时间，避免设置为0
repl-diskless-sync-delay 5

# 主从心跳时间间隔，默认为10秒
# repl-ping-slave-period 10

# 设置复制超时时间将用于以下途径
#
# 1) 批量IO操作.
# 2) master访问slave超时.
# 3) slave访问master.
#
# 一定要确认复制超时时间要大于主从心跳时间，负责一个时间周期内主slave只能传输少量数据
#
# repl-timeout 60
# 如果你配置为yes，Redis往slave发送数据将使用较小的数据包和占用较少的带宽；但是它也可能使slave出现延迟增加
#
# 如果你设置为no，数据延迟将会被减弱，相应的会占用较大的带宽；高并发环境中设置为yes也许是个不错的选择
repl-disable-tcp-nodelay no

# 设置复制积压大小；当slave断开一段时间，积压是一个缓冲区，为了保证slave重新连接时，不必进行全同步，而是同步断开后遗失的一部分
# 缓冲区大小越大，slave断开时间可以越长；当至少有一个slave连接时，缓冲区才会被分配。
# 
# repl-backlog-size 1mb

# 当slave与master超过一定时间后，缓冲区将会被释放；可以通过以下参数来设置时间；设置为0则表示，永远不释放。
#
# repl-backlog-ttl 3600

# slave有优先级是一个数字；用于哨兵节点选举slave成为master；值越低，成为master的概率越大
# 设置为0，则表示该节点永远不会被选举成为master，默认值是100
#
slave-priority 100

# 当master的连接的slave少于N时，并且slave落后M秒时；master将不在接收写入操作；需要有N个slave在线
#
# 如下示例要求，至少有3个slave在线并且落后小于等于10秒
# min-slaves-to-write 3
# min-slaves-max-lag 10
#
# 默认min-slaves-to-write是0；表示不会禁用写
# min-slaves-max-lag is set to 10.

# Redis master可以列出连接的slave的地址和端口；例如使用“INFO replication”命令；
# 可以通过以下选项来重写丛节点的ip以及端口
# slave-announce-ip 5.5.5.5
# slave-announce-port 1234

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

# 要求客户端进行密码验证，"foobared"是密码，客户端通过auth foobared 可以进行验证
#
# requirepass foobared

# 命令重命名
#
# 可以利用这项配置，将危险的命令重命名，防止被人猜测 
#
# rename-command CONFIG b840fc02d524045429941cc15f59e41cb7be6c52
#
# 重命名成空字符串，可以禁用该命令
# rename-command CONFIG ""
#
# 请注意重命名命令被记录在AOF文件或者传输给slave可能会导致一些问题

################ CLIENTS ################

# 最大客户端连接数，默认是10000；超过改数量，新的连接将会返回错误max number of clients reached
# maxclients 10000

############### MEMORY MANAGEMENT ###############

# 设置内存使用限制字节数；当达到限制，redis将尝试maxmemory-policy来移除一些keys
# 如果Redis根据策略不可以移除keys，或者策略设置为noeviction；Redis将回复errors，
# 将停止像 like SET, LPUSH, and so on等操作，只支持GET 操作
# Redis通常是用LRU 或者 LFU cache 或者 noeviction
# 注意slave的缓冲区不计算在maxmemory之内，为了避免主机内存消耗尽，maxmemory可以设置的小一些
# maxmemory <bytes>

# 内存策略，即Redis将如何选择淘汰，当达到maxmemory时；你可以设置一下几种：
# volatile-lru -> lru移除过期keys
# allkeys-lru -> lru移除任何keys
# volatile-lfu -> lfu移除过期keys
# allkeys-lfu -> lfu移除任何keys
# volatile-random -> 随机移除过期
# allkeys-random -> 随意移除任何
# volatile-ttl ->  移除即将过期
# noeviction -> 不移除
#
# LRU means Least Recently Used 最近使用
# LFU means Least Frequently Used 最常使用
#
# 经过以上任何策略都没有可移除的keys时，Redis将会在写操作时返回error
#
#       以下写操作: 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
#
# 默认是以下淘汰策略：noeviction
#
# maxmemory-policy noeviction

# LRU，LFU，TTL 算法检测的样本数量
# maxmemory-samples 5

############# LAZY FREEING ##################

# Redis 有两种删除方式；其中一种是：DEL 它是同步阻塞的删除方式；这意味着删除时间复杂度较低的O(1),O(log_N)的数据时间消耗较小
# 但是删除一个数以百万计的集合数据时，Redis将阻塞非常长的时间。
# 基于以上原因，Redis也提供了非阻塞的删除方式：例如：UNLINK，ASYNC，FLUSHALL，FLUSHDB等命令用于异步的减少内存
#

# DEL，UNLINK，ASYNC，FLUSHALL，FLUSHDB 这些指令是用户控制的；然而Redis以下情节中又必须删除Keys或者清空整个库在：
# 1) 由于maxmemory或者maxmemory policy 进行淘汰
# 2) 数据过期
# 3) 数据已存在
# 4) 复制期间，slave需要全量复制，将会清空原有从库数据
#
# 以上操作默认都是以阻塞的方式进行的，你也可以通过配置使其以非阻塞的方式进行
lazyfree-lazy-eviction no
lazyfree-lazy-expire no
lazyfree-lazy-server-del no
slave-lazy-flush no

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

# 默认的Redis会保存数据在磁盘上，这种方式在需要应用中都是一种不错的方式，但是Redis进程出现问题
# 或者断电都将导致丢失几分钟的数据；AOF是一种替代的方式，它将提供更加优秀的持久化方式；使用AOF
# 默认的持久化策略将只丢失1秒的数据。
# 
# AOF和RDB持久化可以同时被应用，但是出现问题，重新启动Redis时，AOF文件将首先被加载
# Please check http://redis.io/topics/persistence for more information.

appendonly no

# aof文件名

appendfilename "appendonly.aof"

# AOF支持以下几种模式
# no: 不主动刷盘，交由操作系统在合适时机处理；丢失数据不可控制
# always: 每次写操作之后刷盘；慢但是安全性高
# everysec: 每秒刷盘一次，比较适宜；默认
#
# More details please check the following article:
# http://antirez.com/post/redis-persistence-demystified.html
#
# appendfsync always
appendfsync everysec
# appendfsync no

# AOF重写或者BGSAVE会执行大量磁盘IO，当AOF刷盘策略设置为always或者everysec时，在一些Linux配置中fsync()调用将会阻塞Redis太久
# 设置为yes，意味着在BGSAVE或者BGREWRITEAOF期间不会对新的写入执行fsync()调用；这意味着有可能造成丢失30秒的数据
# 如果对延迟要求比较高，可以将改值设置为yes；否则还是设置为no，这将保证你的数据有更好的持久性

no-appendfsync-on-rewrite no

# Redis可以自动重写AOF文件，当AOF的大小增长到一定比例
# 工作原理：Redis会记录上次AOF文件重写后的大小，会拿文件当前大小跟基础大小比较，当文件大小达到指定比例，将触发重写
# 以下分别是设定重写比例以及基础文件大小
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

# Redis启动阶段加载的AOF数据，但是AOF文件可能是不完整的；当Redis运行时突然宕机，或者挂载的ext4文件系统掉线都有可能造成AOF文件不完整
# aof-load-truncated设置为yes，Redis将尽可能多的加载数据，Redis可以继续运行；
# 设置为no，则必须要求用户使用“redis-check-aof”单元来修复AOF文件，否则无法正常运行。
aof-load-truncated yes

# 当重写AOF文件时，Redis可以使用RDB作为一个基准，用于快速重写和恢复；当开启时AOF文件将结合两种文件结构如下所示：
#   [RDB file][AOF tail]
# 当加载时识别出AOF文件已“REDIS”开头，会先加载RDB文件，然后继续加载AOF文件；
# 默认设置为no，优先加载AOF文件是默认配置
aof-use-rdb-preamble no


############### LUA SCRIPTING  #################
# lua脚本最大执行时间，单位毫秒；设置为0，将无限制
lua-time-limit 5000

############## REDIS CLUSTER  #################
# 开启集群，默认是不开启的
# cluster-enabled yes

# 配置文件名称；每个cluster节点有一个配置文件；此文件不需要手动配置，有Redis自动创建和更新；
# cluster-config-file nodes-6379.conf

# Cluster节点超过超时时间，将被称为failure 状态
# cluster-node-timeout 15000

# 如果slave的数据过于陈旧，那么它应该避免被选举成功master。
# 有如下两种检查方式，确认其数据是否陈旧：
# 1) 如果有多个salve节点可以进行故障转移，Slave节点间将会相互通信并进行排名，排名高的会优先成为Master
# 2) 比较每个单节点的Slave节点跟Master节点的交互时间；上次交互时间最久远的Slave节点将不会被选举出来
# 第2点用户可以调整
# cluster-slave-validity-factor 10

# 集群转移界限；默认是1；设置为0只用于DEBUG，在生产使用是非常危险的；禁用转移只需将其设置为一个很大的数字
# cluster-migration-barrier 1

# 默认如果集群不能覆盖全部插槽，集群将停止接收请求；如果你想让其继续工作可以设置为no
# cluster-require-full-coverage yes

# 设置为yes，可以防止Slaves进行故障转移，当然master还是可以手动故障转移；
# cluster-slave-no-failover no