Redis Cluster集群搭建<原>

一、环境配置

         一台window 7上安装虚拟机,虚拟机中安装的是centos系统。

二、目标

    Redis集群搭建的方式有多种,根据集群逻辑的位置,大致可以分为三大类:基于客户端分片的Redis Sharding,如Jedis;基于服务器分片的Redis Cluster;基于客户端服务端之间的代理中间件的集群方案,如Twitter开发的twemproxy、豌豆荚的Codis等。本文接受的Redis-cluster是Redis3.0版本之后,官方推出的一款集群解决方案。与大多数分布式中间件一样,redis的cluster也是依赖选举算法来保证集群的高可用,所以类似ZooKeeper一样,一般是奇数个节点(可以允许N/2以下的节点失效),再考虑到每个节点做Master-Slave互为备份,所以一个redis cluster集群最少也得6个节点。因此,目标是在centos上搭建一个有6个节点的redis-cluster,端口号为 7000-7005。集群结构图如下所示:

 

三、搭建步骤

第一步、新建redis安装目录

  1. mkdir /opt/app/redis_cluster
  2. cd /opt/app/redis_cluster

 


第二步、下载、解压、编译

  1. $ wget http://download.redis.io/releases/redis-3.0.7.tar.gz
  2. $ tar xzf redis-3.0.7.tar.gz
  3. $ cd redis-3.0.7
  4. $ make

 


第三步、新建六个redis节点

[root@localhost redis-cluster]# mkdir 7000 7001 7002 7003 7004 7005

如下图所示,文件夹结构如下,六个文件夹分别保存六个节点相关的配置信息。

分别在7000-7005六个文件夹中创建redis.conf文件,并添加配置,配置内容如下
          注意:端口号 port 与所在文件夹名相同;cluster-config-file 地址中的 7000 也必须跟文件夹名相同。
1.       port 7000
2.       cluster-enabled yes
3.       cluster-config-file /opt/app/redis_cluster/7000/nodes.conf
4.       cluster-node-timeout 5000
5.       appendonly yes

第四步、安装ruby依赖

集群的命令依赖ruby环境,因此需要先安装ruby,使用yum命令安装。

[root@localhost redis_cluster]# yum install ruby -y  

第五步、安装rubygems依赖

安装完ruby后,再安装rubygems组件,依然使用yum命令安装。

[root@localhost redis_cluster]# yum install rubygems -y  

第六步、安装gem-redis依赖

保持耐心,接下来需要安装gem-redis,这个组件其实是redis和ruby的接口。可以去网址https://rubygems.org/gems/redis/versions/查看当前的版本,我本地安装时未加版本号,默认安装最新版本(3.3.1),可以带上版本号安装指定版本,命令如下:

[root@localhost redis_cluster]# gem install redis -v 3.0.7  

第七步、分别启动6个redis实例

至此,该安装的组件都已经安装完毕。然后,依次开启刚才定义好配置的六个redis节点。启动redis服务的命令如下:

[root@localhost redis_cluster]# redis-3.0.7/src/redis-server  7000/redis.conf &

这里可以注意到,每次创建时,配置不同的文件夹里的redis.conf。

都启动完了之后,可以使用命令检查下6个进程:

[root@localhost redis_cluster]# ps -ef | grep redis  

 

第八步、创建集群

走到这一步时,恭喜你,redis-cluster即将完成。创建集群的命令也很简单:

[root@localhost src]# ./redis-trib.rb create --replicas 1 127.0.0.1:7000 127.0.0.1:7001 127.0.0.1:7002 127.0.0.1:7003 127.0.0.1:7004 127.0.0.1:7005

 

创建过程中 redis-trib 会打印出一份预想中的配置给你看, 如果你觉得没问题的话, 就可以输入 “yes” , redis-trib 就会将这份配置应用到集群当中:

 

>>> Creating cluster

Connecting to node 127.0.0.1:7000: OK

Connecting to node 127.0.0.1:7001: OK

Connecting to node 127.0.0.1:7002: OK

Connecting to node 127.0.0.1:7003: OK

Connecting to node 127.0.0.1:7004: OK

Connecting to node 127.0.0.1:7005: OK

>>> Performing hash slots allocation on 6 nodes...

Using 3 masters:

127.0.0.1:7000

127.0.0.1:7001

127.0.0.1:7002

Adding replica 127.0.0.1:7003 to 127.0.0.1:7000

Adding replica 127.0.0.1:7004 to 127.0.0.1:7001

Adding replica 127.0.0.1:7005 to 127.0.0.1:7002

M: 2774f156af482b4f76a5c0bda8ec561a8a1719c2 127.0.0.1:7000

   slots:0-5460 (5461 slots) master

M: 2d03b862083ee1b1785dba5db2987739cf3a80eb 127.0.0.1:7001

   slots:5461-10922 (5462 slots) master

M: 0456869a2c2359c3e06e065a09de86df2e3135ac 127.0.0.1:7002

   slots:10923-16383 (5461 slots) master

S: 37b251500385929d5c54a005809377681b95ca90 127.0.0.1:7003

   replicates 2774f156af482b4f76a5c0bda8ec561a8a1719c2

S: e2e2e692c40fc34f700762d1fe3a8df94816a062 127.0.0.1:7004

   replicates 2d03b862083ee1b1785dba5db2987739cf3a80eb

S: 9923235f8f2b2587407350b1d8b887a7a59de8db 127.0.0.1:7005

   replicates 0456869a2c2359c3e06e065a09de86df2e3135ac

Can I set the above configuration? (type 'yes' to accept):

 

输入 yes 并按下回车确认之后, 集群就会将配置应用到各个节点, 并连接起(join)各个节点 —— 也即是, 让各个节点开始互相通讯:

 

Can I set the above configuration? (type 'yes' to accept): yes

>>> Nodes configuration updated

>>> Assign a different config epoch to each node

>>> Sending CLUSTER MEET messages to join the cluster

Waiting for the cluster to join......

>>> Performing Cluster Check (using node 127.0.0.1:7000)

M: 2774f156af482b4f76a5c0bda8ec561a8a1719c2 127.0.0.1:7000

   slots:0-5460 (5461 slots) master

M: 2d03b862083ee1b1785dba5db2987739cf3a80eb 127.0.0.1:7001

   slots:5461-10922 (5462 slots) master

M: 0456869a2c2359c3e06e065a09de86df2e3135ac 127.0.0.1:7002

   slots:10923-16383 (5461 slots) master

M: 37b251500385929d5c54a005809377681b95ca90 127.0.0.1:7003

   slots: (0 slots) master

   replicates 2774f156af482b4f76a5c0bda8ec561a8a1719c2

M: e2e2e692c40fc34f700762d1fe3a8df94816a062 127.0.0.1:7004

   slots: (0 slots) master

   replicates 2d03b862083ee1b1785dba5db2987739cf3a80eb

M: 9923235f8f2b2587407350b1d8b887a7a59de8db 127.0.0.1:7005

   slots: (0 slots) master

   replicates 0456869a2c2359c3e06e065a09de86df2e3135ac

[OK] All nodes agree about slots configuration.

>>> Check for open slots...

>>> Check slots coverage...

[OK] All 16384 slots covered.

 

一切正常输出以下信息:

 

[OK] All nodes agree about slots configuration.

>>> Check for open slots...

>>> Check slots coverage...

[OK] All 16384 slots covered.

四、Redis集群的测试

1、客户端连接集群

使用redis-cli命令,需要注意的命令中要带上-c,否则对于非本节点的slot,将不会进行重定位,而只是给出位置提示。可以选择连接集群中任意一个节点:

[root@localhost src]# ./redis-cli -c -p 7000

2、使用客户端查看集群信息

         在客户端通过命令cluster info查看集群状态信息;使用cluster nodes查看当前所有节点的信息:


         通过cluster nodes可以看到每个master节点被集群分配到的slot范围,如7000对应的是0-5460

3、存取值测试

根据redis-cluster的key值分配,name应该分配到节点7001[5798]上,上面显示redis cluster自动从7000跳转到了7001节点。

 

同理当取值的时候,也会判断被取值所在的位置,并自动跳转

 

对于值的存取,可以在集群中任意节点进行,cluster会自动跳转存取,包括slave节点,有点类似Http 302重定向

 

对于redis支持的其他数据类型如哈希、列表、集合、有序集合,此处不再测试,感兴趣的读者可以参考redis api自行研究。

4、集群节点选举

         现在模拟将7001节点挂掉,按照redis-cluster原理,7001的从节点7004将被选举为主节点。使用redis-trib.rb check查看7001状态,可以看到7001Master对应的Slave是7004

 

Key“name“原来存在7001上:

 

接下来,杀死7001线程:

 

接下来,可以看到原来作为slave节点的7004升级为master节点,并且,查询key“name”,发现重定位到7004,替代了原来的7001节点。

 

         现在我们恢复一下7001节点,使之重新启动,看是否自动重新加入到集群中以及充当M还是S:

 

         7001重新加入集群,并且变成7004的slave节点。

五、总结

         对客户端来说,整个cluster被看做是一个整体,客户端可以连接任意一个node进行操作,就像操作单一Redis实例一样,当客户端操作的key没有分配到该node上时,Redis会返回转向指令,指向正确的node,这有点儿像浏览器页面的302 redirect跳转。

 

 

优点:

1、  redis cluster作为一个集群,无中心的组织结构,客户端可以任一连接一个节点;

2、  采用solt槽位的形式,增减节点不需要重启服务,集群性能佳;

3、  每个节点都和N-1个节点通信,所以要维护好这个集群架构的每个节点信息,不然会导致整个集群不可工作;

4、  自主监控,自动切换主从;

5、  目前Redis官网主推。

缺点:

1、  不能保证数据的强一致性,官网给出了两种可能丢失写命令的情况如下:

a)         客户端向主节点A发送一条写命令,主节点是首先立马向客户端返回命令回复,然后再把刚刚的执行写命令同步至从节点,追求性能所致该设计;

b)         网络分裂(network partition),如果时间很长导致A节点的从节点转换为主节点,然这中间可能存在客户端正在和A节点通信也就被孤立了,这样写的命令将丢失,如当网络恢复A又重新加入集群。

2、  Redis 3.0以后才正式推出,时间较晚,目前能证明在大规模生产环境下成功的案例还不是很多,需要时间检验。

 

参考资料:

http://blog.csdn.net/fengshizty/article/details/51368004

http://blog.csdn.net/u011204847/article/details/51307044

http://blog.csdn.net/u014490157/article/details/52243996

http://www.cnblogs.com/junneyang/p/5899850.html

 

posted @ 2016-11-24 19:52  人生如若初见  阅读(420)  评论(0编辑  收藏  举报