Redis集群的概念：
RedisClusterdis解决方案，在解决了dis一个服务挂了可以快速的切换到另外一个服务，当遇到单机内存、并发等瓶颈时，可使用此方案来解决这些问题
分布式数据库概念
1. 数据库把整个数据按分区规则映射到多个节点，即把数据划分到多个节点上，每个节点负责整体数据的一个子集。900用户数据，有disdis
2.
redis集群使用了哈希分区，顺序分区暂用不到，不做具体说明；
rediscluster“虚拟槽分区”方式（哈希分区分节点取余、一致性哈希分区和虚拟槽分区），其它两种也不做介绍，有兴趣可以百度了解一下
3.
RedisCluster函数
函数: Hash()=CRC16[key]&16383
fdb72b337db0d105365464a023.png" alt="">
redis
4. disCluster
a支持有限，比如不支持了
b支持有限，当多个支持事务
c一个很大的键值对映射到不同的节点
e支持单层结构，不支持树型结构。
二、集群环境搭建-手动篇
部署结构图：6389为6379的从节点，6390为6380的从节点，6391为6381的从节点
/usr/local/bin/一个文件夹clusterconf，用来存放集群的配置文件
2. 修改配置文件
port 6379 //
cluster-enabled yes //
cluster-node-timeout 15000 //回复的时间）
cluster-config-file /usr/localbin/cluster/data/nodes-6379.conf 配置文件
3. 6dis
dis-server clusterconf/redis6379.conf &
dis-server clusterconf/redis6380.conf &
dis-server clusterconf/redis6381.conf &
dis-server clusterconf/redis6389.conf &
dis-server clusterconf/redis6390.conf &
dis-server clusterconf/redis6391.conf &
cluster meet ip port关键步骤1：集群搭建－与各节点握手）
5. 查询到
6. 禁止
7. 获取集群当前状态
8. dis关键步骤2：集群搭建－分配槽）
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关键步骤3：集群搭建－集群映射)，到此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安装文档,建议用此方式完成
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
redis:)
f) 最关键的一步：通过这个命令可以自动完成之前手动配置集群的握手、分配槽位、主从映射）
./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
貌似只有主节点可读写，从节点只能读
主节点死后，从节点变成主节点
3.集群搭建好以后开始测试
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
不正常的（来源于网络资源）
6379
解决如下：
6379
6380:>cluster setslot 1180 stable
cluster setslot 2998 stable
cluster setslot 11212 stable
其它也一样，分别执行修复完后：
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
6.集群节点之间的通信
1.
当主从角色变化或新增节点，彼此通过ping/pong
2. Gossip
Gossip
meet通知新节点加入，消息发送者通知接收者加入到当前集群，
ping
pong
fail一个
3. 消息解析流程
ID获取到发送节点的相关数据。
消息解析流程：
4.
Gossipdis
不难看出：节点选择的流程可以看出消息交换成本主要体现在发送消息的节点数量和每个消息携带的数据量
流程说明：
A，数量：集群内每个节点维护定时任务默认为每秒执行10随机选取随机性，每cluster-node-timeout/2 dis.confcluster-node-timeout 15000
B，消息数据：节点自身信息和其他节点信息
四、redis集群扩容
A. 准备好新节点
B. ,
1) dis6382.confdis6392.confdis节点
redis
./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添加的是从节点
--master-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 删除了。
6382删除步骤：
1dis-trib.rb reshard 192.168.1.111:6382
1000
2
./redis-trib.rb del-node 192.168.1.111:6382 3e50c6398c75e0088a41f908071c2c2eda1dc900
……
六、故障转移
redis
redis包括了 主观下线和客观下线；
主观下线：指某个节点认为另一个节点不可用，即下线状态，当然这个状态不是最终的故障判定，只能代表这个节点自身的意见，也有可能存在误判；
下线流程：
A，a
B，a
a
客观下线：指真正的下线，集群内多个节点都认为该节点不可用，达成共识，将它下线，如果下线的节点为主节点，还要对它进行故障转移
a标记节点
redis统计持有槽的主节点投票数是否达到一半，当下线报告统计数大于一半时，被标记为客观下线状态。
故障恢复：
故障主节点下线后，如果下线节点的是主节点，则需要在它的从节点中选一个替换它，保证集群的高可用；转移过程如下：
1，资格检查：检查该从节点是否有资格替换故障主节点，如果此从节点与主节点断开过通信，那么当前从节点不具体故障转移；
2，准备选举时间：当从节点符合故障转移资格后，更新触发故障选举时间，只有到达该时间后才能执行后续流程；
3，发起选举：当到达故障选举时间时，进行选举；
4，选举投票：只有持有槽的主节点才有票，会处理故障选举消息，投票过程其实是一个领导者选举（选举从节点为领导者）的过程，每个主节点只能投一张票给从节点，N/2+1通知集群内所有节点。
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 [email protected] 举报，一经查实，本站将立刻删除。
