云端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