欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页  >  IT编程

高并发高可用复杂系统中的缓存架构(十三) redis集群

程序员文章站 2022-06-17 21:18:25
上一篇 将 redis cluster 搭建起来了redis cluster 提供了多个 master,数据可以分布式存储在多个 master 上; 每个 master 都带着 slave,自动就做读写分离; 每个 master 如果故障,那么就会自动将 slave 切换成 master,高可用redis cluster 默认是不支持 slave 节点读或者写的,跟我们手动基于 replication 搭建的主从架构不一样的slave node 上 使用 readonly,get,这个时候....

上一篇 将 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两个节点

         查看原有节点:          

高并发高可用复杂系统中的缓存架构(十三) redis集群

        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 是原存在的任一主节点

      高并发高可用复杂系统中的缓存架构(十三) redis集群

     查看刚才新增的节点   

高并发高可用复杂系统中的缓存架构(十三) redis集群

     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 集群任一个旧节点  高并发高可用复杂系统中的缓存架构(十三) redis集群

查看节点情况,可看见从节点已添加

高并发高可用复杂系统中的缓存架构(十三) redis集群

但是,其主节点也就是6383的哈希槽为空,需要重新分配槽,执行命令:

 ../redis-trib.rb reshard 192.168.230.129:6380 

 注释: 192.168.230.129:6380 集群任一个旧节点

高并发高可用复杂系统中的缓存架构(十三) redis集群

然后再输入yes,redis集群就开始分配哈希槽了.....

至此,一个新的主节点就添加完成了,执行命令查看现在的集群中节点的状态

可看到已分配

高并发高可用复杂系统中的缓存架构(十三) redis集群

高并发高可用复杂系统中的缓存架构(十三) redis集群

二、删除节点

     1、删除从节点

         删除从节点,直接使用以下命令即可

         ../redis-trib.rb del-node 192.168.230.129:6393 05945dcae79aca1425f68ca95f2aaf4d44b2167a

        注释:192.168.230.129:6393  节点地址

                   05945dcae79aca1425f68ca95f2aaf4d44b2167a   节点node_id

       高并发高可用复杂系统中的缓存架构(十三) redis集群

     2、删除主节点

          因为主节点含有槽数,所以,首先要把节点中的哈希槽转移到其他节点中,执行命令

          ../redis-trib.rb reshard 192.168.230.129:6380 

         注:192.168.230.129:6380  集群中任一主节点     高并发高可用复杂系统中的缓存架构(十三) redis集群

然后再输入yes,等待转移完成......

查看节点情况

高并发高可用复杂系统中的缓存架构(十三) redis集群

最后,使用以下命令,将节点删除

 ../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集群

查看节点之间的关系

高并发高可用复杂系统中的缓存架构(十三) redis集群

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也死了,那可用性还是降低了,增强了高可用性

看下现在的集群状态,如下图:

 

高并发高可用复杂系统中的缓存架构(十三) redis集群

集群状态

 

上图可以看到,7001 master 上有 2 slave 。

这时候我们将192.168.43.17:7003 master 的 slave kill 掉:

info Replication //查看redis 实例的主从信息

 

高并发高可用复杂系统中的缓存架构(十三) redis集群

查看7003 master 的 slave

kill 进程 和 rm -rf /var/ run/redis_7006.pid,如下图:

 

高并发高可用复杂系统中的缓存架构(十三) redis集群

kill 7006 redis

再次看现在的集群状态,如下图:

 

高并发高可用复杂系统中的缓存架构(十三) redis集群

集群状态变化

从上图结合前面的集群状态信息,可以看出redis cluster 自动的将 7001 中多余的slave 迁移到了 7003 上。

当再度将7006 redis 实例启动后,7003 master 就会有2个slave 了。

 

高并发高可用复杂系统中的缓存架构(十三) redis集群

7006 redis 启动后

总结:在redis cluster 集群中,如果某个master 下没有了slave ,其他master 中有多余的slave 的话,集群会自动slave 迁移,由此可以见,可以利用该特性,在生产环境中,适当的添加冗余的slave 实例,可以很大程度上提高集群的高可用性

 

本文地址:https://blog.csdn.net/liuerchong/article/details/107317751