redis基础六(集群)

1、redis cluster 介绍

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

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

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

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

1、将数据自动切分（split）到多个节点的能力。

2、当集群中的一部分节点失效或者无法进行通讯时， 仍然可以继续处理命令请求的能力。

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 就可以了。

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

为了使得集群在一部分节点下线或者无法与集群的大多数（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-cluster 架构图如下：

 

架构细节:

 

(1)所有的redis节点彼此互联(PING-PONG机制),内部使用二进制协议优化传输速度和带宽.

(2)节点的fail是通过集群中超过半数的节点检测失效时才生效.

(3)客户端与redis节点直连,不需要中间proxy层.客户端不需要连接集群所有节点,连接集群中任何一个可用节点即可

(4)redis-cluster把所有的物理节点映射到[0-16383]slot上,cluster 负责维护node<->slot<->value

2、redis cluster 搭建(5.0以后的版本)

要让集群正常工作需要2N+1个节点，我们以3个主节点为例，在这里我们要创建6个redis节点，其中三个为主节点，三个为从节点。

2.1 配置文件

1. 需要把#去掉，表示启动的redis服务一会布置为集群模式；
2. Redis集群的一些配置文件，不允许去修改这个文件，如果同一台机器部署多个redis集群服务，这里需要把各个redis服务的 node-6379.conf 名字改为不一样的，避免各个redis服务一样，导致一个服务把另一个redis服务的node-6379.conf覆盖；
3. 默认是15s，表示集群中的master挂掉后，其他master服务ping-pong不通，选举挂掉的master服务的slave服务变为master的时间，15s太长，需要修改下，一般5s；

4.默认一个master挂掉后，其他master在未选出挂掉master的slave为master前，他们都是不能工作的，cluster-require-full-coverage 改为no后，一个master挂掉，其他master照常工作。

2.2 部署cluster服务

本地启动6个服务，3个master，3个slave服务；分别是

127.0.0.1:6391-6396；

1、修改配置文件信息

修改配置文件端口，复制六份；

开启rdb和aof(修改默认的64m为3072m)；

服务改为守护进程；

添加日志输出地址；

修改内存管理机制为 maxmemory-policy  volatile-lru；

开启集群部署配置，如2.1 所示;

2、分别启动六个服务；

3、设置集群服务，命令如下：

./redis-cli --cluster create  127.0.0.1:6391 127.0.0.1:6392 127.0.0.1:6393 127.0.0.1:6394 127.0.0.1:6395 127.0.0.1:6396 --cluster-replicas 1

注意：1)、--cluster-replicas之间没有空格！

           2)、--cluster-replicas 后面的1 表示六台服务器，3个master，对应的各1个slave；

4、执行完上面的命令后，出现如下的提示：

需要输入的是“yes” ，不是“y”，否则不能给每个master分配slot，从而导致redis不可用！！！！

 

注意：

1、Redis集群的部署，为了保持高可用，有必要在部署master的时候同时部署对应的slave，这样master挂的话，slave会在默认的15s后，由其他master选举为msater；

2、如何知道master挂了呢？ 各个redis通过ping-pong去判断，超过设定的时间没有响应就认为master挂了，这个时候只有其他的master才有权限去选举把挂掉的master对应的slave变为master；如何再次其他原挂掉的master，它为变为slave，对应的master是以前它的slave现在变为master的服务；

3、集群部署具有可扩展性，也就是后面还可以继续增加node；

4、reddis cluster的slave不支持写，只要master才能进行写操作。