Redis系列九：redis集群高可用

Redis集群的概念：

　　RedisCluster

分布式数据库概念

1. 900

2. 

   redis集群使用了哈希分区，顺序分区暂用不到，不做具体说明；

   rediscluster“虚拟槽分区”方式（哈希分区分节点取余、一致性哈希分区和虚拟槽分区），其它两种也不做介绍，有兴趣可以百度了解一下

3. 

   RedisCluster

   : Hash()=CRC16[key]&16383

   

redis

4. 

a

b

c

d不支持多数据库，只有

e

二、集群环境搭建-手动篇

部署结构图：6389为6379的从节点，6390为6380的从节点，6391为6381的从节点

/usr/local/bin/

2. 

   port 6379                      //

   cluster-enabled yes              //

   cluster-node-timeout 15000       //

   cluster-config-file  /usr/localbin/cluster/data/nodes-6379.conf

  

3. 6

cluster meet ip port关键步骤1：集群搭建－与各节点握手）

 

5. 

 

6. 

7. 

 

8. 关键步骤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   

/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) yum install rubygems

e) 

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 (

 

不正常的（来源于网络资源）

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. 

  Gossip

 

不难看出：节点选择的流程可以看出消息交换成本主要体现在发送消息的节点数量和每个消息携带的数据量

流程说明：

A，10cluster-node-timeout/2 cluster-node-timeout 15000  

B，消息数据：节点自身信息和其他节点信息

四、redis集群扩容

A. 准备好新节点

B. ,

1) 

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) 

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

1

  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