Redis 5 版本的高可用集群的水平扩展

Redis 5 版本的高可用集群的水平扩展

Redis系列介绍：

Redis的基础介绍与安装使用步骤：https://blog.csdn.net/qq_34002221/article/details/84963588
Redis的基础数据结构与使用： https://blog.csdn.net/qq_34002221/article/details/84981299
Redis核心原理：https://blog.csdn.net/qq_34002221/article/details/84996919
Redis 5 之后版本的高可用集群搭建：https://blog.csdn.net/qq_34002221/article/details/85011041
Redis 5 版本的高可用集群的水平扩展：https://blog.csdn.net/qq_34002221/article/details/85019752
Redis 5 集群选举原理分析:https://blog.csdn.net/qq_34002221/article/details/85042536

---

Redis3.0以后的版本虽然有了集群功能，提供了比之前版本的哨兵模式更高的性能与可用性，但是集群的水平扩展却比较麻烦，今天就来带大家看看redis高可用集群如何做水平扩展，原始集群(见下图)由6个节点组成。

6个节点分布在一台机器上，采用三主三从的模式，以及进行水平新增的2个节点，一主一从。

实际应用中，最好用多台机器，比如说6个节点分布到3台机器上，redis在建立集群时为自动的将主从节点进行不同机器的分配，比如说：master-8001分布在192.168.5.100这台机器上，则它的slave-8004则不会在这台机器上，这是为了如果一台机器挂掉之后，还有其他的机器上的从节点进行替换master，以达到高可用的目的。

按之前的方法将集群进行启动。
分别启动6个节点：

/usr/local/redis/redis-5.0.2/src/redis-server /usr/local/redis-cluster/800*/redis.conf

查询启动情况：

ps -ef | grep redis

建立集群

/usr/local/redis/redis-5.0.2/src/redis-cli --cluster create --cluster-replicas 1 192.168.5.100:8001 192.168.5.100:8002 192.168.5.100:8003 192.168.5.100:8004 192.168.5.100:8005 192.168.5.100:8006

注意：如果之前redis集群给全部停掉了，这时候再建立集群时，会出现如下的情况

[ERR] Node 192.168.5.100:8001 is not empty. Either the node already knows other nodes (check with CLUSTER NODES) or contains some key in database 0.

这个时候需要将每个节点下的这几个文件给删掉（测试情况删掉，实际应用不要删，这是备份文件以及节点信息，按实际的情况进行处理）：

appendonly.aof  dump.rdb  nodes-8001.conf

客户端连接8001端口的redis实例

/usr/local/redis/redis-5.0.2/src/redis-cli -c -h 192.168.5.100 -p 8001

查看集群状态

192.168.5.100:8001> cluster info
cluster_state:ok
cluster_slots_assigned:16384
cluster_slots_ok:16384
cluster_slots_pfail:0
cluster_slots_fail:0
cluster_known_nodes:6
cluster_size:3
cluster_current_epoch:6
cluster_my_epoch:1
cluster_stats_messages_ping_sent:607
cluster_stats_messages_pong_sent:607
cluster_stats_messages_sent:1214
cluster_stats_messages_ping_received:602
cluster_stats_messages_pong_received:607
cluster_stats_messages_meet_received:5
cluster_stats_messages_received:1214

查看节点信息

192.168.5.100:8001> cluster nodes
194a31057d2e098483bcd2ad01e1bba6a1af6a7d 192.168.5.100:8006@18006 slave 7b5f6aa6dcb4d5aca4a94e57ddeea6971b38bba6 0 1544881722939 6 connected
b0db47b7bbd3694596f293aa522488882e8fe647 192.168.5.100:8004@18004 slave 33206e9384297092b5b8a85c944f3564e5d983d7 0 1544881722000 4 connected
7b5f6aa6dcb4d5aca4a94e57ddeea6971b38bba6 192.168.5.100:8002@18002 master - 0 1544881721931 2 connected 5461-10922
33206e9384297092b5b8a85c944f3564e5d983d7 192.168.5.100:8003@18003 master - 0 1544881719000 3 connected 10923-16383
662809cf2d5bb138912dea7fb1e452f6e0f149da 192.168.5.100:8001@18001 myself,master - 0 1544881719000 1 connected 0-5460
60a0f7ced303374d8b36e7aa219cbcd4ff5b0caf 192.168.5.100:8005@18005 slave 662809cf2d5bb138912dea7fb1e452f6e0f149da 0 1544881720000 5 connected

这时候看一下这个信息

7b5f6aa6dcb4d5aca4a94e57ddeea6971b38bba6 192.168.5.100:8002@18002 master - 0 1544881721931 2 connected 5461-10922
33206e9384297092b5b8a85c944f3564e5d983d7 192.168.5.100:8003@18003 master - 0 1544881719000 3 connected 10923-16383
662809cf2d5bb138912dea7fb1e452f6e0f149da 192.168.5.100:8001@18001 myself,master - 0 1544881719000 1 connected 0-5460

---

这里介绍一下redis的hash槽的概念

从上图可以看出，整个集群运行正常，三个master节点和三个slave节点

• 8001端口的实例节点存储0-5460这些hash槽
• 8002端口的实例节点存储5461-10922这些hash槽
• 8003端口的实例节点存储10923-16383这些hash槽

这三个master节点存储的所有hash槽组成redis集群的存储槽位，slave点是每个主节点的备份从节点，不显示存储槽位

Redis 集群中内置了 16384 个哈希槽，当需要在 Redis 集群中放置一个 key-value时，redis 先对 key 使用 crc16 算法算出一个结果，然后把结果对 16384 求余数

这样每个 key 都会对应一个编号在 0-16383 之间的哈希槽，redis 会根据节点数量大致均等的将哈希槽映射到不同的节点。

• 使用哈希槽的好处就在于可以方便的添加或移除节点。

• 当需要增加节点时，只需要把其他节点的某些哈希槽挪到新节点就可以了；

• 当需要移除节点时，只需要把移除节点上的哈希槽挪到其他节点就行了；

• 在这一点上，我们以后新增或移除节点的时候不用先停掉所有的 redis 服务。

---

“用了哈希槽的概念，而没有用一致性哈希算法，不都是哈希么？这样做的原因是为什么呢？”

Redis Cluster是自己做的crc16的简单hash算法，没有用一致性hash。Redis的作者认为它的crc16(key) mod 16384的效果已经不错了，虽然没有一致性hash灵活，但实现很简单，节点增删时处理起来也很方便。

“为了动态增删节点的时候，不至于丢失数据么？”

节点增删时不丢失数据和hash算法没什么关系，不丢失数据要求的是一份数据有多个副本。

“还有集群总共有2的14次方，16384个哈希槽，那么每一个哈希槽中存的key 和 valu