zoukankan      html  css  js  c++  java
  • redis哨兵&codis

    目录

    1. 什么是哨兵模式

    2. 哨兵集群

    3. Redis阐述容灾机制

    4. Redis哨兵原理

    5. Redis-sentinel集群

    6. redis主流集群方案

    7. codis

    1. 什么是哨兵模式

    哨兵模式是一种特殊的模式,首先Redis提供了哨兵的命令,哨兵是一个独立的进程,作为进程,它会独立运行。其原理是哨兵通过发送命令,等待Redis服务器响应,从而监控运行的多个Redis实例

    2. Redis哨兵集群(功能,作用)

      1. 监控(Monitoring):哨兵(sentinel)会不断地检查你的master和slave是否运作正常

      2. 提醒(Notification):当被监控的某个redis出问题时,哨兵可以通过API向管理员或者其他应用程序发送通知

      3. 自动故障迁移(Automatic failover):当一个master不能正常工作时,哨兵(sentinel)会开始一次自动故障迁移操作,它会将失效master的其中一个slave升级为新的master

    3. Redis重点阐述容灾机制

    当某个master服务下线时,所有的slave将无法同步数据,这对于redis集群就是灾难性的,此时哨兵自动将该master下的某个slave服务升级为master服务器替代已下线的master服务继续处理请求,这时灾难的局面就被扭转了回来,这就是容灾机制

    4. Redis哨兵-原理

    5. Redis-sentinel集群

    1、sentinel作用

    1. 当用Redis做主从方案时,假如master宕机,Redis本身无法自动进行主备切换
    
    2. 而Redis-sentinel本身也是一个独立运行的进程,它能监控多个master-slave集群,发现master宕机后能进行自动切换。

    2、sentinel原理

    1. sentinel负责持续监控主节点的健康,当主节挂掉时,自动选择一个最优的从节点切换成主节点
    
    2. 从节点来连接集群时会首先连接sentinel,通过sentinel来查询主节点的地址
    
    3. 当主节点发生故障时,sentinel会将最新的主节点地址告诉客户端,可以实现无需重启自动切换redis

    3、sentinel支持集群

    1. 只使用单个sentinel进程来监控redis集群是不可靠的,当sentinel进程宕掉后sentinel本身也有单点问题
    
    2. 如果有多个sentinel,redis的客户端可以随意地连接任意一个sentinel来获得关于redis集群中的信息。

    4、sentinel版本

    1. Sentinel当前稳定版本称为Sentinel 2,Redis2.8和Redis3.0附带稳定的哨兵版本
    
    2. 安装完redis-3.2.8后,redis-3.2.8/src/redis-sentinel启动程序 redis-3.2.8/sentinel.conf是配置文件。

    5、运行sentinel两种方式(效果相同)

    • 法1:redis-sentinel /path/to/sentinel.conf
    • 法2:redis-server /path/to/sentinel.conf --sentinel
    1. 以上两种方式,都必须指定一个sentinel的配置文件sentinel.conf,如果不指定,将无法启动sentinel。
    
    2. sentinel默认监听26379端口,所以运行前必须确定该端口没有被别的进程占用。

    6、sentinel.conf配置文件说明

    1. 配置文件只需要配置master的信息就好啦,不用配置slave的信息,因为slave能够被自动检测到
    
    2. 需要注意的是,配置文件在sentinel运行期间是会被动态修改的,例如当发生主备切换时候,配置文件中的master会被修改为另外一个slave。
    
    3. 这样,之后sentinel如果重启时,就可以根据这个配置来恢复其之前所监控的redis集群的状态。

    sentinel.conf配置文件注释

     1 '''1、sentinel monitor mymaster 127.0.0.1 6379 2'''
     2 #1)sentinel监控的master的名字叫做mymaster,地址为127.0.0.1:6379
     3 #2)当集群中有2个sentinel认为master死了时,才能真正认为该master已经不可用了
     4 
     5 '''2、sentinel down-after-milliseconds mymaster 60000'''
     6 #1)sentinel会向master发送心跳PING来确认master是否存活,如果master在60000毫秒内不回应PONG 
     7 #2)那么这个sentinel会单方面地认为这个master已经不可用了
     8 
     9 '''3、sentinel failover-timeout mymaster 180000'''
    10 #1)如果sentinel A推荐sentinel B去执行failover,B会等待一段时间后,自行再次去对同一个master执行failover,
    11 #2)这个等待的时间是通过failover-timeout配置项去配置的。
    12 #3)从这个规则可以看出,sentinel集群中的sentinel不会再同一时刻并发去failover同一个master,
    13 #4)第一个进行failover的sentinel如果失败了,另外一个将会在一定时间内进行重新进行failover,以此类推。
    14 
    15 '''4、sentinel parallel-syncs mymaster 1'''
    16 #1)在发生failover主备切换时,这个选项指定了最多可以有多少个slave同时对新的master进行同步
    17 #2)如果这个数字越大,就意味着越多的slave因为replication而不可用,这个数字越小,完成failover所需的时间就越长。
    18 #3)可以通过将这个值设为 1 来保证每次只有一个slave处于不能处理命令请求的状态。
    View Code

    7、配置传播

    1. 一旦一个sentinel成功地对一个master进行了failover,它将会把关于master的最新配置通过广播形式通知其它sentinel,其它的sentinel则更新对应master的配置。
    
    2. 一个faiover要想被成功实行,sentinel必须能够向选为master的slave发送SLAVE OF NO ONE命令,然后能够通过INFO命令看到新master的配置信息。
    
    3. 当将一个slave选举为master并发送SLAVE OF NO ONE`后,即使其它的slave还没针对新master重新配置自己,failover也被认为是成功了的。

     因为每一个配置都有一个版本号,所以以版本号最大的那个为标准:

     1 1)假设有一个名为mymaster的地址为192.168.1.50:6379 2 
     3 2)一开始,集群中所有的sentinel都知道这个地址,于是为mymaster的配置打上版本号1。
     4 
     5 3)一段时候后mymaster死了,有一个sentinel被授权用版本号2对其进行failover。
     6 
     7 4)如果failover成功了,假设地址改为了192.168.1.50:9000,此时配置的版本号为2
     8 
     9 5)进行failover的sentinel会将新配置广播给其他的sentinel,发现新配置的版本号为2时,版本号变大了,
    10      说明配置更新了,于是就会采用最新的版本号为2的配置。

     生产环境使用docker-compose来搭建

     代码演示如下:

       git clone https://gitee.com/QiHanXiBei/redis_sentinel.git

      cd /home

      cd redis_sentinel/

      docker-compose up --force-recreate #启动 由于我们安装redis时设置了开机自启,这里我们需要kill-9杀死进程
      

        在master中连接redis------------------> redis-cli

        salve1中使用6380连接redis---------> redis-cli -p 6380

        salve2中使用6381连接redis---------> redis-cli -p 6381

    数据同步:

        master存入数据-------------------------> set 123 123

        salve1和salve2获取数据-------------------------> get 123

        此时我们模拟主机宕机------------------> docker stop redis_sentinel_master_1

        初始主机中我们将redis退出重连就会发现他已经连不上了

         而从机中会推举一个成为主机,我们使用info查看 

    同样还可以再进行测试,在这个从–>主(slave2)中存数据----> set 123 456

    另外的从–>从(slave1)取数据—> get 123

    我们可以看到数据还是同步的

    6. Redis主流集群方案

      1)redis cluster集群方案

      2)master/slave主从方案

      3)哨兵模式来进行主从替换以及故障恢复

    7. codis

    • 什么是codis?

        1. codis是redis集群解决方案之一,codis是GO语言开发的代理中间件

        2. 当客户端向codis发送指令时,codis负责将指令转发给后面的redis实例来执行,并将返回结果转发给客户端

    • 为什么会出现codis?

        1. 在大数据高并发场景下,单个redis实例往往会无法应对

        2. 首先redis内存不易过大,内存太大会导致rdb文件过大,导致主从同步时间过长

        3. 其次在CPU利用率中上,单个redis实例只能利用单核,数据量太大,压力就会特别大

    • codis部署方案

        1. 单个codis代理支撑的QPS比较有限,通过启动多个codis代理可以显著增加整体QPS

        2. 多codis还能起到容灾功能,挂掉一个codis代理还有很多codis代理可以继续服务
        

    • codis分片原理

        1. codis负责将特定key转发到特定redis实例,codis默认将所有key划分为1024个槽位

        2. 首先会对客户端传来的key进行crc32计算hash值,然后将hash后的整数值对1024进行取模,这个余数就是对应的key槽位

        3. 每个槽位都会唯一映射到后面的多个redis实例之一,codis会在内存中维护槽位和redis实例的映射关系

        4. 这样有了上面key对应的槽位,那么它应该转发到那个redis实例就很明确了

        5. 槽位数量默认是1024,如果集群中节点较多,建议将这个数值大一些,比如2048,4096

    • 不同codis槽位如何同步

        1. 如果codis槽位值存在内存中,那么不同的codis实例间的槽位关系得不到同步

        2. 所以codis还需要一个分布式配置存储的数据库专门来持久化槽位关系

        3. codis将槽位关系存储在zookeeper中,并且提供一个dashboard可以来观察和修改槽位关系

  • 相关阅读:
    泛微云桥e-Bridge 目录遍历,任意文件读取
    (CVE-2020-8209)XenMobile-控制台存在任意文件读取漏洞
    selenium 使用初
    将HTML文件转换为MD文件
    Python对word文档进行操作
    使用java安装jar包出错,提示不是有效的JDK java主目录
    Windows server 2012安装VM tools异常解决办法
    ifconfig 命令,改变主机名,改DNS hosts、关闭selinux firewalld netfilter 、防火墙iptables规则
    iostat iotop 查看硬盘的读写、 free 查看内存的命令 、netstat 命令查看网络、tcpdump 命令
    使用w uptime vmstat top sar nload 等命令查看系统负载
  • 原文地址:https://www.cnblogs.com/xinzaiyuan/p/12659307.html
Copyright © 2011-2022 走看看