【Redis】Redis 集群

一、集群概念

业务发展过程中遇到的峰值瓶颈：

• redis提供的服务OPS可以达到10万/秒，当前业务OPS已经达到20万/秒
• 内存单机容量达到256G,当前业务需求内存容量1T

这个时候可以使用集群的方式可以快速解决上述问题

集群架构： 集群就是使用网络将若干台计算机联通起来，并提供统一的管理方式，使其对外呈现单机的服务效果

集群的作用：

• 分散单台服务器的访问压力，实现负载均衡
• 分散单台服务器的存储压力，实现可扩展性
• 降低单台服务器宕机带来的业务灾难的可能性，实现高可用性

二、集群数据存储设计

• 通过hash算法设计，计算出key应该保存的位置
• 将所有的存储空间切割成16384份，每台主机保存一部分，每份代表的一个存储空间（槽），不是一个key的保存空间，这个存储空间可以保存很多key
• 将key按照计算出的结果放到对应的存储空间

假定我们现在增加一台机器，这些存储的数据以及空间应该如何分配呢？

一台机器分一些槽出来给新的机器，所谓的增加机器和删除机器，改变槽所存储的机器即可

三、集群内部通讯设计

• 各个数据库相互通信，保存各个库中槽的编号
• 一次命中，直接返回
• 一次未命中，告知具体位置，最多两次才命中

此时有一台客户端查找key，首先会通过hash算法计算出key对应的槽编号，然后在哈希环上找到对应的机器，检查这台机器上是否有对应的槽（由于可能进行了机器的增加、删除，机器上的槽会被添加到不同机器上）

如果这台机器有key对应的槽，直接查找返回；如果没有，则查找每台机器槽编号和机器的记录，然后再到对应机器取即可

四、搭建集群

Cluster配置

设置加入cluster，成为其中的节点

cluster-enabled yes|no

cluster配置文件名，该文件属于自动生成，仅用于快速查找文件并查询文件内容

cluster-config-file <filename>

节点服务响应超时时间，用于判定该节点是否下线或切换为slave

cluster-node-timeout <milliseconds>

master连接的slave最小数量

cluster-migration-barrier <count>

配置3 masters---3 slaves

编写redis-6379.conf

由redis-6379.conf得到redis-6380.conf、redis-6381.conf、redis-6382.conf、redis-6383.conf、redis-6384.conf，分别作为3个master和3个slave的启动配置文件

启动所有的master和slave

这还是一个一个的节点，我们需要把他们连在一起，在src目录下有一个redis-trib.rb的可执行程序（这个文件执行需要安装ruby）

# 这里的n表示1个master对应n个slave
# 后面的ip:port表示master和slave的信息，master和slave的数量需要和前面的n对应
# 假设n=1，写了6组ip:port，则表示前3个为master，后3个为slave，实现1主1从
# 假设n=2，写了9组ip:port，则表示前3个为master，后6个为slave，实现1主2从
./redis-trib.rb create --replicas n ip1:port1 ip2:port2 ....

写6组ip:port，执行指令，生成3组1主1从

生成多组主从结构前，我们先看一下data目录（在redis-端口.conf中配置）下生成的节点的配置文件nodes-端口.conf

我们输入yes，生成3组1主1从

cluster连接在一起后，集群就配置好了，此时nodes-端口.conf就发生了改变。我们看一下master 6379对应的节点配置文件

我们看一下6379master终端的提示信息

五、集群使用实践

1. 使用集群存放数据

我们连接上6379端口的redis服务器后，想要在6379服务器上放数据，可通过CRC算法和模16384计算出itheima这个数据应该放在5798号槽，而这个槽在6380机器上，不允许我们放在6379机器上

我们使用-c参数登录服务器，这个参数是专门操作集群的

我们依然连接6379服务器，放数据的时候，给出提示信息，虽然我们在6379上放数据，但通过CRC算法和模16384计算出itheima这个数据应该放在5798号槽，故重定向到了6380机器

我们通过-c参数登录6382这台slave服务器取数据

提示信息告诉我们，重定向到6380机器上的5798号槽取出来的。只要是我们登录集群中的任意一台机器，都能在6380机器上的5798号槽取出来，如果我们登录6380机器就不会有重定向信息，而是直接取出数据

2. slave掉线对集群的影响

集群最大的优势并不是能在多台机器存放数据，而是集群能够很好的解决宕机带来的业务灾难

我们先停掉6382 slave1

我们看一下slave1对应的master1，master1发现slave1 10s内无响应，则将其标记为已下线

而此时集群中的其他master和slave都会收到master1的通知，slave1已下线

这时我们让slave1重新上线

上线后和master1重新同步即可，master1再通知其他的master和slave有关slave1的上线信息，其他的机器就清除slave1的下线标记

总结： slave下线后，与其对应的master会将其标记为下线状态，同时通知集群中其他机器该slave下线；待其上线后，再与其进行数据同步，然后通知集群中其他的机器该slave的上线信息

3. master掉线对集群的影响

我们停掉master1

下面是与master1对应的slave1的操作

我们用cluster nodes查看一下节点信息，发现有4个master，其中6379被标记为fail

我们现在重新启动6379

6379请求和6382进行数据同步

再用cluster nodes查看一下节点信息，6379的状态从master fail被修改为slave

总结： 当master1下线后，对应的slave1会尝试连接，超时后自己成为新的master，然后通知集群中其他的机器，master1下线以及自己成为master的消息，master1的状态被标记为master fail；6379重新上线时，会成为slave，并和自己的master进行数据同步

Cluster节点操作命令

查看集群节点信息

cluster nodes

进入一个从节点redis，切换其主节点

cluster replication <master-id>

发现一个新节点，新增主节点

cluster meet ip:port

忽略一个没有slot的节点

cluster forget

手动故障转移

cluster failover