<返回更多

火山引擎 Redis 云原生实践

2021-04-20    
加入收藏

redis 简介

Redis 是大家日常工作中使用较多的典型 KV 存储,常年位居 DB-Engines Key-Value 存储第一。Redis 是基于内存的存储,提供了丰富的数据结构,支持字符串类型、哈希/列表/集合类型以及 stream 结构。Redis 内置了很多特性,其中比较重要的有:

 

 

Redis 的典型应用场景有以下 3 种:

 

Redis 协议是二进制安全的文本协议。它很简单,可以通过 telnet 连接到一个 Redis server 实例上执行 get 和 set 操作。

K8s 简介

K8s 是一个容器编排系统,可以自动化容器应用的部署、扩展和管理。K8s 提供了一些基础特性:

 

现实工作中遇到的服务根据是否需要数据持久化可分为有状态服务和无状态服务。不需要数据持久化的服务被认为是无状态的,包含以下几种类型:

 

有状态服务需要稳定的持久化存储。除此之外,可能还会有一些其它的特性要求:

在 K8s 上,我们一般会用 StatefulSet resource 来托管有状态服务。

Redis 云原生实践

下面将介绍火山引擎 Redis 云原生实践。首先我们会明确 Redis 云原生的目标,主要有以下几个:

 

Redis 集群架构

下面介绍一下我们的 Redis 集群架构。集群里有三个组件:Server、Proxy 和 Configserver,分别完成不同的功能。

火山引擎 Redis 云原生实践

 

结合以上介绍的 Redis 架构以及 K8s 的特性,我们抽象了一个 Redis 集群在 K8s 集群上部署的基本形态:

 

Redis Server 启动的时候需要一些配置文件,里面涉及到一些用户名和密码,我们是用 Secret 来存储的。在 Server Pod 运行的时候通过 volume 机制挂载到 Server Pod 内部。

对于 Proxy,通过 HPA,基于 Proxy 的 CPU 利用率,支持 Proxy 服务的动态扩缩容。

火山引擎 Redis 云原生实践

 

放置策略

对于一个 Redis 集群涉及到的 Server 和 Proxy 组件,我们有一些放置策略的要求,比如:

 

存储

存储使用的是 PVC 加 PV 再加上具有动态供给能力的 StorageClass。使用 StorageClass 是为了抽象不同的存储后端,可支持本地磁盘和分布式存储。可以通过 StorageClass 的配置直接申请对应的存储,不用了解具体后端的实现。

 

另外,我们使用的是支持动态供给的 StorageClass,可自动按需创建不同大小的 PV。如果使用静态供给,就无法提前预知所有 Redis 实例的规格,也无法把它们对应的指定数量的 PV 都创建出来。

Redis 云原生功能介绍

Redis 云原生化以后,Operator 组件是基于 Operator Pattern 实现的一个 custom controller,主要用于编排 Redis Cluster resource,管理 Redis 集群的一些变更。Configserver 也部署在 K8s 上,所有跟 Redis 相关的组件都是云原生化的

新建集群

火山引擎 Redis 云原生实践

 

  1. 对于常见的新建集群的请求,会先发给 ApiServer。ApiServer 接收到请求之后,会通过 client go 的 watch 机制让 Operator 感知到。
  2. 随后 Operator 会请求 ApiServer 创建对应 Server 的 StatefulSet。
  3. K8s 把所有 Server 的 StatefulSet 创建成功之后,等所有的 Pod 都处于 ready 状态,这时所有分片内的 Server Pod 之间是没有主从关系的。
  4. Operator 感知到所有的 StatefulSet 都已经处于 ready 的状态之后,会获取所有 Server Pod 信息,并注册到 Configserver。
  5. Configserver 接下来会连接到所有分片内的 Slave 节点,执行实际的 SLAVEOF 命令,保证建立真正的主从关系。
  6. Operator 会定期查询 Configserver 里建立主从关系的进度。等所有分片的主从关系建立成功之后, Operator 会请求 ApiServer 把对应的 Proxy 创建出来。
  7. Proxy 创建出来之后,会去 Configserver 拉取最新的拓扑,保证对外提供服务的时候可以把请求打给后端正常的分片。

 

分片扩容

火山引擎 Redis 云原生实践

 

在实际使用的过程中如果遇到容量不足的情况,需要进行水平扩容。分片扩容的请求也是类似的:

  1. 请求发给 ApiServer。
  2. ApiServer 把请求推送给 Operator。
  3. Operator 感知到之后,会先给 ApiServer 发请求,把新的分片对应的 StatefulSet 创建出来。
  4. K8s 会把新分片的 StatefulSet 创建好,在处于 ready 状态之后,一个 StatefulSet 下的每个 Pod 也都是独立的状态,没有建立真正的主从关系。
  5. Operator 获知新创建的 Server StatefulSet 分片已经处于 ready 状态之后,会把新的 Server 分片的实例地址注册到 Configserver。Configserver 现在会有两个阶段:
  6. 第一步:指导新分片内真实主从关系的建立。即连到所有的新分片的 Slave 上,执行 SLAVEOF 的命令;
  7. 第二步:指导数据从老分片迁移到新分片。这样新的分片才能发挥作用,这一步很重要。
  8. Operator 会一直检查数据迁移或者 rebalance 的进度。等进度结束之后,Operator 会更新 Redis Cluster 里 status 的字段,反映出来当前的分片扩容的操作已经结束了。

 

分片缩容

火山引擎 Redis 云原生实践

 

分片缩容的流程和分片扩容类似:请求先发送给 ApiServer,Operator 会感知到请求,然后把缩容分片的请求发送给 Configserver。

Configserver 此时做的事情是:

 

  1. 先指导数据迁移。考虑到后边的一些分片下线,需要把分片上的数据先迁移到其他可用分片上,保证数据不丢。
  2. Operator 会一直查询 Configserver 指导的数据 rebalance 的进度。等缩容操作在 Configserver 完成之后,Operator 会请求 ApiServer 执行真正的 Server StatefulSet 删除,这时才是安全的删除操作。

 

组件升级

火山引擎 Redis 云原生实践

 

一个 Redis 集群会涉及到两个组件:Proxy 和 Server。

 

无状态的 Proxy 用 Deployment 托管,如果要进行组件升级,直接升级对应的 image 即可。

 

Server 是一个有状态的组件,它的升级流程相对来说复杂一点。为了简化流程,我们以 Server 只有 1 分片的 Redis 集群为例,介绍升级过程。

  1. Server 组件的升级请求发送给 ApiServer,ApiServer 接收到这个请求之后会把它推送给 Operator。
  2. Operator 首先会按照分片内 Pod 编号从大到小的顺序选择要升级的 Pod。
  3. 选定 Pod 之后,会把它从 Configserver 的读拓扑里摘掉。(如果要摘除的这个 Pod 在集群拓扑里是 Master,我们会先调用 Configserver 的 API,执行 Failover,把它变成 Slave,然后再把它从读的拓扑里边给摘除掉。)
  4. 之后,Operator 等待 30 秒。这个机制的出发点是:
  5. 首先,Proxy 去 Configserver 拉取配置是异步过程,可能需要经过至少一轮的数据同步才能正常拿到数据。等待 30 秒主要是为了保证所有的 Proxy 都已经拿到了最新的读拓扑,新的读请求不会再发送到要升级的 Server 节点上。
  6. 另外,我们要保证等待 30 秒的时间,让已经被要升级的 Server Pod 接收的这些请求都成功地被处理,并且返回之后,才能把要升级的 Server Pod kill 掉。
  7. 30 秒之后请求 ApiServer 执行实际的 Pod 删除操作。删除之后 K8s 会重新调度一个新的 Pod 起来,这时新创建的 Server Pod 也是一个独立的 Server 的状态,没有跟任何节点建立主从关系。Operator 感知到新的 Server Pod 已经处于 ready 的状态,会把它注册到 Configserver。
  8. Configserver 连到新的 Server Pod 上,根据它所处的分片跟所在分片的 Master 节点建立主从关系,同时进行数据同步。
  9. Operator 会定期检查新的 Server 分片在 Configserver 是否已经完成数据同步。如果是,Operator 才会认为一个 Server Pod 完成了升级。该分片内其他所有 Server pod 的升级流程都是类似的,直到该分片内所有 Server Pod 都升级完,才认为这个分片升级完成。最后 Operator 会更新自己 Redis Cluster 的 CRD 里对应的 Status 状态信息,反映当前组件升级的流程和变更操作已经结束了。

总结展望

本次分享的以 Redis 为例,介绍了有状态服务部署到 K8s 的抽象流程,并介绍了火山引擎在 Redis 云原生方向的一些探索和实践。目前火山引擎对于 Redis 云原生已经完成了基本功能的构建,未来会在动态扩缩容、异常恢复、细粒度的资源分配和管理方面,结合 K8s 的特性,进行更多深层次的思考和实践,期望通过云原生化的方式,进一步提升运维自动化能力和资源的利用率。

 

Q&A

Q1:没用 Cluster 的模式吗?

A:没有,最早也使用过 Cluster 模式,后来业务体量变大,发现 Cluster 有集群规模上限,不能满足业务的需求。

Q2:Redis 的 Proxy 会计算 Key 在哪个分片吗?

A:会的,Proxy 会参考类似 Redis Cluster 的 Key Hash 算法对 Key 进行 hash,之后分布到不同的 Server 分片上。

Q3:如何界定 Slave 可以提升为 Master?切换步骤是怎样的?

A:Configserver 会定期给 Master 发送 health check 请求进行探活。只有连续多次对一个 Master 的探活都失败时,才会认为 Master 不可用。这时 Configserver 会从分片内所有 Slave 中选择可用的提升成新的 Master(不是所有的 Slave 都可用,可能某一个 Slave 也挂了,或者主从数据同步的延迟比较高)。

Q4:Proxy 是每个 Redis 集群独有还是所有集群共享的?

A:Proxy 不是每个 Redis 集群独占的。首先,所有集群共享一个 Proxy 集群,有隔离性的问题。另外,Proxy 支持动态扩缩容,可以做到弹性资源扩缩容,所以不会导致资源浪费。

Q5:系统的稳定性如何,主从切换耗时怎样?

A:稳定性挺好。主从切换的耗时是一个策略问题,需要做一些 tradeoff。如果判断策略太激进,可能会因为临时的网络抖动等因素频繁触发主从切换。实际使用中我们的主从切换耗时在 10s 左右。

Q6:Redis 在什么规模等级下的 K8s 部署会需要修改较多默认配置或者直接更改源码? 在动态扩容的基础上建立 Redis 集群是否会加大困难?有什么方式可以让 Redis 集群无限扩容吗?最多到多少?

A:Redis 目前部署的 K8s 集群规模可选,根据需要的 Redis 集群容量来选择 K8s 规模就可以。适配云原生会需要调整一些组件之间的服务发现方式,但是不需要太多源码的修改。我们目前只支持 Proxy 的动态扩缩容,Server 是有状态的服务,还不太好接入 HPA(因为可能会涉及到一些数据的迁移),虽然 HPA 也支持对 Statefulset 服务的自动化扩缩容。我们的 Redis 架构理论上集群的规模可以很大,现在 CRD 的限制是一个 Redis 集群最多 1024 个分片。

关于火山引擎

火山引擎是字节跳动旗下的数字服务与智能科技品牌,基于公司服务数亿用户的大数据、人工智能和基础服务等技术能力,为企业提供系统化的全链路解决方案,助力企业务实地创新,给企业带来持续、快速增长。

声明:本站部分内容来自互联网,如有版权侵犯或其他问题请与我们联系,我们将立即删除或处理。
▍相关推荐
更多资讯 >>>