高并发高可用复杂系统中的缓存架构(十三) redis集群
上一篇 将 redis cluster 搭建起来了
redis cluster 提供了多个 master,数据可以分布式存储在多个 master 上; 每个 master 都带着 slave,自动就做读写分离; 每个 master 如果故障,那么就会自动将 slave 切换成 master,高可用
redis cluster 默认是不支持 slave 节点读或者写的,跟我们手动基于 replication 搭建的主从架构不一样的
slave node 上 使用 readonly,get,这个时候才能在 slave node 进行读取
redis cluster 主从架构,读写分离,复杂了点也可以做,但是 jedis 客户端,对 redis cluster 的读写分离支持不太好的
默认的话就是读和写都到 master 上去执行的
如果你要让最流行的 jedis 做 redis cluster 的读写分离的访问,那可能还得自己修改一点 jedis 的源码,成本比较高
核心的思路,在 redis cluster 中,就没有所谓的读写分离的概念了
读写分离是为了什么?主要是因为要建立一主多从的架构,才能横向任意扩展 slave node 去支撑更大的读吞吐量
redis cluster 的架构下,实际上本身 master 就是可以任意扩展的,你如果要支撑更大的读吞吐量,或者写吞吐量,或者数据量,都可以直接对 master 进行横向扩展就可以了,也可以实现支撑更高的读吞吐的效果
redis cluster 通过 master 水平扩容来支撑更高的读写吞吐 + 海量数据
redis cluster 模式下,不建议做物理的读写分离了,我们建议通过 master 的水平扩容,来横向扩展读写吞吐量,还有支撑更多的海量数据
比如 redis 单机假设读吞吐是 5w/s,写吞吐 2w/s,如果有 5 台 master,读吞吐可以达到总量 25w/s QPS,写可以达到 10w/s QPS
redis 单机内存不建议过大(建议值 6G、8G),因为 fork 类操作的时候很耗时,会导致请求延时的问题
只要横向扩容更多的 master 就能达到支撑 1TB 数据量。
Redis集群动态增加和删除节点
一、添加节点
1、首先将需要添加的节点启动:
这里启动redis6383.conf和redis6393.conf两个节点
查看原有节点:
3个主节点所对应的哈希槽(hash slot)
myself表示当前连接的节点
2、执行以下命令,将新节点添加到集群中
../redis-trib.rb add-node 192.168.230.129:6383 192.168.230.129:6380
备注:192.168.42.111:6383 是新的主节点
192.168.42.111:6380 是原存在的任一主节点
查看刚才新增的节点
3、增加一个从节点,执行以下命令
../redis-trib.rb add-node --slave --master-id 863203beac4e9e1fd85b218fc388f8b8ac9d2218 192.168.230.129:6393 192.168.230.129:6380
注释:
--slave 表示添加的是从节点
--master-id 863203beac4e9e1fd85b218fc388f8b8ac9d2218 主节点的node id,在这里是前面新添加的6383的node id
192.168.10.220:6393 新节点
192.168.10.219:6380 集群任一个旧节点
查看节点情况,可看见从节点已添加
但是,其主节点也就是6383的哈希槽为空,需要重新分配槽,执行命令:
../redis-trib.rb reshard 192.168.230.129:6380
注释: 192.168.230.129:6380 集群任一个旧节点
然后再输入yes,redis集群就开始分配哈希槽了.....
至此,一个新的主节点就添加完成了,执行命令查看现在的集群中节点的状态
可看到已分配
二、删除节点
1、删除从节点
删除从节点,直接使用以下命令即可
../redis-trib.rb del-node 192.168.230.129:6393 05945dcae79aca1425f68ca95f2aaf4d44b2167a
注释:192.168.230.129:6393 节点地址
05945dcae79aca1425f68ca95f2aaf4d44b2167a 节点node_id
2、删除主节点
因为主节点含有槽数,所以,首先要把节点中的哈希槽转移到其他节点中,执行命令
../redis-trib.rb reshard 192.168.230.129:6380
注:192.168.230.129:6380 集群中任一主节点
然后再输入yes,等待转移完成......
查看节点情况
最后,使用以下命令,将节点删除
../redis-trib.rb del-node 192.168.230.129:6383 863203beac4e9e1fd85b218fc388f8b8ac9d2218
三、为主节点添加从节点
1.首先将新节点添加到集群中,使用命令
../redis-trib.rb add-node 192.168.230.129:6383 192.168.230.129:6380
2.执行以下命令,将添加至某个主节点
../redis-cli -c -h 192.168.230.129 -p 6383 cluster replicate 52f6a45a1e968ab150a50127f29e9f0b3efbae9c
注:后面的node_id为要添加主节点的ID
3.使用下面命令来确认一下192.168.230.129:6383是否已经成为192.168.230.129:6380的从节点
../redis-cli -c -h 192.168.230.129 -p 6380 cluster nodes | grep slave | grep 52f6a45a1e968ab150a50127f29e9f0b3efbae9c
可看到6380的两个从节点:
查看节点之间的关系
redis cluster 的自动化 slave 迁移实现更强的高可用架构的部署方案
slave 的自动迁移:比如现在有 10 个 master,每个有 1 个 slave,新增了 3 个 slave 作为冗余,有的 master 就有 2 个 slave 了(出现了salve冗余),其他的 master 还是只有 1 个 slave
如果某个 master 的 slave 挂了,那么 redis cluster 会自动迁移一个冗余的 slave 给那个 master
这样的好处:如果你每个 master 只有一个 slave,万一说一个 slave 死了,然后很快,master也死了,那可用性还是降低了,增强了高可用性
看下现在的集群状态,如下图:
集群状态
上图可以看到,7001 master 上有 2 slave 。
这时候我们将192.168.43.17:7003 master 的 slave kill 掉:
info Replication //查看redis 实例的主从信息
查看7003 master 的 slave
kill 进程 和 rm -rf /var/ run/redis_7006.pid,如下图:
kill 7006 redis
再次看现在的集群状态,如下图:
集群状态变化
从上图结合前面的集群状态信息,可以看出redis cluster 自动的将 7001 中多余的slave 迁移到了 7003 上。
当再度将7006 redis 实例启动后,7003 master 就会有2个slave 了。
7006 redis 启动后
总结:在redis cluster 集群中,如果某个master 下没有了slave ,其他master 中有多余的slave 的话,集群会自动slave 迁移,由此可以见,可以利用该特性,在生产环境中,适当的添加冗余的slave 实例,可以很大程度上提高集群的高可用性
本文地址:https://blog.csdn.net/liuerchong/article/details/107317751
推荐阅读
-
高并发高可用复杂系统中的缓存架构(十五) 缓存架构讲解,如何保证缓存数据库一致性
-
高并发高可用复杂系统中的缓存架构(三) 能够支撑高并发 + 高可用 + 海量数据 + 备份恢复的 redis 的重要性
-
高并发高可用复杂系统中的缓存架构(四) redis架构基础
-
高并发高可用复杂系统中的缓存架构(十三) redis集群
-
高并发高可用复杂系统中的缓存架构(三) 能够支撑高并发 + 高可用 + 海量数据 + 备份恢复的 redis 的重要性
-
高并发高可用复杂系统中的缓存架构(十五) 缓存架构讲解,如何保证缓存数据库一致性
-
高并发高可用复杂系统中的缓存架构(四) redis架构基础
-
高并发高可用复杂系统中的缓存架构(十三) redis集群