Linux详细搭建Redis-Cluster集群以及使用

Posted 2021-12-17 学码无涯

在服务开发中，单机都会存在单点故障的问题，及服务部署在一台服务器上，一旦服务器宕机服务就不可用，所以为了让服务高可用，分布式服务就出现了，将同一服务部署到多台机器上，即使其中几台服务器宕机，只要有一台服务器可用服务就可用。

集群的优点

高可伸缩性：服务器集群具有很强的可伸缩性。随着需求和负荷的增长，可以向集群系统添加更多的服务器。在这样的配置中，可以有多台服务器执行相同的应用和数据库操作。

高可用性：高可用性是指，在不需要操作者干预的情况下，防止系统发生故障或从故障中自动恢复的能力。通过把故障服务器上的应用程序转移到备份服务器上运行，集群系统能够把正常运行时间提高到大于99.9%，大大减少服务器和应用程序的停机时间。

高可管理性：系统管理员可以从远程管理一个、甚至一组集群，就好像在单机系统中一样。

所以，为了在大流量访问下提供稳定的业务，集群化是存储的必然形态

Redis-Cluster

redis cluster是官方的redis集群实现
redis-cluster使用去中心化的思想 使用hash slot方式 将16348个hash slot 覆盖到所有节点上 对于存储的每个key值 使用CRC16(KEY)&16348=slot 得到他对应的hash slot 并在访问key时就去找他的hash slot在哪一个节点上 然后由当前访问节点从实际被分配了这个hash slot的节点去取数据 节点之间使用轻量协议通信 减少带宽占用 性能很高 自动实现负载均衡与高可用 自动实现failover 并且支持动态扩展 官方已经可以1000个节点 实现的复杂度低

cluster（集群）：

cluster同时满足了sentinel的一些特性达到了高可用目的，不同点是采用hash算法根据key自动将数据分配到不同的节点当中，新增节点非常方便，当数据量过大时，可增加机器进行扩容，解决了单机容量受限的问题。

cluster特性

1、多个redis节点直接数据共享
2、所有的节点都是一主一从或一主多从
3、不支持同时处理多个key（如MSET/MGET），因为cluster需要把key分配节点，高并发量同时创建key-value会降低性能并导致不可预测的行为
4、支持在线增加、删除节点
5、不支持多数据库选择

cluster搭建

集群部署需要至少六个节点，个人学习测试，只在本机进行创建使用，而生产环境是在多个机器上面部署才能高可用性

创建节点

配置

vim …/redis.conf 进行修改配置，由于该文件内容较多，可以选择finalshell自带编辑器修改
修改一下选项

port 6379 #放入节点目录下修改成节点端口
cluster-enabled yes  #启用集群
cluster-node-timeout 5000 #超时时间
protected-mode no #此时外部网络可以直接访问
daemonize yes  #后台启动
bind 0.0.0.0

修改完毕后Ctrl+s保存
可以通过grep 内容 …/redis.conf查看修改是否成功

保存后，挨个复制到节点目录下，修改该节点的端口保存
在每个节点目录下启动

查看服务以及防火墙状态

创建集群

./redis-cli --cluster create 172.31.0.224:6370..........172.31.0.224:6375 --cluster-replicas 1

查看集群信息

./redis-cli --cluster check 172.31.0.224:6375

3主3从
我们可以用Redis Desktop Manager连接一下

使用问题：

当使用6379进行存值时发现报错：(error) CLUSTERDOWN Hash slot not served ：没有分配槽

原因：

使用创建集群指令时会出现
Can I set the above configuration? (type ‘yes’ to accept):
你需要输入yes,而并非缩写 y，因为玩linux的都习惯的会输入 y，但是这里不行，要全拼yes才可以。就是这个错误引起的分配槽失败。

检测

redis-cli --cluster check 127.0.0.1:6379
检测结果
[ERR] Not all 16384 slots are covered by nodes

进行修复

redis-cli --cluster fix 127.0.0.1:6379
修复完后让我们添加key-value

没有问题，让我们在节点上添加key-value

发现报错(error) MOVED 9439 172.31.0.224:6371
原因是因为没有用集群模式连接（连接节点命令 没有加 -c 参数）
./redis-cli -c -h 172.31.0.224:6371

查看Redis Desktop Manager

连接6372节点，也存在key-value

模拟节点宕机

查看节点主从身份
6370.6371.6372为Mater，6373，6374，6375为slave，对这些单词很不爽哈，主人，奴隶

我们对6372的主进行处决 kill

当我们再次查看节点的主从身份

发现6370，6371还为主人，6374，6375为奴隶
6372没了，6373当了主人，
宕机后的节点数据会不会丢失？

Redis Cluster 不保证强一致性，在一些特殊场景，客户端即使收到了写入确认，还是可能丢数据的。
Redis Cluster 不保证强一致性，存在丢失数据的场景：

异步复制
在 master 写成功，但 slave 同步完成之前，master 宕机了，slave 变为 master，数据丢失。