redis学习记录(3)redis高可用理解

一、主从复制存在的问题

       一旦主节点出现故障, 需要手动将一个从节点晋升为主节点, 同时需要修改应用方的主节点地址, 还需要命令其他从节点去复制新的主节点, 整个过程都需要人工干预。

二、高可用 redis sentinel

1、概述:

        Redis Sentinel是一个分布式架构, 其中包含若干个Sentinel节点和Redis数据节点, 每个Sentinel节点会对数据节点和其余Sentinel节点进行监控, 当它发现节点不可达时, 会对节点做下线标识。 如果被标识的是主节点, 它还会和其他Sentinel节点进行“协商”, 当大多数Sentinel节点都认为主节点不可达时, 它们会选举出一个Sentinel节点来完成自动故障转移的工作, 同时会将这个变化实时通知给Redis应用方。 整个过程完全是自动的, 不需要人工来介入。
 

它的主要功能有以下几点

  • 多个sentinel发现并确认master有问题
  • 选举出一个sentinel作为领导
  • 选出一个slave作为master
  • 通知其余slave成为新的master的slave
  • 通知客户端主从变化
  • 等待老的master复活成为新的master的slave

详细流程:https://www.jianshu.com/p/00a6d7cc82b2

 2、安装与配置

①配置开启主从节点

 7001端口配置,7002类似。

 有两个从节点

②配置开启sentinel监控主节点(sentinel是特殊的redis)

配置:

  • Sentinel节点的默认端口是26379。
  • sentinel monitor mymaster 127.0.0.1 7000 2配置代表sentinel-1节点需要监控127.0.0.1: 7000这个主节点, 2代表判断主节点失败至少需要2个Sentinel节点同意, mymaster是主节点的别名

启动sentinel

redis-sentinel redis-sentinel-26381.conf

 当三个Sentinel节点都启动后,拓扑结构图如下:

 注意:

  • 生产环境中建议Redis Sentinel的所有节点应该分布在不同的物理机上。
  • Redis Sentinel中的数据节点和普通的Redis数据节点在配置上没有任何区别, 只不过是添加了一些Sentinel节点对它们进行监控。
     

三、redis-sentinel实现原理

1、sentinel 集群通过三个定时监控任务完成对各个节点发现和监控。

1、每10秒每个sentinel对master和slave执行info

  • 发现slave节点
  • 确认主从关系

作用:

sentinel 集群可以得知 master 和 slave 的基本信息,①通过向主节点执行 info 命令,获取从节点的信息,所以 sentinel 节点不需要显式配置监控从节点,②当有新的从节点加入时都可以立刻感知出来,③当 master 节点故障或者故障转移后,可以通过 info 命令实时更新 redis 主从信息。

2、 每隔2秒,每个 sentinel 节点会向 redis 数据节点的__sentinel__:hello这个channel(频道)发送一条消息。每个sentinel都会订阅该频道。信息交互平台:信息交换、领导者选举

该定时任务的作用

  • 发现新的 sentinel节点:通过订阅主节点的__sentinel__:hello了解其他的 sentinel 节点信息,如果是新加入的 sentinel 节点,将该 sentinel 节点信息保存起来,并与该 sentinel 节点创建连接。
  • sentinel 节点之间交换主节点的状态,用做 master 下线和故障处理的 leader 选举的依据。

3、每隔1秒, 每个Sentinel节点会向主节点、 从节点、 其余Sentinel节点发送一条ping命令做一次心跳检测, 来确认这些节点当前是否可达。

通过定时发送ping命令,sentinel 节点对主节点、从节点、其余 sentinel 节点都建立起连接,实现了对每个节点的监控,这个定时任务是节点下线判定的重要依据

2、主观下线和客观下线

sentinel monitor mymaster 127.0.0.1 6379 2
                 master名                法定人数<quorum> 建议节点数/2+1,超过50%。让我想起了区块链
sentinel down-after-milliseconds mymaster 30000  #超时下线
                                  master名  30s
sentinel is-master-down-by-addr <ip> <port> <current_epoch> <runid>  #问一下别的sentinel是否master该下线了

 

1、主观下线

每个 sentinel 节点每隔1秒对主节点、从节点、其他 sentinel 节点发送 ping 命令做心跳检测,当这些节点超过
down-after-milliseconds没有进行有效回复,sentinel节点就会认为该节点下线,这个行为叫做主观下线。主观下线是某个 sentinel 节点的判断,并不是 sentinel 集群的判断,所以存在误判的可能。

2、客观下线

        当 sentinel 主观下线的节点是主节点时,该 sentinel 节点会通过sentinel ismaster-down-by-addr命令向其他 sentinel 节点询问对主节点的判断,当超过<quorum>个(quorum可配置)sentinel 节点认为主节点有问题,这时该 sentinel 节点会做出客观下线的决定,也就是大部分(超过50%)是 sentinel 节点都对主节点的下线做了同意的判定,那么这个判定就是客观的。

sentinel is-master-down-by-addr <ip> <port> <current_epoch> <runid>
·ip: 主节点IP。
·port: 主节点端口。
·current_epoch: 当前配置纪元。
·runid: 此参数有两种类型, 不同类型决定了此API作用的不同。
当runid等于“*”时, 作用是Sentinel节点直接交换对主节点下线的判定。
当runid等于当前Sentinel节点的runid时, 作用是当前Sentinel节点希望目标Sentinel节点同意自己成为领
导者的请求, 有关Sentinel领导者选举, 后面会进行介绍。

如果发送:sentinel is-master-down-by-addr 127.0.0.1 6379 0 *

返回三个参数:

  1. down_state: 目标Sentinel节点对于主节点的下线判断, 1是下线, 0是在线。
  2. leader_runid: 当leader_runid等于“*”时, 代表返回结果是用来做主节点是否不可达, 当leader_runid等于具体的runid, 代表目标节点同意runid成为领导者。
  3. leader_epoch: 领导者纪元。
     

3、故障转移前的领导者节点选举

当 sentinel 集群确认 master 下线,需要选举出一个 leader 节点来进行故障转移
选举:通过sentinel is-master-down-by-addr命令都希望成为领导者

  1. 每个做主观下线的Sentinel节点向其他Sentinel节点发送命令,要求将它设置为领导者。
  2. 收到命令的Sentinel节点如果没有同意通过其他Sentinel节点发送的命令,那么将同意该请求,否则拒绝。
  3. 如果该Sentinel节点发现自己的票数已经超过Sentinel集合半数且超过quorum ,那么它将成为领导者。
  4. 如果此过程有多个Sentinel节点成为了领导者,那么将等待一段时间重新进行选举。

 

4、故障转移(sentinel领导者节点做)

1、从slave节点中选取一个“合适的”节点作为新的master节点。

  • 选择slave-priority(优先级)最高的slave节点,如果存在则返回,不存在则继续。
  • 选择复制偏移量最大的slave节点,如果存在则返回,不存在则继续。
  • 选择runid最小的slave节点。

2、对上面的slave执行slave no one命令让它成为master节点。

3、向剩余的slave节点发送命令,让它们成为新的master的slave节点。复制master节点。

4、更新原来的master为slave,并一直“关注”,当它恢复后,命令它去复制新的master节点。

 四、读写分离

        从节点也可以用来扩展主节点的读能力,尤其是在读多写少的场景下。

        但是存在一个问题:从节点不是高可用的,如果从节点出现故障,与其相连的客户端获取不到服务。其次,主节点没有客观下线,客观下线只针对主节点

方法:

        在设计Redis Sentinel的从节点高可用时, 只要能够实时掌握所有从节点的状态(可以依赖Sentinel节点的消息通
知, 获取Redis数据节点的状态变化
), 把所有从节点看做一个资源池 , 无论是上线还是下线从节点, 客户端都能及时感知到(将其从资源池中添加或者删除) , 这样从节点的高可用目标就达到了。

读写分离架构图
  • 1
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
1.redis支持的数据结构 string list hash set zset(基本回答) 加分项:另外redis还对这几种数据结构做了扩展,如GEO对位置计算,hyperLogLog做统计,bitmaps:redis底层存储value值都是存储的二进制数据,redis提供bitmaps(位图)可以直接访问或修改底层存储的二进制数据 2.redis线程模型 redis是单线程实现。 3.redis 提供的持久机制 redis 支持rdb和aof两种持久机制,redis4.0后支持混合持久化。rdb是定时的持久机制,宕机有可能会丢失最后一次持久化之后存在数据丢失。aof是基于操作日志追加的持久机制。(基本回答) 加分项: 1.rdb持久化原理 原理是redis会单独创建(fork)一个与当前进程一模一样的子进程来进行持久化, 这个子线程的所有数据(变量。环境变量,程序程序计数器等)都和原进程一模一样,会先将数据写入到一个临时文件中, 待持久化结束了,再用这个临时文件替换上次持久化好的文件 2.他什么时候fork子进程,或者什么时候触发rdb持久化机制 shutdown时,如果没有开启aof,会触发 配置文件中默认的快照配置 执行命令save或者bgsave save是只管保存,其他不管,全部阻塞 bgsave: redis会在后台异步进行快照操作,同时可以响应客户端的请求,但是在调用fork函数时是阻塞的,很快,可以忽略不计 执行flushall命令 但是里面是空的,无意义 3.aof原理? 原理是将Reids的操作日志以追加的方式写入文件,读操作是不记录的 2.触发机制(根据配置文件配置项) no:表示等操作系统进行数据缓存同步到磁盘(快,持久化没保证) always:同步持久化,每次发生数据变更时,立即记录到磁盘(慢,安全) everysec:表示每秒同步一次(默认值,很快,但可能会丢失一秒以内的数据) 以下问题都是基本回答: 4.redis支持事务吗 redis可以说是半支持事务(假事务),提供了一些在一定程度上支持线程安全和事务的命令。例如:multi/exec watch inc等。但是redis的事务并不支持回滚,即可以两个命令可以同时提交执行,但是如果有失败,成功的也不会回滚 5.你们公司使用的是什么集群模式 看你写的项目经验,如果你们公司数据量特别大,公司用缓存牛逼,就说Rediscluster,小公司可以说哨兵集群 1.哨兵模式 基本回答:哨兵主要就是启动哨兵(redis特殊)节点,对主节点进行监控,如果半数以上发现ping主节点不通了,认为主节点挂了,则进行故障转移,就是选出一个从节点代替主节点 2.Rediscluster集群模式 基本回答:Rediscluster是一个高可用集群,它基于分片(对key进行crc16,然后对16384取余)的原理,可以把他理解为是由多组哨兵集群组成,但是它不依赖哨兵 6.缓存穿透 缓存穿透指的是使用不存在的key进行大量的高并发查询,这导致缓存无法命中,每次请求都要穿透到后端数据库系统进行查询,数据库压力过大。 常用解决方案:将空值缓存起来。 其他解决方案:使用布隆过滤器(guava 19开始已支持布隆过滤器) 备注:如果你可以理解太白老师讲的基于redis位图自己实现的布隆过滤器,可以说说,更加分 7.缓存击穿 缓存击穿是指缓存中没有但数据库中有的数据(一般是缓存时间到期),这时由于并发用户特别多,同时读缓存没读到数据,又同时去数据库去取数据,引起数据库压力瞬间增大,造成过大压力 解决方案:1.互斥锁 如果项目不会多部署则可以使用jvm锁,如果会多部署则使用分布式锁 8.缓存雪崩 缓存雪崩指缓存服务器重启或者大量缓存集中在某一个时间段内失效 常用解决办法: 1.主要就是要搭建高可用集群,保证机器的高可用。 2.对不同的数据使用不同的失效时间,甚至对相同的数据、不同的请求使用不同的失效时间。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值