Centos7.0搭建Redis集群【转】

2019-08-04 本文已影响0人擦普洱

原文地址：https://www.jianshu.com/p/9fe248e5a0ca

Step 0 ：集群概念

Redis 集群简介

Redis 集群是一个可以在多个 Redis 节点之间进行数据共享的设施（installation）。

Redis 集群不支持那些需要同时处理多个键的 Redis 命令，因为执行这些命令需要在多个 Redis 节点之间移动数据，并且在高负载的情况下，这些命令将降低 Redis 集群的性能，并导致不可预测的行为。

Redis 集群通过分区（partition）来提供一定程度的可用（availability）：即使集群中有一部分节点失效或者无法进行通讯，集群也可以继续处理命令请求。

Redis 集群提供了以下两个好处：

将数据自动切分（split）到多个节点的能力。
当集群中的一部分节点失效或者无法进行通讯时，仍然可以继续处理命令请求的能力。

Redis 集群数据共享

Redis 集群使用数据分片（sharding）而非一致性哈希（consistency hashing）来实现：一个 Redis 集群包含 16384 个哈希槽（hash slot），数据库中的每个键都属于这 16384 个哈希槽的其中一个，集群使用公式 CRC16(key) % 16384 来计算键 key 属于哪个槽，其中 CRC16(key) 语句用于计算键 key 的 CRC16 校验和。

集群中的每个节点负责处理一部分哈希槽。举个例子，一个集群可以有三个哈希槽，其中：

节点 A 负责处理 0 号至 5500 号哈希槽。
节点 B 负责处理 5501 号至 11000 号哈希槽。
节点 C 负责处理 11001 号至 16384 号哈希槽。

这种将哈希槽分布到不同节点的做法使得用户可以很容易地向集群中添加或者删除节点。比如说：

如果用户将新节点 D 添加到集群中，那么集群只需要将节点 A 、B 、 C 中的某些槽移动到节点 D 就可以了。
与此类似，如果用户要从集群中移除节点 A ，那么集群只需要将节点 A 中的所有哈希槽移动到节点 B 和节点 C ，然后再移除空白（不包含任何哈希槽）的节点 A 就可以了。

因为将一个哈希槽从一个节点移动到另一个节点不会造成节点阻塞，所以无论是添加新节点还是移除已存在节点，又或者改变某个节点包含的哈希槽数量，都不会造成集群下线。

Redis 集群中的主从复制

为了使得集群在一部分节点下线或者无法与集群的大多数（majority）节点进行通讯的情况下，仍然可以正常运作， Redis 集群对节点使用了主从复制功能：集群中的每个节点都有 1 个至 N 个复制品（replica），其中一个复制品为主节点（master），而其余的 N-1 个复制品为从节点（slave）。

在之前列举的节点 A 、B 、C 的例子中，如果节点 B 下线了，那么集群将无法正常运行，因为集群找不到节点来处理 5501 号至 11000 号的哈希槽。

另一方面，假如在创建集群的时候（或者至少在节点 B 下线之前），我们为主节点 B 添加了从节点 B1 ，那么当主节点 B 下线的时候，集群就会将 B1 设置为新的主节点，并让它代替下线的主节点 B ，继续处理 5501 号至 11000 号的哈希槽，这样集群就不会因为主节点 B 的下线而无法正常运作了。

不过如果节点 B 和 B1 都下线的话， Redis 集群还是会停止运作。

Redis 集群的一致性保证（guarantee）

Redis 集群不保证数据的强一致性（strong consistency）：在特定条件下， Redis 集群可能会丢失已经被执行过的写命令。

使用异步复制（asynchronous replication）是 Redis 集群可能会丢失写命令的其中一个原因。考虑以下这个写命令的例子：

客户端向主节点 B 发送一条写命令。
主节点 B 执行写命令，并向客户端返回命令回复。
主节点 B 将刚刚执行的写命令复制给它的从节点 B1 、 B2 和 B3 。

如你所见，主节点对命令的复制工作发生在返回命令回复之后，因为如果每次处理命令请求都需要等待复制操作完成的话，那么主节点处理命令请求的速度将极大地降低 —— 我们必须在性能和一致性之间做出权衡。

如果真的有必要的话， Redis 集群可能会在将来提供同步地（synchronou）执行写命令的方法。

Redis 集群另外一种可能会丢失命令的情况是，集群出现网络分裂（network partition），并且一个客户端与至少包括一个主节点在内的少数（minority）实例被孤立。

举个例子，假设集群包含 A 、 B 、 C 、 A1 、 B1 、 C1 六个节点，其中 A 、B 、C 为主节点，而 A1 、B1 、C1 分别为三个主节点的从节点，另外还有一个客户端 Z1 。

假设集群中发生网络分裂，那么集群可能会分裂为两方，大多数（majority）的一方包含节点 A 、C 、A1 、B1 和 C1 ，而少数（minority）的一方则包含节点 B 和客户端 Z1 。

在网络分裂期间，主节点 B 仍然会接受 Z1 发送的写命令：

如果网络分裂出现的时间很短，那么集群会继续正常运行；
但是，如果网络分裂出现的时间足够长，使得大多数一方将从节点 B1 设置为新的主节点，并使用 B1 来代替原来的主节点 B ，那么 Z1 发送给主节点 B 的写命令将丢失。

注意，在网络分裂出现期间，客户端 Z1 可以向主节点 B 发送写命令的最大时间是有限制的，这一时间限制称为节点超时时间（node timeout），是 Redis 集群的一个重要的配置选项：

对于大多数一方来说，如果一个主节点未能在节点超时时间所设定的时限内重新联系上集群，那么集群会将这个主节点视为下线，并使用从节点来代替这个主节点继续工作。
对于少数一方，如果一个主节点未能在节点超时时间所设定的时限内重新联系上集群，那么它将停止处理写命令，并向客户端报告错误。

Step 1:安装Redis

1.下载redis源码包
redis5.0.0.tar.gz，提取码：8tf9

#Redis5.0.0.tar.gz目录
$ cd /usr/local/application/redis

2.解压

$ tar -zxvf redis-5.0.0.tar.gz

3.安装gcc依赖

$ yum install gcc

4.进入redis解压后的目录

$ cd redis-5.0.0

5.编译安装

$ make MALLOC=libc

将src目录下的文件加到/usr/local/bin目录

$ cd src && make install

6.创建集群
以下是一个包含了最少选项的集群配置文件示例：

port 7000
cluster-enabled yes
cluster-config-file nodes.conf
cluster-node-timeout 5000
appendonly yes

文件中的 cluster-enabled 选项用于开实例的集群模式，而 cluster-conf-file 选项则设定了保存节点配置文件的路径，默认值为 nodes.conf 。
nodes.conf无须人为修改，它由 Redis 集群在启动时创建，并在有需要时自动进行更新。

要让集群正常运作至少需要三个主节点，不过在刚开始试用集群功能时，强烈建议使用六个节点：其中三个为主节点，而其余三个则是各个主节点的从节点。

首先，让我们进入一个新目录，并创建六个以端口号为名字的子目录，稍后我们在将每个目录中运行一个 Redis 实例：

#当前所在目录：/usr/local/application/redis
$ mkdir cluster
$ cd cluster
$ mkdir 7000 7001 7002 7003 7004 7005

在文件夹 7000 至 7005 中，各创建一个 redis.conf 文件，文件的内容可以使用上面的示例配置文件，但记得将配置中的端口号从 7000 改为与文件夹名字相同的号码。

7.设置密码
密码设置分两种，本文档因为第一次安装，使用方式一。
密码是一定要设置的，无密会造成众多问题，例如被入侵挖矿，远程访问不了
方式一：修改所有Redis集群中的redis.conf文件加入:

masterauth passwd
requirepass passwd

说明：这种方式需要重新启动各节点

方式二：如何实例已经启动，则进入各个实例进行设置：

$ redis-cli -c -p 7000 
127.0.0.1:7000>config set masterauth passwd
OK
127.0.0.1:7000>config set requirepass passwd
OK
127.0.0.1:7000>config rewrite 
OK

之后分别使用redis-cli -c -p 7001，redis-cli -c -p 7002…..命令给各节点设置上密码。
注意：各个节点密码都必须一致，否则Redirected就会失败，推荐这种方式，这种方式会把密码写入到redis.conf里面去，且不用重启。

接下来就是启动所有节点

#当前所在目录：/usr/local/application/redis/cluster
$ cd 7000
$ ../redis-5.0.0/src/redis-server ./redis.conf &
$ cd ../7001
$ ../redis-5.0.0/src/redis-server ./redis.conf &
$ cd ../7002
$ ../redis-5.0.0/src/redis-server ./redis.conf &
$ cd ../7003
$ ../redis-5.0.0/src/redis-server ./redis.conf &
$ cd ../7004
$ ../redis-5.0.0/src/redis-server ./redis.conf &
$ cd ../7005
$ ../redis-5.0.0/src/redis-server ./redis.conf &

为了方便起见可以将以上启动命令做成脚本，然后授权chmod 777 脚本名，执行即可。

Step 2:启动集群

现在我们已经有了六个正在运行中的 Redis 实例，接下来我们需要使用这些实例来创建集群
执行以下命令来创建集群：

$ redis-cli --cluster create --cluster-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-cli 会打印出一份预想中的配置给你看，如果你觉得没问题的话，就可以输入 yes ， redis-cli 就会将这份配置应用到集群当中：

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
127.0.0.1:7000 replica #1 is 127.0.0.1:7003
127.0.0.1:7001 replica #1 is 127.0.0.1:7004
127.0.0.1:7002 replica #1 is 127.0.0.1:7005
M: 9991306f0e50640a5684f1958fd754b38fa034c9 127.0.0.1:7000
slots:0-5460 (5461 slots) master
M: e68e52cee0550f558b03b342f2f0354d2b8a083b 127.0.0.1:7001
slots:5461-10921 (5461 slots) master
M: 393c6df5eb4b4cec323f0e4ca961c8b256e3460a 127.0.0.1:7002
slots:10922-16383 (5462 slots) master
S: 48b728dbcedff6bf056231eb44990b7d1c35c3e0 127.0.0.1:7003
S: 345ede084ac784a5c030a0387f8aaa9edfc59af3 127.0.0.1:7004
S: 3375be2ccc321932e8853234ffa87ee9fde973ff 127.0.0.1:7005
Can I set the above configuration? (type 'yes' to accept): yes

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

Nodes configuration updated
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: 9991306f0e50640a5684f1958fd754b38fa034c9 127.0.0.1:7000
slots:0-5460 (5461 slots) master
M: e68e52cee0550f558b03b342f2f0354d2b8a083b 127.0.0.1:7001
slots:5461-10921 (5461 slots) master
M: 393c6df5eb4b4cec323f0e4ca961c8b256e3460a 127.0.0.1:7002
slots:10922-16383 (5462 slots) master
M: 48b728dbcedff6bf056231eb44990b7d1c35c3e0 127.0.0.1:7003
slots: (0 slots) master
M: 345ede084ac784a5c030a0387f8aaa9edfc59af3 127.0.0.1:7004
slots: (0 slots) master
M: 3375be2ccc321932e8853234ffa87ee9fde973ff 127.0.0.1:7005
slots: (0 slots) master
[OK] All nodes agree about slots configuration.

如果一切正常的话， redis-trib 将输出以下信息：

Check for open slots...
Check slots coverage...
[OK] All 16384 slots covered.

这表示集群中的 16384 个槽都有至少一个主节点在处理，集群运作正常。

测试集群比较简单的办法就是使用redis-cli：

$ redis-cli -c -p 7000 -a passwd
$ 127.0.0.1:7000>set a 158658
-> Redirected to slot [12182] located at 127.0.0.1:7002
OK
$ 127.0.0.1:7002>set b 111111
-> Redirected to slot [6001] located at 127.0.0.1:7001
OK
$ 127.0.0.1:7001>get a
-> Redirected to slot [12182] located at 127.0.0.1:7002
"158658"

redis-cli 对集群的支持是非常基本的，所以它总是依靠 Redis 集群节点来将它转向（redirect）至正确的节点。

一个真正的（serious）集群客户端应该做得比这更好：它应该用缓存记录起哈希槽与节点地址之间的映射（map），从而直接将命令发送到正确的节点上面。

这种映射只会在集群的配置出现某些修改时变化，比如说，在一次故障转移（failover）之后，或者系统管理员通过添加节点或移除节点来修改了集群的布局（layout）之后，诸如此类。

Step 3:添加新节点到集群

根据新添加节点的种类，我们需要用两种方法来将新节点添加到集群里面：

如果要添加的新节点是一个主节点，那么我们需要创建一个空节点（empty node），然后将某些哈希桶移动到这个空节点里面。
另一方面，如果要添加的新节点是一个从节点，那么我们需要将这个新节点设置为集群中某个节点的复制品（replica）。
本节将对以上两种情况进行介绍，首先介绍主节点的添加方法，然后再介绍从节点的添加方法。

无论添加的是那种节点，第一步要做的总是添加一个空节点。

我们可以继续使用之前启动 127.0.0.1:7000 、 127.0.0.1:7001 等节点的方法，创建一个端口号为 7006 的新节点，使用的配置文件也和之前一样，只是记得要将配置中的端口号改为 7000 。

以下是启动端口号为 7006 的新节点的详细步骤：

在终端里创建一个新的标签页。
进入 cluster文件夹。
创建并进入 7006 文件夹。
将 redis.conf 文件复制到 7006 文件夹里面，然后将配置中的端口号选项改为 7006 。
使用命令../redis-5.0.0/src/redis-server ./redis.conf & 启动节点。
如果一切正常，那么节点应该会正确地启动。

接下来，执行以下命令，将这个新节点添加到集群里面：

$ redis-cli --cluster add-node 127.0.0.1:7006 127.0.0.1 7000

通过 cluster nodes 命令，我们可以确认新节点 127.0.0.1:7006 已经被添加到集群里面了：

$ 127.0.0.1:7006> cluster nodes
3e3a6cb0d9a9a87168e266b0a0b24026c0aae3f0 127.0.0.1:7001 master - 0 1385543178575 0 connected 5960-10921
3fc783611028b1707fd65345e763befb36454d73 127.0.0.1:7004 slave 3e3a6cb0d9a9a87168e266b0a0b24026c0aae3f0 0 1385543179583 0 connected
f093c80dde814da99c5cf72a7dd01590792b783b :0 myself,master - 0 0 0 connected
2938205e12de373867bf38f1ca29d31d0ddb3e46 127.0.0.1:7002 slave 3c3a0c74aae0b56170ccb03a76b60cfe7dc1912e 0 1385543178072 3 connected
a211e242fc6b22a9427fed61285e85892fa04e08 127.0.0.1:7003 slave 97a3a64667477371c4479320d683e4c8db5858b1 0 1385543178575 0 connected
97a3a64667477371c4479320d683e4c8db5858b1 127.0.0.1:7000 master - 0 1385543179080 0 connected 0-5959 10922-11422
3c3a0c74aae0b56170ccb03a76b60cfe7dc1912e 127.0.0.1:7005 master - 0 1385543177568 3 connected 11423-16383

新节点现在已经连接上了集群，成为集群的一份子，并且可以对客户端的命令请求进行转向了，但是和其他主节点相比，新节点还有两点区别：

新节点没有包含任何数据，因为它没有包含任何哈希桶。
尽管新节点没有包含任何哈希桶，但它仍然是一个主节点，所以在集群需要将某个从节点升级为新的主节点时，这个新节点不会被选中。

接下来，只要将集群中的某些哈希桶移动到新节点里面，新节点就会成为真正的主节点了。

移动哈希桶(集群重新分片)

执行以下命令可以开始一次重新分片操作：

$ redis-cli --cluster reshard 127.0.0.1:7000
Connecting to node 127.0.0.1:7000: OK
Connecting to node 127.0.0.1:7002: OK
Connecting to node 127.0.0.1:7005: OK
Connecting to node 127.0.0.1:7001: OK
Connecting to node 127.0.0.1:7003: OK
Connecting to node 127.0.0.1:7004: OK
>>> Performing Cluster Check (using node 127.0.0.1:7000)
M: 9991306f0e50640a5684f1958fd754b38fa034c9 127.0.0.1:7000
slots:0-5460 (5461 slots) master
M: 393c6df5eb4b4cec323f0e4ca961c8b256e3460a 127.0.0.1:7002
slots:10922-16383 (5462 slots) master
S: 3375be2ccc321932e8853234ffa87ee9fde973ff 127.0.0.1:7005
slots: (0 slots) slave
M: e68e52cee0550f558b03b342f2f0354d2b8a083b 127.0.0.1:7001
slots:5461-10921 (5461 slots) master
S: 48b728dbcedff6bf056231eb44990b7d1c35c3e0 127.0.0.1:7003
slots: (0 slots) slave
S: 345ede084ac784a5c030a0387f8aaa9edfc59af3 127.0.0.1:7004
slots: (0 slots) slave
[OK] All nodes agree about slots configuration.
>>> Check for open slots...
>>> Check slots coverage...
[OK] All 16384 slots covered.
How many slots do you want to move (from 1 to 16384)? 1000

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

指定目标需要使用节点的 ID ，而不是 IP 地址和端口。比如说，我们打算使用集群的第一个主节点来作为目标，它的 IP 地址和端口是 127.0.0.1:7000 ，而节点 ID 则是 9991306f0e50640a5684f1958fd754b38fa034c9 ，那么我们应该向 redis-trib 提供节点的 ID ：

$ redis-cli --cluster reshard 127.0.0.1:7000
...
What is the receiving node ID? 9991306f0e50640a5684f1958fd754b38fa034c9

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

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

$ redis-cli --cluster reshard 127.0.0.1:7000
...
Please enter all the source node IDs.
Type 'all' to use all the nodes as source nodes for the hash slots.
Type 'done' once you entered all the source nodes IDs.
Source node #1:all

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

$ redis-cli --cluster reshard 127.0.0.1:7000
...
Moving slot 11421 from 393c6df5eb4b4cec323f0e4ca961c8b256e3460a
Moving slot 11422 from 393c6df5eb4b4cec323f0e4ca961c8b256e3460a
Moving slot 5461 from e68e52cee0550f558b03b342f2f0354d2b8a083b
Moving slot 5469 from e68e52cee0550f558b03b342f2f0354d2b8a083b
...
Moving slot 5959 from e68e52cee0550f558b03b342f2f0354d2b8a083b
Do you want to proceed with the proposed reshard plan (yes/no)? yes

输入 yes 并使用按下回车之后， redis-cli 就会正式开始执行重新分片操作，将指定的哈希槽从源节点一个个地移动到目标节点上面：

$ redis-cli --cluster reshard 127.0.0.1:7000
...
Moving slot 5934 from 127.0.0.1:7001 to 127.0.0.1:7000:
Moving slot 5935 from 127.0.0.1:7001 to 127.0.0.1:7000:
Moving slot 5936 from 127.0.0.1:7001 to 127.0.0.1:7000:
Moving slot 5937 from 127.0.0.1:7001 to 127.0.0.1:7000:
...
Moving slot 5959 from 127.0.0.1:7001 to 127.0.0.1:7000:

哈希桶的移动就完成了

现在，让我们来看看，将一个新节点转变为某个主节点的复制品（也即是从节点）的方法。

举个例子，如果我们打算让新节点成为 127.0.0.1:7005 的从节点，那么我们只要用客户端连接上新节点，然后执行以下命令就可以了：

$ redis 127.0.0.1:7006> cluster replicate 3c3a0c74aae0b56170ccb03a76b60cfe7dc1912e

其中命令提供的 3c3a0c74aae0b56170ccb03a76b60cfe7dc1912e 就是主节点 127.0.0.1:7005 的节点 ID 。

执行 cluster replicate 命令之后，我们可以使用以下命令来确认 127.0.0.1:7006 已经成为了 ID 为 3c3a0c74aae0b56170ccb03a76b60cfe7dc1912e 的节点的从节点：

$ redis-cli -p 7000 cluster nodes | grep slave | grep 3c3a0c74aae0b56170ccb03a76b60cfe7dc1912e
f093c80dde814da99c5cf72a7dd01590792b783b 127.0.0.1:7006 slave 3c3a0c74aae0b56170ccb03a76b60cfe7dc1912e 0 1385543617702 3 connected
2938205e12de373867bf38f1ca29d31d0ddb3e46 127.0.0.1:7002 slave 3c3a0c74aae0b56170ccb03a76b60cfe7dc1912e 0 1385543617198 3 connected

3c3a0c74aae0b56170ccb03a76b60cfe7dc1912e 现在有两个从节点，一个从节点的端口号为 7002 ，而另一个从节点的端口号为 7006 。