redis的AOF、RDB、Sentinel介绍
一.写作目的
最近整理面试题,发现很多RDB、AOF以及Redis Sentinel的面试题,所以在这里记一下,内容基本都来自《Redis开发与运维》,推荐大家看一下这本书,写的非常好。
其中AOF、RDB是Redis的两种“持久化”机制,持久化指的是将数据从内存保存到磁盘介质中,当Redis服务器因为故障崩溃后,可以利用持久化的文件来会进行数据恢复。
二. RDB-内存快照
RDB持久化方式,是把内存中的数据生成快照保存到硬盘,可以通过手动和自动两种途径来触发RDB持久化:
RDB持久化后,保存的文件扩展名为*.rdb。
2.1 手动触发RDB持久化
手动触发,是指执行命令来触发持久化,又可分为两种,分别是save和bgsave两个命令,这两个命令存在相当大的区别:
save:阻塞当前Redis服务器,直到RDB过程完成为止,对于内存数据比较大的Redis服务器会造成长时间阻塞;
bgsave:Redis进程执行fork操作创建子进程,RDB持久化过程由子进程负责,完成后自动结束,阻塞只发生在fork阶段,时间很短;
2.2 自动触发RDB持久化
这种方式主要是通过配置来实现,在redis的配置文件中设置
save seconds changes # seconds秒内进行了changes次修改,则执行一次save命令 # 下面表示60秒内,如果发生了至少5次修改,则会进行RDB流程 save 60 5
需要注意的是,配置的是多少秒发生了多少次更改,只会对更改的次数计数,因为读操作不会更改数据。
2.3 优缺点
优点:保存全量数据,可以用来灾难恢复;
缺点:无法保证实时性,因为保存的是内存快照,在保存快照过程中,Redis仍在请求(可能包含数据修改),造成快照数据和实时数据存在差异;
三、AOF-文件追加
3.1 简单介绍
AOF是指将Redis收到的“写”命令记录到文件中(包含增删改命令,不包含读命令);
另外AOF默认会将命令追加到名为的appendonly.aof文件中。
3.2 AOF注意点
1.AOF方式并不是简单的将命令直接追加到aof文件中(会有一定格式);
2.AOF并不是每次都将命令追加到aof文件中(有一个缓冲区),可以设置配置项appendfsync的值always、no、everysec,其中always表示每次都要同步写入硬盘,no表示由系统控制,everysec表示每秒写一次;
3.不断将写命令追加到aof文件中,时间一长,aof文件就会特别大,需要定期对其进行压缩重写(比如多次del合并为一次del这种)。重写也有手动和自动两种方式,手动方式是执行bgrewriteaof,自动方式时进行配置。
四、Sentinel-哨兵
4.1 哨兵介绍
Redis Sentinel是一个分布式架构,其中包含若干个Sentinel节点和Redis 数据节点(包含master、slave节点);
每个Sentinel节点会对数据节点和其余Sentinel节点进行监控,当它发现节点不可达时,会对节点做下线标识。
如果被标识的是主节点,它还会和其他Sentinel节点进行“协商”,当大多数Sentinel节点都认为主节点不可达时,它们会选举出一个Sentinel节点来完成自动故障转移的工作,同时会将这个变化实时通知给Redis应用方。
4.2 主观下线
每个Sentinel节点会每隔1秒对主节点、从节点、其他Sentinel节点发送ping命令做心跳检测,当这些节点超过 down-after-milliseconds没有进行有效回复,Sentinel节点就会对该节点做失败判定,这个行为叫做主观下线。
4.3 客观下线
当Sentinel主观下线的节点是主节点时,该Sentinel节点会通过sentinel is-master-down-by-addr命令向其他Sentinel节点询问对主节点的判断,当超过<quorum>个数,Sentinel节点认为主节点确实有问题,这时该Sentinel节点会做出客观下线的决定,但是并没有进行故障转移。
4.4 哨兵Leader选举
使用Raft算法,选举过程如下(简要):
1.每个在线的Sentinel节点都有资格成为领导者,当它确认主节点主观 下线时候,会向其他Sentinel节点发送sentinel is-master-down-by-addr命令, 要求将自己设置为领导者。
2.收到命令的Sentinel节点,如果没有同意过其他Sentinel节点的sentinel is-master-down-by-addr命令,将同意该请求,否则拒绝。
如果该Sentinel节点发现自己的票数已经大于等于max(quorum, num(sentinels)/2+1),那么它将成为领导者。
如果此过程没有选举出领导者,将进入下一次选举。
4.5 故障转移
1.选择最好的从节点:优先级最高、偏移量最大(数据越完整)、runid最小。
2.将选定的从节点设为主节点,并将该新主节点设为其他从节点的主节点;
3.宕机恢复的旧主节点设为新主节点的从节点。