Redis - 高可用性：Redis Cluster实现

官网

Redis是有中文官网的：Redis - cluster，但是有些东西没写清楚

这里自己根据步骤完成并补充了一些知识点

版本：Redis 5 ，在Centos下运行

至少要Redis3.0（包括3.0）以上版本，且Redis3、4还要装Ruby，建议Redis5起步

---

主从复制-》哨兵模式-》Redis Cluster

可用性（Availability）：非故障的节点在合理的时间内返回合理的响应（不是错误和超时的响应）

Redis模式：

• 单机模式：只有一个redis服务器，宕机后整个系统就失效了
• 为了解决单机模式的问题，提出主从复制：复制redis，原redis叫master，负责写操作，复制的redis叫slave，负责读操作，slave宕机不会影响系统
• 但是主从复制模式master宕机一样系统失效，提出哨兵模式：设置一个独立进程监视redis（master/slave），当master宕机时选择一个slave顶替master

Redis - 高可用性：主从复制、哨兵模式及应用

哨兵模式需要一个独立进程不停的监视master（心跳机制），耗费系统资源

Redis官方提供了Redis Cluster：一个提供在多个Redis间节点间共享数据的程序集

Redis Cluster至少需要3（master）+3（slave）才能建立集群，采用无中心结构，每个节点保存节点和集群状态，节点相互连接

Redis Cluster与哨兵模式不同在与：

• 无中心结构：redis cluster使用多个master保存数据，没有主从区别
• 容错机制：当master宕机时，哨兵模式是哨兵推举slave为master，而redis cluster中slave仅做数据备份，master宕机就由对应的slave顶上
• redis cluster以哈希槽进行数据分片，而哨兵模式并没有自动的分配数据

redis cluster 容错机制

在哨兵模式下：sentinel monitor mySentinel 127.0.0.1 6379 3

当master宕机，3个哨兵认为master宕机就推举slave为master

在cluster中同样有容错机制：

判断master不可用：

投票机制：集群中所有master进行投票，如果半数以上master与该master通信超时，则认为该master宕机，推选对应的slave为master

判断集群不可用：

1. 如果某个master和对应slave宕机，该集群不可用 - fail（master+slave宕机，某些哈希槽无法使用）
2. 半数以上master宕机，集群不可用 - fail

---

哈希分布

分布式系统的数据会分布在多个节点中，需要设置数据分布方式
常用的数据分布方式有哈希分布和顺序分布

• 顺序分布：按照数据顺序均分

• 传统哈希分布：插入数据时，首先计算哈希值（例如节点取余），再查询元数据服务器，获得该哈希值对应的服务器。
  在这种算法下，服务器的增减将导致大量的数据迁移，不适合于生产

3个节点分为：【3,6…99】、【1,4…100】、【2,5…98】
新增一个节点，数据分布就发生了较大的改变：【1,5…97】，【2,6…98】…

节点取余扩容时建议多倍扩容，数据迁移少

• 一致性哈希分布：将整个hash空间映射成环，每个节点负责一定空间内的数据

优点在与增减节点只需重定位环空间中的一小部分数据，具有较好的容错性和可扩展性

• 哈希槽

Redis 集群有16384个哈希槽,每个key通过CRC16校验后对16384取模来决定放置哪个槽.集群的每个节点负责一部分hash槽,举个例子,比如当前集群有3个节点,那么:

节点 A 包含 0 到 5500号哈希槽.
节点 B 包含5501 到 11000 号哈希槽.
节点 C 包含11001 到 16384号哈希槽.

这种结构很容易添加或者删除节点. 比如如果我想新添加个节点D, 我需要从节点 A, B, C中得部分槽到D上. 如果我想移除节点A,需要将A中的槽移到B和C节点上,然后将没有任何槽的A节点从集群中移除即可.

由于从一个节点将哈希槽移动到另一个节点并不会停止服务,所以无论添加删除或者改变某个节点的哈希槽的数量都不会造成集群不可用的状态.

---

Redis Cluster操作

准备

1. 能够使用的Redis

2. 创建相应的Redis服务的文件夹

创建redis_cluster文件夹，因为我们会有3（master）+3（slave）个服务，端口分别设置为7000~7005，创建对应的文件夹

3. Redis.conf设置cluster相关属性

# 关闭保护模式，可以公网访问
protected-mode no
# 端口号
port 7000
# 启动cluster
cluster-enabled yes
# 当前节点的集群信息
cluster-config-file nodes-7000.conf
# 连接超时
cluster-node-timeout 5000
# 是否在每次更新操作后进行日志记录
appendonly yes
# 后台启动
daemonize yes
# redis节点密码，所有节点应当一样
requirepass ***
# 连接主节点密码
masterauth ***

4. 复制6个redis.conf到对应的文件夹：上面的配置7000要修改成对应的端口

每个文件夹都有对应的redis.conf，表示一个redis服务

5. 复制redis到当前文件夹，启动6个节点

带节点的redis.conf启动redis

/opt/local/redis_cluster/redis/bin/redis-server ./7000/redis.conf
/opt/local/redis_cluster/redis/bin/redis-server ./7001/redis.conf
/opt/local/redis_cluster/redis/bin/redis-server ./7002/redis.conf
/opt/local/redis_cluster/redis/bin/redis-server ./7003/redis.conf
/opt/local/redis_cluster/redis/bin/redis-server ./7004/redis.conf
/opt/local/redis_cluster/redis/bin/redis-server ./7005/redis.conf

当然也可以写成一个shell脚本：start.sh

给该脚本设置权限

chmod u+x start.sh

启动：ps -ef | grep -i redis查看端口，确实启动了6个redis服务

搭建集群

6个redis服务已经准备好了，可以使用这些服务来搭建集群

只需要执行：

redis-cli --cluster create -a zfk857213 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 --cluster-replicas 1

当出现[OK] All 16384 slots covered.创建集群成功

测试

启动一个端口的客户端

-c表示cluster

./redis/bin/redis-cli -c -p 7000 -a zfk85721

当存储bb时，hash计算后存放到节点7001，即进入7001，7001节点仅保存该节点数据，get aa时需要进入7000节点查找

可以查看节点信息cluster nodes

确实是3（master）+3（slave）

---

SpringBoot连接Redis Cluster

Springboot连接cluster与连接哨兵模式类似：Springboot连接哨兵模式

在yml里配置：

---

报错

[ERR] Node 127.0.0.1:7000 NOAUTH Authentication required

登录redis时没输密码：加上-a 密码

./redis/bin/redis-cli -c -p 7000 -a zfk857213

hash槽出错：

(error) CLUSTERDOWN Hash slot not served

修复redis：

./redis-cli --cluster fix 127.0.0.1:7004 -a zfk857213

3. 创建集群时报错

因为以前已经创建过一次，再创建显示这些端口非空

Node 127.0.0.1:7000 is not empty. Either the node already knows other nodes (check with CLUSTER NODES) or contains some key in database 0.

解决方案：

• 将dump.rdb、nodes.conf、*.aof、.log等文件删除（这些是数据备份文件）

• 在每个端口的cli进行flushall清除数据库信息

然后创建集群即可