前言
在数据爆炸的信息时代,为了防止数据库被巨大的流量所击垮,人们开始利用缓存,以此减少数据库的压力;而对于缓存的选型,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
网友评论