Redis 集群

    上一次说到了哨兵模式下的主从配置，这个只是增强了高可用性，但是对于存储的数据量依然会存在着限制，受限与存储内存最小的数据节点，特别是当使用持久化时

    Redis的集群使用数据分片而非同Memcached的客户端一致性hash的分片。这里的好处则是方便扩容 后期迁移方便等特点。

首先为了搭建集群，我创建6个redis实例用于三主三从的集群配置，不明白怎么弄的可以看前面的搭建方法。

想要搭建集群，首先需要修改实例的配置文件

cluster-enabledyes

cluster-config-filenodes.conf

cluster-enabled表示集群启用与否

cluster-config-file则是指定集群的配置文件 。nodes.conf是配置文件名。根目录参见dir目录的位置。

修改六个配置文件后重新启动则会发现区别，此时的每个实例已经开启了集群功能。

同样在查看redis_6379.log日志文件则会发这样的信息。

其中后面的一串则表示的是该节点的运行 ID，是节点在集群中的唯一标示

此时在数据目录中则能够发现我们刚才配置的集群配置文件

打开配置文件则可以看到以下信息

由此可以看到节点的运行ID，其他的则在集群配置完成后说明

开始初始化集群，我们使用的是redis源码包中提供的一个辅助工具redis-trib.rb来创建集群

/usr/local/redis3.0/redis-3.0.1/src/redis-trib.rbcreate --replicas 1  127.0.0.1:6379127.0.0.1:6380 127.0.0.1:6381 127.0.0.1:6382 127.0.0.1:6383 127.0.0.1:6384

Create 表示创建集群 -–replicas 1 表示每个主数据库拥有一个从库

根据错误提示：/usr/bin/env: ruby: 没有那个文件或目录。

因为redis-trib.rb是使用ruby编写的，因此需要先安装ruby

Yum –yinstall ruby

再次执行创建，依然报错

/usr/local/redis3.0/redis-3.0.1/src/redis-trib.rb:24:in`require': no such file to load -- rubygems (LoadError)from/usr/local/redis3.0/redis-3.0.1/src/redis-trib.rb:24

因为redis-trib.rb依赖于gem包redis 使用

Gem install redis 来安装

当安装完成后

执行创建集群的命令

当输入yes设置上面的配置

首先redis-trib.rb会以客户端的形式尝试连接所有的节点，并发送ping命令确定这些节点可以正常使用。如果有任何节点无法连接则创建失败。同时发送info命令查找每个节点的运行ID以及是否开启的集群功能。当一切完成后，会向每个节点发送cluster meet 命令 cluster meet ipport 这个命令告诉当前节点指定的ip与port上运行的节点也是集群的一部分。最终将6个节点归入一个集群中

根据上面的配置显示，可以看出63796380 6381为主库，而他们的从库则是6382 6383 6384 。

同样可以看到16384个插槽中 0—5460号 5461个插槽分配在6379端口上的主库中  5461—10922号5462个插槽分配在了6380端口的主库上，10923—16383号5461个插槽分配在了6381端口的主库上。

通过客户端使用命令clusternodes可以看到集群中所有的节点的信息

我们使用新节点的客户端执行clustermeet命令为集群添加新的节点,命令后面是集群中任意一个节点的地址与端口

此时我们再次查看集群中节点的信息

很显然 此时新节点已经被添加到集群中去了。新的节点添加到集群后有两种选择，要么通过cluster replicate 命令复制集群中某个主库中的数据过来以一个从库的身份运行 要么向集群申请插槽，以主库的身份运行。

首先我们配置让6385实例节点以主库的身份运行

在配置之前，我们先通过clusterslots命令查看插槽的分配情况

根据返回的数据，我们可以看到16384个插槽被分成了三份，即三条记录。每条记录的前两个值表示的是插槽的开始与结束值。后面的两个值表示的是节点的IP与端口，主库总是在前面

接下来我们开始重新分片

执行命令 /usr/local/redis3.0/redis-3.0.1/src/redis-trib.rbreshard 127.0.0.1:6379

Reshard表示要重新分片，后面需要指定集群中其中一个节点的地址，redis-trib 就会自动找到集群中的其他节点

最后我们指定多少个插槽想要移动，在这里我指定1000个。

除了移动的哈希槽数量之外，redis-trib 还需要知道重新分片的目标（target node）， 也即是， 负责接收这 1000 个哈希槽的节点。

接着，redis-trib 会向你询问重新分片的源节点（source node）， 也即是， 要从哪个节点中取出 1000 个哈希槽， 并将这些槽移动到目标节点上面。

如果我们不打算从特定的节点上取出指定数量的哈希槽， 那么可以向 redis-trib 输入 all ， 这样的话， 集群中的所有主节点都会成为源节点， redis-trib 将从各个源节点中各取出一部分哈希槽， 凑够 1000 个， 然后移动到目标节点上面：

输入 all 并按下回车之后， redis-trib 将打印出哈希槽的移动计划， 如果你觉得没问题的话， 就可以输入 yes 并再次按下回车：

当输入yes后 则开始重新分片，在重新分片的过程中并不会影响客户端的使用

当重新分片完成后，使用clusterslots命令可以查看到如下信息

6385实例上的存在了分别原来在6379端口实例上的0-332插槽,6380端口实例上的5461-5794插槽，6381端口实例上的10923-11255上的插槽.

同样，我们可以使用以下命令来检查重新分片的集群是否正常

/usr/local/redis3.0/redis-3.0.1/src/redis-trib.rbcheck 127.0.0.1:6379