网站 建设平台分析,兼职网站的建设目标怎么写,wordpress是公益,个人 网站 备案Redis高级篇 —— 分布式缓存 文章目录 Redis高级篇 —— 分布式缓存1 Redis持久化1.1 RDB1.2 RDB的fork原理1.3 RDB总结1.4 AOF持久化1.5 RDB和AOF的对比 2 Redis主从2.1 搭建主从架构2.2 数据同步原理2.2.1 全量同步2.2.2 增量同步 3 Redis哨兵3.1 哨兵的作用和原理3.1.1 哨兵…Redis高级篇 —— 分布式缓存 文章目录 Redis高级篇 —— 分布式缓存1 Redis持久化1.1 RDB1.2 RDB的fork原理1.3 RDB总结1.4 AOF持久化1.5 RDB和AOF的对比 2 Redis主从2.1 搭建主从架构2.2 数据同步原理2.2.1 全量同步2.2.2 增量同步 3 Redis哨兵3.1 哨兵的作用和原理3.1.1 哨兵的作用3.1.2 服务状态监控3.1.3 选举新的master3.1.4 如何实现故障转移3.1.5 redis集群哨兵模式脑裂3.1.6 总结 3.2 RedisTemplate的哨兵模式 4 Redis分片集群4.1 分片集群结构4.2 散列插槽4.3 故障转移4.4 RedisTemplate访问分片集群 1 Redis持久化
1.1 RDB
RDB全称Redis Database Backup fileRedis数据备份文件也叫Redis数据快照。简单来说就是把内存中的所有数据都记录到磁盘中。当Redis实例故障重启后从磁盘读取快照文件恢复数据。
快照文件称为RDB文件默认是保存在当前运行目录。 Redis是单线程的 一旦主线程执行RDB就会阻塞所有Redis的命令。 而这个RDB是把数据写到磁盘写磁盘是比较慢的 当数据量比较大的时候写的时间就很长。 因此这个命令不推荐使用一般在Redis要停机前再使用。所以在Redis运行过程中 推荐使用bgsave后台异步执行 是由一个额外的子进程来执行的。 Redis停机会执行一次RDB。
Redis内部有触发RDB的机制可以在redis.conf文件中找到格式如下 RDB的其他配置也可以在redis.conf文件中设置 因此不用但是Redis用着用着突然停机导致数据没来得及保存。Redis自动会保存数据。
1.2 RDB的fork原理
bgsave开始时会frok主进程得到子进程子进程 共享 主进程的内存数据。完成fork后读取内存数据并写入 RDB 文件。 物理内存 可以理解为就是计算机中的内存条。Linux中进程不能直接操作物理内存但是每个进程都会被分配一个虚拟内存主进程只能操作虚拟内存而后操作系统会维护一个虚拟内存与物理内存之间的映射关系表这个表就称为 页表 。
所以主进程操作虚拟内存而虚拟内存基于页表的映射关系 到物理内存真正的存储位置。这样就能实现对物理内存的读写。
而执行frok操作时会启动一个子进程。fork过程不是把内存数据做拷贝仅仅是把页表做拷贝也就是把映射关系拷贝给子进程。而子进程和主进程有了相同的映射关系当子进程在操作自己的虚拟内存时因为映射关系和主进程一样所以能映射到和主进程一样的物理内存区域。就实现了子进程与主进程物理内存的共享。这样就无需拷贝内存中的数据直接享受内存共享这个速度就会变得非常快。这样主进程frok的时间就会尽可能短阻塞的时间也会短。
而后子进程就可以放心的读取自己内存的数据再写入到RDB文件中。
但是还有一个问题就是子进程在读的过程中此时主进程再写怎么办先再了解一下fork
fork采用的是copy-on-write技术
当主进程执行读操作时访问共享内存当主进程执行写操作则会拷贝一份数据执行写操作。 也就是说当子进程在读的时候如果主进程此时要写那么就会拷贝一份相同的数据比如数据Bfork时 会将物理内存中的Redis数据设置为只读模式然后对拷贝的数据副本进行读写页表的映射关系也会改变成新的数据副本。
这样其实还有一个问题就是如果子进程写的速度太慢了此时写的操作又各种各样极端情况下导致每个数据都拷贝了一个副本那么此时Redis内存就翻倍了本来16GB的现在32GB了。 所以Redis一般是要预留一些内存空间的一台服务器32G则肯定不能都给Redis存储数据这样容易导致做RDB时内存溢出。
1.3 RDB总结 写入数据时间久万一两次持久化的间隔短导致还没写完又开始新写了就导致数据丢失。
1.4 AOF持久化
AOF全称为Append Only File追加文件。Redis处理的每一个写命令都会记录在AOF文件 可以看做是命令日志文件。 比如设置了123首先会把对应数据保存在key value中而后再把命令写入到AOF文件中。
当Redis出现故障相要恢复数据只需要读取AOF文件把里面的命令从头到尾执行一遍数据就恢复了。
AOF默认是关闭的需要修改Redis.conf配置文件来开启AOF AOF的命令记录的频率也可以通过redis.conf文件来匹配。有三种方案下面三种
第一种方案是写key value和写入AOF文件一起执行完才算redis命令执行完绝对安全但是性能是最差的。
第二种方案性能比第一种方案好但是最多会丢失1s内的数据牺牲了一定的可靠性。
第三种方案性能最好但是安全性最差。 因为是记录命令AOF文件会比RDB文件大得多。而且AOF会记录对同一个key的多次写操作但只有最后一次写操作 才有意义。通过执行 bgrewriteaof 命令可以让AOF文件执行重写功能用最少的命令达到相同效果。 Redis也会在触发阈值时自动去重写AOF文件阈值也可以在redis.conf中配置 命令远远要大于数据再加上RDB会有压缩所以AOF文件体积要比RDB文件大
AOF也是异步的
1.5 RDB和AOF的对比
RDB和AOF各有自己的优缺点如果对数据安全性要求较高在实际开发中往往会结合两者来使用。 RDB文件小宕机后恢复速度快AOF反之。 RDB持久化一次间隔时间太长数据容易丢失
2 Redis主从
2.1 搭建主从架构
单节点Redis的并发能力是有上限的要进一步提高Redis的并发能力 就需要搭建主从集群实现读写分离 。 开启主从关系后就决定了主节点只能写从节点只能读的关系。 2.2 数据同步原理
2.2.1 全量同步
主从第一次同步是 全量同步 master如何判断slave是不是第一次来同步数据这里会用到两个很重要的概念
replication Id 简称replid是数据集的标记id一致则说明是同一数据集。每个master都有唯一的replidslave则会继承master节点的replid。offset 偏移量随着记录在repl_backlog中的数据增多而逐渐增大。slave完成同步时也会记录当前同步的offset。如果slave的offset小于master的offset说明slave数据落后于master需要更新。
因此slave做数据同步必须向master声明自己的replication Id 和 offsetmaster才可以判断到底需要同步哪些数据。
那么问题来了master如何判断slave节点是不是第一次来做数据同步
只要判断id相不相同就行了相同就不是第一次来不同就是第一次来。 2.2.2 增量同步
主从第一次同步是 全量同步 但如果slave重启后同步则执行 增量同步 注意 repl_baklog大小有上限。写满后会覆盖最早的数据。如果slave断开时间过久导致尚未备份的数据被覆盖则无法基于log做增量同步只能再次全量同步。
可以从以下几个方面来优化Redis主从集群
在master中配置repl-diskless-sync yes启用无磁盘复制避免全量同步时的磁盘IORedis单节点上的内存占用不要太大减少RDB导致的过多磁盘IO适当提高repl_baklog的大小发现slave宕机时尽快实现故障恢复尽可能避免全量同步限制一个master上的slave节点数量如果实在是太多slave则可以采用主—从-从链式结构减少master压力 3 Redis哨兵
前面介绍了slave节点宕机恢复后可以找master节点同步数据那么master节点宕机怎么办
如果做了Redis数据持久化那么重启一下是没问题可以恢复数据的继续当master。但是需要考虑的一点是在master Redis宕机的这一段时间内再重启数据恢复的过程当中用户是无法进行写操作的因为master挂了那么可用性就下降了。
解决方法 可以一直监控Redis集群状态一旦发现master宕机就立即让其中一个slave变成新的master因为slave一直在数据同步所以slave有master所有数据这样就可以无缝衔接就保证Redis集群一直健康的。对外来说什么故障都没发生过。等到原来的master恢复了就让其当slave就可以了。
这个检测和重启的动作就由哨兵来做。
3.1 哨兵的作用和原理
3.1.1 哨兵的作用
Redis提供了哨兵Sentinel机制来实现主从集群的自动故障恢复。哨兵的结构和作用如下
监控Sentinel会不断检查你的master和slave是否按期工作自动故障恢复 如果master故障Sentinel会将一个slave提升为master。当故障实例恢复后也以新的master为主。通知 Sentinel充当Redis客户端的服务发现来源当集群发生故障转移时会将最新信息推送给Redis的客户端。 就是其实Redis客户端也是通过Sentinel来知道集群中master的地址的一旦发生变更Sentinel会选一个新的master并把地址给Redis客服端。
3.1.2 服务状态监控
Sentinel基于心跳机制监测服务状态每个一秒向集群的每个实例发送ping命令
主观下线如果某sentinel节点发现某实例未在规定时间响应则认为该实例 主观下线。客观下线若超过指定数量quorum的sentinel都认为该实例主观下线则该实例 客观下线 。quorum值最好超过Sentinel实例数量的一半。
3.1.3 选举新的master
一旦发现master故障sentinel需要在slave中选择一个作为新的master选择依据是这样的
首先会判断slave节点与master节点断开时间长短如果超过指定值down-after-milliseconds * 10 则会排除该slave节点然后判断slave节点的salve-priority值可以在配置文件中配置越小优先级越高如果是0则永不参与选举如果slave-priority一样则判断slave节点的offset值 越大说明数据越新优先级越高。最后判断slave节点的运行id和大小越小优先级越高。其实完成以上几步剩下的slave都可以作为新的master节点最后这步就是定义一个选的唯一性规则实际都可以选了。
3.1.4 如何实现故障转移
当选中了其中一个slave为新的master后例如slave1故障的转移的步骤如下 sentinel给备选的slave1节点发送slaveof no one命令让该节点成为新的master该节点配置文件中就修改为了主节点 snetinel给所有其它slave发送slave of 192.168.150.101 7002命令让这些slave成为新的master的从节点开始从新第的master上同步数据。 最后sentinel将故障节点标记为slave在该节点对应的配置文件中将此节点修改为slave并告知其信master节点当故障节点恢复后会自动成为新的master的slave节点。 3.1.5 redis集群哨兵模式脑裂 由于网络原因主节点和哨兵处于不同的网络分区那么哨兵只能去监测从节点它监测不到主节点了。那么哨兵就会按照选举规则从从节点中选出一个新的主节点但是值得注意的是老的主节点还没有挂那么此时就有两个主节点了就像大脑分裂了一样。
现在就有问题了因为目前的客户端还连接的是老的master他会持续往老的主节点写入数据新的节点就不能同步数据因为网络还有问题。
假如现在网络正常了哨兵会将老的master强制降为slave并且这个salve还会从新的master中同步数据我们知道第一次同步数据是会先清空自己的数据的然后客户端从Sentinel中接收新的master节点地址并进行连接。这就尴尬了这个slave中原本作为master保存的数据都没了。脑裂问题就导致数据丢失了 redis中有两个配置参数 min-replicas-to-write 1 表示最少的salve节点为1个
就是说当主节点至少有一个从节点时才允许接收客户端的数据否则直接拒绝请求
min-replicas-max-lag 5 表示数据复制和同步的延迟不能超过5秒
通过这两个配置如果发生脑裂了达不到这两个要求就拒绝客户端的请求这样就能避免大量的数据丢失了。
3.1.6 总结 3.2 RedisTemplate的哨兵模式
在Sentinel集群监管下的Redis主从集群其节点会因为自动故障转移而发生变化Redis的客户端必须感知这种变化及时更新连接信息。Spring的RedisTemplate底层利用lettuce实现了节点的感知和自动切换
4 Redis分片集群
4.1 分片集群结构
主从和哨兵可以解决高并发读、高可用的问题但是依然有两个问题没有解决
海量数据存储问题高并发写的问题
使用分片集群可以解决上述问题分片集群特征
集群中有多个master每个master保存不同数据每个master都可以有多个slave节点master之间通过ping监控彼此健康状态这样连额外的哨兵也不用了客户端请求可以访问集群任意节点最红都会被转发到正确节点。 多个master可以储存海量数据并且高并发的读。每个master都有集群有对应的slave就可以高并发的读。
4.2 散列插槽
Redis会把每一个master节点映射到0~16383共16384个哈希槽hash slot上查看集群信息时就能看到 数据key不是与节点绑定而是与插槽绑定。redis会根据key的有效部分计算插槽值分两个情况
key中包含{}“且”{}“中至少包含1个字符”{}中的部分是有效部分key中不包含{}整个key都是有效部分。
例如key是num那么就根据num计算如果是{itcast}num则根据itcast计算。计算方式是利用CRC16算法得到一个hash值然后对16384取余得到的结果就是slot值。而每个节点包含不同的slot值一旦key映射到了对应的slot值它就知道自己对应的是哪个master节点上的key了。
之所以与插槽绑定不是直接与master节点绑定是因为万一master节点宕机或者集群扩容、伸缩可以将此节点对应的插槽直接绑定到另一个活着的节点上不至于跟着master节点一起丢失。这样数据跟着插槽走永远都能找到对应的位置。 最后这个放在同一个实例中很妙相同类型数据的key加个大括号大括号里数据都一样作为key的前缀。然后相同类型不同数据的后缀不一样这样就能都在一个slot插槽里且key不完全相同。
4.3 故障转移
分片集群虽然没有哨兵但是也有故障转移的功能。
当集群中有一个master宕机会发生什么呢 首先是该实例与其它实例失去连接 然后是疑似宕机 最后是确定下线自动提升一个slave为新的master
上面那种是自动的故障转移是有的节点意外宕机了自动选一个新的节点。
有的时候需要手动转移比如换一个更好的节点替代这个节点。
手动转移
利用cluster failover命令可以手动让集群中的某个master宕机切换到cluster failover命令的这个slave节点实现无感知的数据迁移。其流程如下 手动的Failover支持三种不同模式
缺省默认的流程如上图force省略了对offset的一致性校验takeover直接执行第5步忽略数据一致性、忽略master状态和其它master的意见
4.4 RedisTemplate访问分片集群
Spring的RedisTemplate底层同样基于lettuce实现了分布集群的支持 而使用步骤与哨兵模式基本一致 引入redis的starter依赖 配置分片集群地址 配置读写分离
