云端redis管控方式

 

目录

openstack

openstack简介

openstack框架下redis管控结构

docker+k8s

docker简介

k8s简介

docker+k8s框架下redis管控结构

云原生

云原生简介

redis本身对云原生的支持

去中心化的集群模式

集群基于slot的扩缩容

对docker部署的专门配置

云原生框架下redis管控结构

阿里云

腾讯云



openstack

openstack简介

OpenStack是一个开源的云计算管理平台项目,由几个主要的组件组合起来完成具体工作。OpenStack支持几乎所有类型的云环境,项目目标是提供实施简单、可大规模扩展、丰富、标准统一的云计算管理平台。OpenStack通过各种互补的服务提供了基础设施即服务(IaaS)的解决方案,每个服务提供API以进行集成。Openstack最为人称道的特性在于每个组件之间的相互独立,使得openstack框架天生支持在云服务的几个提供层面(Iaas Paas Saas Baas,然而Faas似乎力有不逮)上灵活地组合运行。

openstack框架下redis管控结构

在云上提供redis明显属于DBaas(数据库即服务,DBaas属于Paas还是Saas有些微妙,不展开讨论),openstack中有一个专门的组件负责DBaas的管控,即Trove。Trove在openstack框架中多用于负责数据库的管理,调用下层的Nova、Neutron、Cinder等服务提供的API,创建含有数据库服务的虚拟机。其实我认为从某种意义上讲,Trove其实是一种Saas服务的管控方式,不仅限于数据库。

下面是一个Trove管控一个redis集群的实例。trove-api是trove中对外提供接口的部分,接收到请求后调用trove-taskmanager的程序。trove-taskmanager通过调用下层的Nova、Neutron、Cinder等服务提供的API,创建出三个虚机(Nova),虚机中不仅有redis服务,还有一个负责存储的硬盘(Cinder),并且虚机之间网络打通可以互相通信(Neutron)。创建完毕后,trove-taskmanager通过对每个trove-guestagent发送实际业务配置,trove-guestagent将整个redis集群建立起来。期间产生的各种信息记录,通过trove-conductor落到openstack自身的数据库保存。

docker+k8s

docker简介

docker是一个虚拟环境容器,可以将你的开发环境、代码、配置文件等一并打包到这个容器中,并发布和应用到任意平台中。关于容器,有一句相当精准的总结:其实,容器就是一个视图隔离、资源可限制、独立文件系统的进程集合。将redis服务部署在docker中,制作好镜像,就能导入到在任何环境上运行容器。redis官方已经提供好了docker镜像,开发者并不需要从头开始制作,只要docker pull一个然后做一些自己的定制即可。

k8s简介

直接摘抄k8s中文社区的简介:

Kubernetes是一个开源的,用于管理云平台中多个主机上的容器化的应用,Kubernetes的目标是让部署容器化的应用简单并且高效(powerful),Kubernetes提供了应用部署,规划,更新,维护的一种机制。

docker其实也有自身的集群管理工具swarm,但是其生态活跃程度并不如k8s。swarm和k8s的对比:https://www.cnblogs.com/i6first/p/9399213.html

docker+k8s框架下redis管控结构

如下图所示,k8s分为master和node两种角色,redis运行其中接受管理。具体master和node中各个进程如何交互管理就不在此展开了。

不得不说,k8s将管控的最小单位定义为Pod,是非常匠心独运的一个设计。Pod可以是认为在Docker Container的基础上加了一层封装,让多个(也可以是单个)容器对外提供的服务有一个统一的状态,这样的管控方式与Redis的集群方式不谋而合。在docker+k8s的管控结构中,每个Pod是一个redis集群中的节点,其中有一主多备的多个容器,以Pod为单位在几个物理的Node上进行调度,管控层关注每个Pod的状态,Pod内部关注自己的主从切换。但是这里也有冲突的店,假如每个Pod内的容器不能够动态的变化,那么redis提供的集群从节点平衡的功能就不能够发挥作用。

云原生

云原生简介

云原生不应该说是一种管控框架,而应该说是一种软件开发的指导思想和运作模式。即软件开发在设计阶段就应该考虑自身是跑在云端的,设计时应该注重发挥云平台的优势,在各种传统软件较难完成的方面能够轻易地复用云平台的机制(分布式、弹性扩缩容、高可用等)。

redis本身对云原生的支持

去中心化的集群模式

redis的集群并不存在领头节点这样的概念,每个节点负责一部分slot的处理,每个节点内存在几个redis实例,以一主多备的结构存在,并且failover也只发生在节点内部。为了保证整个集群的稳定性,redis也提供了从实例自动平衡的功能,会尽量维持整个集群的所有节点都有主备实例。

集群基于slot的扩缩容

redis的集群处理key的时候,是以16384个slot对key进行划分,每个集群中的节点分别处理部分slot。在集群需要扩缩容的时候可以简单的通过slot的迁移来达到目的,业务层不需要做什么处理,新的key就自然地可以落到新的节点上。对于没有专门适配集群的client(可以感知slot的变化)的业务来说,旧key的迁移是需要做的,但是旧key的迁移会是一个比较大的问题,阻塞式的迁移在遇到大key或者热点key的时候都不太好处理,可以考虑依赖应用层和后端持久化的惰性更新。

对docker部署的专门配置

提供了以下配置

cluster-announce-ip
cluster-announce-port
cluster-announce-bus-port

便于在容器内运行时,组成集群能够适配上层的网络管理

云原生框架下redis管控结构

这里我们关注下头部厂商发布的一些帖子,此处不过多地展开。

阿里云

https://zhuanlan.zhihu.com/p/150573190

腾讯云

https://cloud.tencent.com/developer/article/1651568

 

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值