大佬教程收集整理的这篇文章主要介绍了Redis系列九:redis集群高可用,大佬教程大佬觉得挺不错的,现在分享给大家,也给大家做个参考。
redis集群的概念:
redisClusterdis解决方案,在解决了dis一个服务挂了可以快速的切换到另外一个服务,当遇到单机内存、并发等瓶颈时,可使用此方案来解决这些问题
1. 数据库把整个数据按分区规则映射到多个节点,即把数据划分到多个节点上,每个节点负责整体数据的一个子集。900用户数据,有disdis
@H_874_21@redis@H_874_21@集群使用了哈希分区,顺序分区暂用不到,不做具体说明;
rediscluster@H_874_21@“虚拟槽分区”方式(哈希分区分节点取余、一致性哈希分区和虚拟槽分区),其它两种也不做介绍,有兴趣可以百度了解一下
redisCluster函数
函数: Hash()=CRC16[key]&16383
title="redis系列九:redis集群高可用" alt="redis系列九:redis集群高可用" src="http://code.js-code.com/res/2019/02-10/10/b7bbbffdb72b337db0d105365464a023.png" >
a支持有限,比如不支持了
b支持有限,当多个支持事务
c一个很大的键值对映射到不同的节点
d@H_874_21@不支持多数据库,只有@H_874_21@
e支持单层结构,不支持树型结构。
@H_874_21@@H_874_21@部署结构图:6389为6379的从节点,6390为6380的从节点,6391为6381的从节点
/usr/local/bin/一个文件夹clusterconf,用来存放集群的配置文件
2. 修改配置文件
cluster-node-timeout 15000 //回复的时间)
cluster-config-file /usr/localbin/cluster/data/nodes-6379.conf 配置文件
3. @H_874_21@6dis
@H_874_21@dis-server clusterconf/redis6379.conf &
@H_874_21@dis-server clusterconf/redis6380.conf &
@H_874_21@dis-server clusterconf/redis6381.conf &
@H_874_21@dis-server clusterconf/redis6389.conf &
@H_874_21@dis-server clusterconf/redis6390.conf &
@H_874_21@dis-server clusterconf/redis6391.conf &
cluster meet ip port@H_874_21@关键步骤1:集群搭建-与各节点握手)
5. 查询到
6. 禁止
7. 获取集群当前状态
8. dis@H_874_21@关键步骤2:@H_874_21@集群搭建-分配槽)
redis-cli -h 192.168.152.128 -p 6379 cluster addslots {0...5461}
redis-cli -h 192.168.152.128 -p 6380 cluster addslots {5641...10922}
redis-cli -h 192.168.152.128 -p 6381 cluster addslots {10923...16383}
9.
11. cluster nodes
12. 6389@H_874_21@关键步骤3:@H_874_21@集群搭建-集群映射),到此redis集群手动搭建完成
192.168.152.128:6389> cluster Replicate 9b7b0c22f95eb01fb9935ad4b04d396c7f99e881
192.168.152.128:6390> cluster Replicate 5351c088472467ae485ed519cea271efda646bfa
92.168.152.128:6391> cluster Replicate e718f126278072e1e180c3e518d73e0bc877b3dc
使用ruby来自动分配槽与主从分配,见redis安装文档,建议用此方式完成
@H_874_21@@H_874_21@1.首先下载ruby-2.3.1.tar.gz dis-3.3.0.gem,然后把这两个工具通过winscp传入linux虚拟机
/usr/local
tar -zxvf ruby-2.3.1.tar.gz
a) cd /software/rubysoft/ruby-2.3.1
b) ./configure -prefix=/usr/local/ruby
C) make && make install //
d) dis-3.3.0.gem //yum install rubygems
E) fig-file文件删除;依次启动
dis-server clusterconf/redis6379.conf
f) @H_874_21@最关键的一步:通过这个命令可以自动完成之前手动配置集群的握手、分配槽位、主从映射)
./redis-trib.rb create --replicas 1 192.168.152.128:6379 192.168.152.128:6380 192.168.152.128:6381 192.168.152.128:6389 192.168.152.128:6390 192.168.152.128:6391
6379
貌似只有主节点可读写,从节点只能读
主节点死后,从节点变成主节点
a) 连入redis集群并设置值./redis-cli -h 192.168.152.128 -p 6379 -c
可以看到设置name以后,重定向到了6380的这个redis,这时因为键name经过CRC16[k]&16284虚拟槽分区算法以后落到了6380这个节点,所以数据就存到了6380这个redis节点
切回6379获取name的值也会通过同样的算法重定向到6380
4.集群健康检查
./redis-trib.rb check 192.168.152.128:6379 (dis
title="redis系列九:redis集群高可用" alt="redis系列九:redis集群高可用" src="http://code.js-code.com/res/2019/02-10/10/44b4039f71e3fa249027b72af1a8a6f1.png" >
不正常的(来源于网络资源)
6379
解决如下:
6379
6380:>cluster setslot 1180 stable
cluster setslot 2998 stable
cluster setslot 11212 stable
其它也一样,分别执行修复完后:
@H_874_21@6379
redis.conf加上
masterauth “12345678”
requiredpass “12345678”
用户和密码是很有必要的,设置成一致
配置如下:
./redis-trib.rb create --replicas 2
192.168.1.111:6379 192.168.1.111:6380 192.168.1.111:6381
192.168.1.111:6479 192.168.1.111:6480 192.168.1.111:6481
192.168.1.111:6579 192.168.1.111:6580 192.168.1.111:6581
1.
@H_874_21@
当主从角色变化或新增节点,彼此通过ping/pong
2. Gossip
Gossip
@H_237_0@meet通知新节点加入,消息发送者通知接收者加入到当前集群,
ping
pong
fail一个
@H_874_21@3. 消息解析流程
ID获取到发送节点的相关数据。
消息解析流程:
4.
Gossipdis
不难看出:节点选择的流程可以看出消息交换成本主要体现在发送消息的节点数量和每个消息携带的数据量
流程说明:
A,数量:集群内每个节点维护定时任务默认为每秒执行10随机选取随机性,每cluster-node-timeout/2 dis.confcluster-node-timeout 15000
B,消息数据:节点自身信息和其他节点信息
A. 准备好新节点
B. ,
1) dis6382.confdis6392.confdis节点
./redis-server clusterconf/redis6382.conf &
./redis-server clusterconf/redis6392.conf &
2)
./redis-trib.rb add-node 192.168.152.128:6382 192.168.152.128:6379
6379
3),添加从节点
redis-trib.rb add-node --slave --master-id 03ccad2ba5dd1e062464bc7590400441fafb63f2 192.168.152.128:6392 192.168.152.128:6379
--slave添加的是从节点
--R_568_11845@aster-id 03ccad2ba5dd1e062464bc7590400441fafb63f2
192.168.152.128:6392,
192.168.152.128:6379
4) dis-trib.rb reshard 192.168.152.128:6382 //
How many slots do you want to move (from 1 to 16384)? 1000 //
what is the receiving node ID? 464bc7590400441fafb63f2 //
source node #1:all //
新增完毕!
集群同时也支持节点下线掉,下线的流程如下:
流程说明:
A,slot,
B,当下线的节点没有槽或本身是从节点时,就可以通知集群内其它节点(或者叫忘记节点),当下线节点被忘记后正常关闭。
删除节点也分两种:
6382
6392
./redis-trib.rb del-node 192.168.1.111:6392 7668541151b4c37d2d9 删除了。
@H_874_21@6382删除步骤:
1dis-trib.rb reshard 192.168.1.111:6382
1000
2
./redis-trib.rb del-node 192.168.1.111:6382 3e50c6398c75e0088a41f908071c2c2eda1dc900
……
redis包括了 主观下线和客观下线;
主观下线:指某个节点认为另一个节点不可用,即下线状态,当然这个状态不是最终的故障判定,只能代表这个节点自身的意见,也有可能存在误判;
下线流程:
A,a
B,a
a
客观下线:指真正的下线,集群内多个节点都认为该节点不可用,达成共识,将它下线,如果下线的节点为主节点,还要对它进行@R_327_10772@
a标记节点
redis统计持有槽的主节点投票数是否达到一半,当下线报告统计数大于一半时,被标记为客观下线状态。
故障恢复:
故障主节点下线后,如果下线节点的是主节点,则需要在它的从节点中选一个替换它,保证集群的高可用;转移过程如下:
1,资格检查:检查该从节点是否有资格替换故障主节点,如果此从节点与主节点断开过通信,那么当前从节点不具体@R_327_10772@;
2,准备选举时间:当从节点符合@R_327_10772@资格后,更新触发故障选举时间,只有到达该时间后才能执行后续流程;
3,发起选举:当到达故障选举时间时,进行选举;
4,选举投票:只有持有槽的主节点才有票,会处理故障选举消息,投票过程其实是一个领导者选举(选举@H_874_21@从节点为领导者)的过程,每个主节点只能投一张票给从节点,N/2+1通知集群内所有节点。
以上是大佬教程为你收集整理的Redis系列九:redis集群高可用全部内容,希望文章能够帮你解决Redis系列九:redis集群高可用所遇到的程序开发问题。
如果觉得大佬教程网站内容还不错,欢迎将大佬教程推荐给程序员好友。
本图文内容来源于网友网络收集整理提供,作为学习参考使用,版权属于原作者。
如您有任何意见或建议可联系处理。小编QQ:384754419,请注明来意。