redis哨兵&codis

目录

1. 什么是哨兵模式

2. 哨兵集群

3. Redis阐述容灾机制

4. Redis哨兵原理

5. Redis-sentinel集群

6. redis主流集群方案

7. codis

1. 什么是哨兵模式

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

redis哨兵&codis_第1张图片

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哨兵-原理

redis哨兵&codis_第2张图片

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杀死进程
  redis哨兵&codis_第3张图片

redis哨兵&codis_第4张图片

    在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退出重连就会发现他已经连不上了
redis哨兵&codis_第5张图片

     而从机中会推举一个成为主机,我们使用info查看 redis哨兵&codis_第6张图片

redis哨兵&codis_第7张图片

同样还可以再进行测试,在这个从–>主(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代理可以继续服务
    redis哨兵&codis_第8张图片

  • 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可以来观察和修改槽位关系

你可能感兴趣的:(redis哨兵&codis)