Ubuntu搭建redis集群

搭建集群

接下来在redis安装目录下创建一个新的文件夹cluster

mkdir cluster

然后在该目录下创建六个目录，分别命名为7000、7001、7002、7003、7004和7005：

cd cluster/
mkdir 7000 7001 7002 7003 7004 7005

在7000目录下创建一个Redis配置文件redis.conf，内容如下：

port 7000
bind 192.168.153.130 
daemonize yes 
pidfile /var/run/redis_7000.pid
cluster-enabled yes
cluster-config-file nodes_7000.conf
cluster-node-timeout 15000
protected-mode no
appendonly yes

上述配置是开启redis集群的最简配置，各项配置的含义如下：

• port 7000：redis节点的端口号为7000；
• bind 192.168.153.130：绑定本机的IP地址；
• daemonize yes：以后台服务的形式开启redis；
• pidfile /var/run/redis_7000.pid：以该配置启动redis后将在/var/run/目录下创建一个redis_port.pid文件；
• cluster-enabled yes：是否开启集群，yes；
• cluster-config-file nodes_7000.conf：集群配置文件，启动后自动生成，文件名称为nodes_7000.conf。该文件将保持集群配置信息，以保证重启该redis节点后能够保持集群状态；
• cluster-node-timeout 15000：请求超时时间，默认为15秒；
• protected-mode no:
• appendonly yes：是否开启aof日志，开启后每次写操作都记录一条日志。

剩下的7001~7005节点的配置文件除了端口号改为相应的之外，其他配置保持一致。配置好7000~7005节点的redis配置文件后，启动这些节点：

注意需要进入redis.conf所在文件夹执行启动节点！ ！ ！

注意需要进入redis.conf所在文件夹执行启动节点！ ！ ！

注意需要进入redis.conf所在文件夹执行启动节点！ ！ ！

例如使用下面的命令启动7001节点，直接在redis安装目录启动会报错

cd cluster/7001/
redis-server redis.conf

检查是否启动成功

输入下列启动集群

redis-cli --cluster create 192.168.153.130:7000 192.168.153.130:7001 192.168.153.130:7002 192.168.153.130:7003 192.168.153.130:7004 192.168.153.130:7005 --cluster-replicas 1

选项--replicas 1表示我们希望为集群中的每个主节点创建一个从节点，之后跟着的其他参数则是这个集群实例的地址列表：3个主节点（Master，即7000~7002），3个从节点（Slave，即7003~7005）。输入该命令后，终端打印出如下配置：

其中M开头的节点为主节点，S开头的为从节点。从从节点的replicates（复制的意思）信息可以看出7000的从节点为7004，7001的从节点为7005，7002的从节点为7003。确认无误后输入yes点击回车继续：

可看到7000节点的拥有5461个哈希槽（0 - 6460 slots），7001节点拥有5462个哈希槽（5461 - 10922 slots），7002节点拥有5461个哈希槽（10923 - 16383 slots），而从属节点并没有分配哈希槽。

从最后一行的输出信息可以看出，redis集群总共有16384个哈希槽（slots）。

此外，那些一大串的字符称为节点ID

集群测试

测试存取

连接集群(以7003从节点为例)

redis-cli -h 192.168.153.130 -c -p 7003

可发现，存值的操作并不是在7003节点完成的，存值的过程只在主节点下完成，并且每次set操作redis都会输出Redirected to slot [xxxx] located at的提示。redis集群有16384个哈希槽，每次set key时，redis内部通过CRC16校验后对16384取模来决定放置哪个哈希槽。正如上面所说的，集群的每个主节点负责一部分哈希槽。

比如第一条命令set a 1计算出来的哈希码为15495，介于11001到16384之间，所以便存储在了7002节点中。

上面我们提到7000节点的从节点为7005，下面来验证一下：

可看到它们存储的key是相同的。

尝试从7004节点删除key：

发现7000节点的b也被删除。

接下来从7000节点获取a的值（a存储在7002节点中）

可看到redis自己redirected到了7002节点获取a的值，这就是集群的特点，每个节点都是平等的，可以相互间取值。

测试主从

在集群过程中可以通过主从的分配来提高redis的可用性。比如这个例子，集群有7000、7001和7002 3个主节点，如果这3个节点都没有从节点，假设7001宕机了，那么整个集群就会因为缺少5501-11000这个范围的哈希槽而变得不可用。

所以我们在集群建立的时候，一定要为每个主节点都添加了从节点, 比如像上面的例子那样，集群包含主节点7000、7001和7002以及从节点7003、7004和7005, 那么即使7001宕系统也可以继续正常工作。

当7001这个主节点宕机后，redis集群将会选择7001的从节点7005作为新的主节点以确保集群正常的工作。当重新启动7001后，其自动变为了7005的从节点，角色完成了转换!

为了验证这个理论，下面将7001节点杀死，然后观察:

查看7005节点的状态

redis-cli --cluster check 192.168.153.130:7005

可看到7005已经晋升为了主节点。接着测试从7000节点获取c的值（c存储在7001节点中，7005之前为7001的从节点，所以也存有这个值）：

redis自动redirected到了7005，并成功获取到了c的值

重新启动7001节点

cd cluster/7001/
redis-server redis.conf

查看7001节点状态

redis-cli --cluster check 192.168.153.130:7001

7001已经成为了7005的从节点了。

关闭/重启集群

依次关闭各个节点

redis-cli -h 192.168.153.130 -p 7000 shutdown
redis-cli -h 192.168.153.130 -p 7001 shutdown
redis-cli -h 192.168.153.130 -p 7002 shutdown
redis-cli -h 192.168.153.130 -p 7003 shutdown
redis-cli -h 192.168.153.130 -p 7004 shutdown
redis-cli -h 192.168.153.130 -p 7005 shutdown

当然也可以直接使用kill -9 进程id，关闭各个redis节点(不建议)

如果需要重启集群，只需要进入各个节点的文件夹，如7000节点

cd cluster/7000
redis-server redis.conf