【redis-6】redis集群与分区

redis分区的意义在于，提升性能和存储能力，毕竟，单机的io和计算能力、存储能力有限。下面，具体来谈一下分区：

一：分区的方式

如使用id作为key，分区方式可以有：

1、范围分区

 

根据 id 数字的范围比如 1--10000 、 100001--20000.....90001-100000 ，每个范围分到不同的 Redis 实例 。

 

优点： 实现简单，方便迁移和扩展。

缺点：1、key只能是数字型。  2、如果有热点数据区分，会造成热点数据分布不均，性能损失。

 

2、hash分区

 

简单hash，比如使用key对redis实例数取模。 但是迁移复杂，当实例数变化会重新计算，造成旧数据错乱（可使用一致性hash环）

二：分区执行者

 分区的动作由哪里发起呢？ 来看一下：

1、client端分区

其实就是开发者自己计算hash值并指向对应的redis。 这样开发者需要维护所有的redis，应对所有数据处理关系，难以扩展，如果实例数改变，还要手动迁移数据。

2、proxy分区

在客户端和redis服务器之间加入代理，结合sentinel来完成。规避了client端分区的弊端。但是呢，在中间加入代理会造成性能下降，并且，有一些命令也是不支持的。

常见的代理有Codis（豌豆荚）和TwemProxy（Twitter），具体使用这里不作讲述。 我想讲的重点是下面一种：官方cluster分区

3、官方cluster分区

redis3.0之后，redis官方已提供了完整的集群解决方案，无需依赖client端或proxy端，开发者不用自己计算规则，搭建proxy等工作。  另外：方案采用去中心化的方式，包括：sharding（分区）、replication（复制）、failover（故障转移），称为RedisCluster。

1、redisCluster优点： 

高性能： 具备多主节点，负载均衡，读写分离

高可用：支持标准主从复制，实现类似raft的方式，可以实现主从切换

易扩展：增加或删除实例不需停机，无需任何代理工具

Redis5.0 前采用 redis-trib 进行集群的创建和管理，需要 ruby支持 ；Redis5.0 可以直接使用 Redis-cli 进行集群的创建和管理。

 

2、gossip协议

 

如图示，集群节点去中心化，采用p2p的方式，当某一个节点收到client端请求，会像病毒一样传播到其他节点上，最终找到正确的数据。

 

此传播依靠Gossip协议，而Gossip协议基本思想就是：

一个节点周期性(每秒)随机选择一些节点，并把信息传递给这些节点。 这些节点接下来会做同样的事情，信息会周期性的传播到N个节点，N称为扇出fanout。

gossip 协议包含多种消息，包括 meet 、 ping 、 pong 、 fail 、 publish 等等

 

meet ：sender向receiver发出，请求receiver加入sender的集群

ping ：节点检测其他节点是否在线

pong ：receiver收到meet或ping后的回复信息；在failover后，新的Master也会广播pong

fail ：节点A判断节点B下线后，A节点广播B的fail信息，其他收到节点会将B节点标记为下线

publish ：节点A收到publish命令，节点A执行该命令，并向集群广播publish命令，收到publish 命令的节点都会执行相同的publish命令

3、slot槽

redis中，总共划分了16384个slot，并把集群中所有实例映射到这些slot上 [0-16383]，比如上面有5个master，redisCluster在创建的时候，可以将slot映射为：

 

 

redis1	0-3270
redis2	3271-6542
redis3	6543-9814
redis4	9815-13087
redis5	13088-16383

存储时使用crc16 算法计算key值，并对16384取余，最终落到争取的redis。

注意： slot在cluster上必须是连续的

4、集群搭建

redisCluster要求至少3主3从，这里用一台机器实现伪集群，端口号7001-7006，版本redis-5.0.5：

1、解压并创建安装目录7001，安装

安装：

在redis-5.0.5/src下执行：  make install PREFIX=/var/redis-cluster/7001

拷贝配置文件： cp /var/redis-5.0.5/redis.conf /var/redis-cluster/7001/bin/

修改配置文件：

protected-mode no

port 7001

bind 127.0.0.1  注释掉

daemonize yes

cluster-enabled yes   开启集群模式

2、拷贝配置到其他节点目录，修改各节点端口

3、编写集群启动脚本并授权

4、启动脚本：./start.sh

5、创建集群关系：

./redis-cli --cluster create 192.168.0.140:7001 192.168.0.140:7002 192.168.0.140:7003 192.168.0.140:7004 192.168.0.140:7005 192.168.0.140:7006 --cluster-replicas 1

注意：--cluster-replicas 1代表每个master有1个slave，它会自动分配，作为master的节点需写在前面。。 到这里，每个节点的nodes.conf中都有节点槽的信息了，如图示

连接集群测试（-c 表示以集群方式连接）：在7001上保存，算出来的槽位置在7002上，所以保存在7002上

到这里，集群搭建完毕。我们可以

6、测试 往集群中添加节点

创建7007节点，并安装启动7007

./redis-cli --cluster add-node 192.168.0.140:7007 192.168.0.140:7001     （这里只需要指向其中一个master即可）

此时，7007还没有分配slot，在7007上执行命令分配slot：

./redis-cli --cluster reshard 192.168.0.140:7007

此时会让输入分配的slot数量，输入3000

此时需要输入7007在集群的id，可以查看nodes.conf中集群节点信息获取

4

接着，执行以下两步：

到这里，节点成功加入集群，可以使用cluster nodes命令查看集群节点信息：

不过这时候，7007还没有slave，我们再添加一个7008作为它的slave：

先启动一个7008实例，然后加入集群成为7007的slave： 

./redis-cli --cluster add-node 192.168.127.128:7008 192.168.127.128:7007 --cluster-slave --cluster-master-id 6ff20bf463c954e977b213f0e36f3efc02bd53d6

50b073163bc4058e89d285dc5dfc42a0d1a222f2是7007结点的id，可通过cluster nodes查看

查看集群信息，有7008了：

7、删除节点

./redis-cli --cluster del-node 192.168.127.128:7008 7008的id

如果删除master，需要先把slot分配出去，比如删除7007，并把槽分配给7001：

redis-cli --cluster reshard 192.168.127.128:7007 --cluster-from 7007的id --cluster-to 7001的id --cluster-slots  7007槽的数量

5、客户端是如何找到正确的节点数据的？认识一下moved重定向和ask重定向

moved重定向：

1、cluster中节点虽然有各自负责的slot范围，但是会通过通信知道其他节点和slot的对应关系。

2、client会随机连接到一个节点，根据CRC16规则取hash值，如果刚好是当前节点的slot范围，执行命令； 否则，带上目标节点信息，返回moved异常，client重新请求正确的节点。

ask重定向：

就是在收到moved异常重新请求节点的时候，在扩容或缩容，节点的slot被迁移了，返回ask重定向，client再次重新请求正确节点。

6、容灾

故障检测：

cluster中每个节点会定期给其他节点发送ping消息，如果在cluster-node-timeout内没收到pong回复，标记为失败。 超过一半的master认为某个节点失败时，会将其标记为fail，并通知其他节点。