今天来讲讲redis以下知识点,如有不当请多指教!
Redis持久化
主从复制
Sentinel机制
Redis Cluster
redis是基于内存
的,如果不想办法将数据保存在硬盘上,一旦redis重启(退出/故障),内存的数据将会全部丢失。
Redis提供了两种持久化方法:
RDB
(基于快照),将某一时刻的所有数据保存到一个RDB文件中。
AOF
(append-only-file),当Redis服务器执行写命令的时候,将执行的写命令保存到AOF文件中。
RDB
保存某个时间点的全量数据快照
SAVE
:阻塞Redis的服务器进程,知道RDB文件被创建完毕
BGSAVE
:Fork出一个子进程来创建RDB文件,不阻塞服务器进程,使用lastsave
指令可以查看最近的备份时间
注意:Redis服务器在启动的时候,如果发现有RDB文件,就会自动载入RDB文件(不需要人工干预)
优点: RDB是一个紧凑压缩的二进制文件,代表Redis在某个时间点上的数据快照,适合备份,全量复制等场景。 且加载RDB恢复数据远远快于AOF的方式。
缺点: 没办法做到实时持久化/秒级持久化,因为bgsave每次运行都要执行fork操作创建子进程,属于重量级操作,频繁执行成本过高。
//在n秒内修改m条数据时创建RDB文件
save 900 1
save 300 10
save 60 10000
stop-writes-on-bgsave-error yes //bgsave出错时停止写入
rdbcompression yes //压缩RDB文件
rdbchecksum yes //校验文件是否损坏
AOF
与RDB不一样的是,AOF
记录的是命令,而不是数据。
如何开启AOF?
只需在配置文件中将appendonly
设置为yes即可。
1、所有的写入命令追加到aof_buf
缓冲区中。
2、AOF会根据对应的策略向磁盘做同步操作。刷盘策略由appendfsync
参数决定。
3、定期对AOF文件进行重写。重写策略由auto-aof-rewrite-percentage
,auto-aof-rewrite-min-size
两个参数决定。
appendfsync参数有如下取值:
appendfsync always # 每次有数据修改发生时都会写入AOF文件。
appendfsync everysec # 每秒钟同步一次,该策略为AOF的默认策略。
appendfsync no # 从不同步。高效但是数据不会被持久化。
为什么要重写? 重写后可以加快节点启动时的加载时间
重写后的文件为什么可以变小? 进程内超时的数据不用再写入到AOF文件中 多条写命令可以合并为一个
1、手动触发
直接调用bgrewriteaof
命令
2、自动触发
先来看看有关参数:
auto-aof-rewrite-min-size
:执行AOF重写时,文件的最小体积,默认值为64MB。
auto-aof-rewrite-percentage
:执行AOF重写时,当前AOF大小(即aof_current_size)和上一次重写时AOF大小(aof_base_size)的比值。
只有当auto-aof-rewrite-min-size和auto-aof-rewrite-percentage两个参数同时满足时,才会自动触发AOF重写。
Redis将AOF重写程序放到子进程
里执行(BGREWRITEAOF
命令),像BGSAVE
命令一样fork出一个子进程来完成重写AOF的操作,从而不会影响到主进程。
AOF后台重写是不会阻塞主进程接收请求的,新的写命令请求可能会导致当前数据库和重写后的AOF文件的数据不一致!
为了解决数据不一致的问题,Redis服务器设置了一个AOF重写缓冲区
,当子进程完成重写后会发送信号让父进程将AOF重写缓冲区的数据写到新的AOF文件。
RDB和AOF并不互斥,它俩可以同时使用。
RDB的优点:载入时恢复数据快、文件体积小。 RDB的缺点:会一定程度上丢失数据(因为系统一旦在定时持久化之前出现宕机现象,此前没有来得及写入磁盘的数据都将丢失。)
AOF的优点:丢失数据少(默认配置只丢失1秒的数据)。 AOF的缺点:恢复数据相对较慢,文件体积大
如果Redis服务器同时开启了RDB和AOF持久化,服务器会优先使用AOF文件来还原数据
(因为AOF更新频率比RDB更新频率要高,还原的数据更完善)
单机即在一台机器上部署一个redis节点,主要会存在以下问题: 1、如果发生机器故障,例如磁盘损坏,主板损坏等,未能在短时间内修复好,客户端将无法连接redis 2、Redis的内存是有限的,可能放不下那么多的数据 3、单台Redis支持的并发量也是有限的
如图上面是master节点
,下面是slave
节点,即主节点和从节点。从节点也是可以对外提供服务的,主节点是有数据的,从节点可以通过复制操作将主节点的数据同步过来,并且随着主节点数据不断写入,从节点数据也会做同步的更新。
整体起到的就是数据备份的效果
除了一主一从模型之外,redis还提供了一主多从的模型,也就是一个master可以有多个slave,也就相当于有了多份的数据副本。
除了作为数据备份,主从模型还能做另外一个功能,就是读写分离。 让master节点负责提供写服务,slave节点提供读服务,而将数据读取的压力进行分流和负载,分摊给所 有的从节点。
slaveof 198.162.88.66 6379
执行该命令使当前redis节点成为指定redis节点的从节点,此复制命令是异步
进行的,redis会自动进行后续数据复制的操作
如果想取消从节点可以执行 slave of on one
命令
2、修改配置
# 配置主节点的IP和端口号
slaveof ip port
# 从节点只做读的操作,保证主从数据的一致性
slave-read-only yes
redis每次启动的时候都会有一个随机的ID,作为一个标识,这个ID就是runid,当然重启之后值就改变了。
假如端口为6380的redis去复制6379,知道runid
后,在6380上做一个标识,如果runid
改变了,说明主可能重启了或者发生了其它变化,这时候就可以做一个全量复制把数据同步过来。或者第一次启动时根本不知道6379的runid
,也会进行全量复制
偏移量:数据写入量的字节 比如主执行set hello world,就会有一个偏移量,然后从同步数据,也会记录一个偏移量 当两个偏移量达到一致时候,实际上数据就是完全同步的状态。
全量复制主节点会将RDB文件也就是当前状态去同步给slave,在此期间主节点新写入的命令会单独记录起来,然后当RDB文件加载完毕之后,会通过偏移量对比将这个期间产生的写入值同步给slave,这样就能达到数据完全同步的效果
全量复制过程
psync
,是做同步的命令,它可以完成全量复制和部分复制的功能,当启动slave节点时,它会发送psync
命令给主节点,需要传递两个参数,runid
和offset
(偏移量),也就是从节点向主节点传递主节点的runid以及自己的偏移量,对于第一次复制而言,就直接传递?和 -1,当然这个参数是由slave内部传的。bgsave
生成RDB文件,并且在此期间新产生的写入命令会被记录到repl_back_buffer
(复制缓冲区)执行全量复制除了开销大之外,还会有个问题: 假如master和slave网络发生了抖动,那一段时间内这些数据就会丢失,对于slave来说这段时间master更新的数据是不知道的。最简单的方式就是再做一次全量复制,从而获取到最新的数据,在redis2.8之前是这么做的。
redis2.8之后提供部分复制,如果发生类似网络抖动,可以有这样一种机制将这种损失降低到最低,如何实现的?
部分复制过程
通过部分复制有效的降低了全量复制的开销。
Sentinel
(哨兵)是用于监控redis集群中master状态的工具,是Redis 的高可用性解决方案,sentinel哨兵模式已经被集成在redis2.4之后的版本中。
Sentinel系统可以监视一个或者多个redis master服务,以及这些master服务的所有从服务;当某个master服务下线时,自动将该master下的某个从服务升级为新的master服务,替代已下线的master服务继续处理请求,等挂掉的主服务器重连上来,会将它变成从服务器。
Sentinel在内部有3个定时任务
1)每隔10秒——每个sentinel会对master和slave执行info命令,这个任务主要用来发现slave节点和确认主从关系。
2)每隔2秒——每个sentinel通过master节点的channel交换信息(pub/sub)。master节点上有一个名为__sentinel__:hello
的发布订阅的频道。sentinel节点通过__sentinel__:hello频道进行信息交换(对节点的"看法"和自身的信息),达成共识。
3)每隔1秒——每个sentinel对其他sentinel和redis节点执行ping操作(相互监控),这个其实是一个心跳检测,是失败判定的依据。
判断主服务器是否下线有两种情况:
主观下线
Sentinel会以每秒一次的频率向与它创建命令连接的实例(包括主从服务器和其他的Sentinel)发送PING命令,通过PING命令返回的信息判断实例是否在线 如果一个主服务器在down-after-milliseconds毫秒内连续向Sentinel发送无效回复,那么当前Sentinel就会主观认为该主服务器已经下线了。
客观下线
当Sentinel将一个主服务器判断为主观下线以后,为了确认该主服务器是否真的下线,它会向同样监视该主服务器的Sentinel询问,看它们是否也认为该主服务器是否下线。 如果足够多的Sentinel认为该主服务器是下线的,那么就判定该主服务为客观下线,并对主服务器执行故障转移操作。
在redis-sentinel的conf文件里有这么两个配置:
1)sentinel monitor
四个参数含义:
masterName
这个是对某个master+slave组合的一个区分标识。
ip
和 port
就是master节点的 ip 和 端口号。
quorum
这个参数是进行客观下线的一个依据,意思是**至少有 quorum 个sentinel主观的认为这个master有故障,才会对这个master进行下线以及故障转移。**因为有的时候,某个sentinel节点可能因为自身网络原因,导致无法连接master,而此时master并没有出现故障,所以这就需要多个sentinel都一致认为该master有问题,才可以进行下一步操作,这就保证了公平性和高可用。
2)sentinel down-after-milliseconds
这个配置其实就是进行主观下线的一个依据,表示:如果这台sentinel超过timeout这个时间都无法连通master包括slave的话,就会主观认为该master已经下线。
当一个主服务器被认为客观下线以后,此时需要一个Sentinel服务器对该服务器进行处理,因此监视这个下线的主服务器的各个Sentinel会进行协商,选举出一个领头的Sentinel,领头的Sentinel会对下线的主服务器执行故障转移操作。
选举领头Sentinel的规则也比较多,总的来说就是先到先得(哪个快,就选哪个)
注意:挑选某一个从服务器作为主服务器也是有策略的,大概如下:
(1)跟master断开连接的时长 (2)slave优先级 (3)复制offset大小 (4)run id
Redis3.0版本之前,可以通过Redis Sentinel(哨兵)来实现高可用,从3.0版本之后,官方推出了Redis Cluster
,它的主要用途是实现数据分片,并且实现高可用。
在Redis Sentinel模式中,每个节点需要保存全量数据,冗余比较多,而在Redis Cluster模式中,每个分片只需要保存一部分的数据,
Redis Cluster每个节点都保存各自的数据和整个集群的状态。每个节点都和其他所有节点连接,而且这些连接保持活跃,这样就保证了我们只需要连接集群中的任意一个节点,就可以获取到其他节点的数据。
Redis Cluster的具体实现细节是采用了Hash槽
的概念,集群会预先分配16384
个槽,并将这些槽分配给具体的服务节点,通过对Key进行CRC16(key)%16384
运算得到对应的槽是哪一个,从而将读写操作转发到该槽所对应的服务节点。当有新的节点加入或者移除的时候,再来迁移这些槽以及其对应的数据。在这种设计之下,我们就可以很方便的进行动态扩容或缩容。
Redis Cluster为了保证数据的高可用性,加入了主从模式,一个主节点对应一个或多个从节点,主节点提供数据存取,从节点则是从主节点拉取数据备份,当这个主节点挂掉后,就会有这个从节点选取一个来充当主节点,从而保证集群不会挂掉。
有关redis集群的安装配置在这里就不多说了,在这里对先对redis cluster有个了解,日后再来补充。
如果这篇文章对您有所帮助,或者有所启发的话,求一键三连:点赞、转发、收藏,您的支持是我坚持写作最大的动力。