• 企业400电话
  • 微网小程序
  • AI电话机器人
  • 电商代运营
  • 全 部 栏 目

    企业400电话 网络优化推广 AI电话机器人 呼叫中心 网站建设 商标✡知产 微网小程序 电商运营 彩铃•短信 增值拓展业务
    Redis Sentinel的基本搭建

    Redis Sentinel的概念

       我们知道Redis主从模式下,一旦主节点由于故障不能提供服务,需要人工将从节点晋升为主节点,同时还要通知应用方更新主节点的地址。然后在很多应用场景下这种故障处理的方式是无法接受的,应用程序需要实时感知当前的可用节点。为了解决这个问题,Redis Sentinel应运而生,也称之为"哨兵"。

       介绍sentinel之前,先来了解几个redis的概念,

    主节点master:Redis进程,主服务

    从节点slave:redis进程,从服务

    Redis数据节点:主节点和从节点

    Sentinel节点:监控Redis数据节点,独立的sentinel进程

    Sentinel节点集合:若干Sentinel节点的抽象组合,若干sentinel节点进程

    Redis Sentinel:Redis高可用实现方案,sentinel节点集合和redis数据节点进程

    01 主从复制问题

    前面的文章中我们讲述了主从复制,可以将从节点作为主节点的灾备节点,今天我们来看主从复制带来的问题:

    1、一旦主节点发生故障,从节点晋升为主节点的过程和应用调整新主节点的过程,都需要人为干预

    2、主节点的写能力容易受到单机的限制

    3、主节点的存储能力容易受到单机的限制

       一种常见的方法是使用脚本来触发主从节点的角色切换,例如在一个一主两从的结构中,假设主节点master,从节点slave1,slave2,我们来看故障发生时架构的状态:

    1、主节点master故障,客户端连接失败,两个从节点复制失败

    2、选择一个主节点slave1,对其执行slave of no one命令使其成为主节点master2

    3、更新应用程序连接的节点为slave1的IP地址

    4、slave2以slave1为新的主节点,复制slave1上的命令

    5、待原来的master恢复之后,让它成为slave1的从节点。

    上述过程可以做成自动化的过程,但是需要考虑三点:a、要确保判断节点不可达的机制健全,否则容易出现误判断情况

    b、如果有多个从节点,如果保证只有一个从节点被晋升为主节点是个关键的问题

    c、通知客户端新的主节点的机制是否足够健壮

    02 Redis Sentinel的高可用机制

       Sentinel能够自动完成故障发现和故障转移,并及时通知应用方。这是它的核心价值所在。

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

    Redis Sentinel与Redis主从复制模式只是多了若干个sentinel节点,并没有对redis节点做特殊处理,这是很多redis开发和运维人员容易混淆的地方。

    二者架构图如下:

    在整个主服务故障到重新选择主服务的过程中,sentinel主要干如下几件事情:

    1、监控,sentinel节点会定期检测redis数据节点,其余sentinel节点是否可达

    2、通知,sentinel节点会将故障转移的结果通知给应用方。

    3、主节点故障转移:实现从节点晋升为主节点并维护后续正确的主从关系

    4、配置提供者:在redis sentinel结构中,客户端在初始化的时候连接的是sentinel节点集合,从中获取主节点信息

       上面的架构图中不难发现sentinel也是多个的,这样的好处有两个:

    1、可以保证sentinel的健壮性,一个sentinel挂了,不影响整个集群的功能。

    2、对于节点的故障判断是多个sentinel同时判断出来的,有效的防止了误判

        sentinel节点本身其实就是独立的redis节点,只不过它们不存处数据,只支持部分命令。

        接下来,我们来看sentinel的部署和配置文件内容。

    03 sentinel部署

        sentinel部署之前,需要先有master和两个slave的一主两从架构:

    127.0.0.1:6379> info replication
    # Replication
    role:master
    connected_slaves:2
    slave0:ip=127.0.0.1,port=6380,state=online,offset=169,lag=1
    slave1:ip=127.0.0.1,port=6381,state=online,offset=169,lag=1
    master_repl_offset:183
    repl_backlog_active:1
    repl_backlog_size:1048576
    repl_backlog_first_byte_offset:2
    repl_backlog_histlen:182

      sentinel的部署配置文件:

    [root@VM_48_10_centos redis]# cat redis-sentinel-26379.conf 
    port 26379
    daemonize yes
    logfile "26379.log"
    dir "/usr/local/redis-3.0.7"
    sentinel monitor mymaster 127.0.0.1 6379 2

      其中,sentinel monitor mymaster代表sentinel要监控主节点6379,2代表判断主节点失败至少需要2个sentinel节点同意。

      其余两个sentinel的配置文件和这个大同小异,只需要修改对应端口和日志文件即可。sentinel启动命令如下:

    [root@VM_48_10_centos redis]# redis-sentinel redis-sentinel-26379.conf 
    [1] 7311
    [root@VM_48_10_centos redis]# redis-sentinel redis-sentinel-26380.conf 
    [1] 7366
    [root@VM_48_10_centos redis]# redis-sentinel redis-sentinel-26381.conf 
    [2] 7380
    [root@VM_48_10_centos redis]# 
    [root@VM_48_10_centos redis]# ps -ef|grep sentinel
    root      7312     1  0 22:51 ?        00:00:00 redis-sentinel *:26379 [sentinel]
    root      7367     1  0 22:52 ?        00:00:00 redis-sentinel *:26380 [sentinel]
    root      7381     1  0 22:52 ?        00:00:00 redis-sentinel *:26381 [sentinel]
    root      7405  5850  0 22:52 pts/7    00:00:00 grep --color=auto sentinel

    此时,重新查看26379这个sentinel的配置文件,会发现里面多了一些内容:

    [root@VM_48_10_centos redis]# cat redis-sentinel-26379.conf 
    port 26379
    daemonize yes
    logfile "26379.log"
    dir "/usr/local/redis-3.0.7"
    sentinel monitor mymaster 127.0.0.1 6379 2
    sentinel config-epoch mymaster 0
    sentinel leader-epoch mymaster 0
    sentinel known-slave mymaster 127.0.0.1 6380
    # Generated by CONFIG REWRITE
    sentinel known-slave mymaster 127.0.0.1 6381
    sentinel known-sentinel mymaster 127.0.0.1 26381 0a2c77616ef88282fa12ef7c8aca142a2473cd5a
    sentinel known-sentinel mymaster 127.0.0.1 26380 3ad6460bf5f4b01f277fdce3aa423d596993eec5
    sentinel current-epoch 0

       可以发现,sentinel之间已经进行了交互,并写入了配置文件中一些已经获取到的内容。

    使用命令info sentinel查看当前sentinel集群的信息:

    [root@VM_48_10_centos redis]# redis-cli -h 127.0.0.1 -p 26379 info sentinel
    # Sentinel
    sentinel_masters:1
    sentinel_tilt:0
    sentinel_running_scripts:0
    sentinel_scripts_queue_length:0
    master0:name=mymaster,status=ok,address=127.0.0.1:6379,slaves=2,sentinels=3

    以上就是Redis Sentinel的使用的详细内容,更多关于Redis Sentinel的资料请关注脚本之家其它相关文章!

    您可能感兴趣的文章:
    • 浅析Redis Sentinel 与 Redis Cluster
    • 基于SpringCloud手写一个简易版Sentinel
    • Spring Cloud Alibaba之Sentinel实现熔断限流功能
    • Sentinel实现动态配置的集群流控的方法
    • 解决redis sentinel 频繁主备切换的问题
    • Redis Sentinel的使用方法
    • Spring Cloud Alibaba 使用 Feign+Sentinel 完成熔断的示例
    • Java之SpringCloudAlibaba Sentinel组件案例讲解
    上一篇:SpringMVC集成redis配置的多种实现方法
    下一篇:Redis Sentinel的使用方法
  • 相关文章
  • 

    © 2016-2020 巨人网络通讯 版权所有

    《增值电信业务经营许可证》 苏ICP备15040257号-8

    Redis Sentinel的基本搭建 Redis,Sentinel,的,基本,搭建,