火山引擎 Redis 云原生实践
点击上方👆蓝字关注我们！
本文整理自火山引擎开发者社区首次 Meetup 中的分享《Redis 云原生实践》，主要介绍了将 Redis 部署到 K8s 的抽象流程，以及火山引擎在 Redis 云原生方向的探索和实践。
Redis 简介
复制：Redis 支持异步的全量和增量同步，可以把数据从 Master 复制到 Slave， 实现 Redis 数据的高可用。 持久化：支持数据的持久化，可以通过 RDB 和 AOF 机制实现数据落盘。 支持哨兵工具：哨兵工具的主要工作模式是监控 Master 节点的健康状况。当发现 Master 节点不可用时，会主动执行 Failover， 把 Slave 节点提升成 Master，保证 Redis 服务的高可用。 提供集群模式：单体 Redis 实例受限于物理机内存，当需要很大的 Redis 集群容量时，可以使用 Redis 集群模式。Redis 集群模式的原理是把保存在其中的数据做了分片，每一部分数据由不同的 Redis 实例承担。
缓存：因为 Redis 是基于内存的存储，它的读写请求会在内存执行，请求响应的延迟很低，所以很多场景下会把 Redis 当做缓存使用。 数据库：Redis 支持持久化，可以把它当做 KV 数据库使用。 消息队列：Redis 支持 stream 数据，在 stream 数据结构基础上封装了 pub-sub 命令，实现了数据的发布和订阅，即提供了消息队列的基本功能。
K8s 简介
自动装箱：可指定 K8s 里 Pod 所需资源的最小值和最大值，即 limit 和 request 的值。K8s 可以根据 request 的值做 Pod 调度，在一个节点上拉起 Pod。 服务发现与负载均衡：K8s 提供基于 DNS 的服务发现机制，同时也提供基于 service 的负载均衡。 自动化上线和回滚：这里会涉及到 K8s 的工作负载资源。K8s 提供几种不同的工作负载资源对应不同的业务场景。 这些不同的工作负载资源可以实现服务的配置变更，例如更新 image、升级 binary、进行副本的扩缩容等。 支持 Deployment/DaemonSet 支持 StatefulSet 支持 CronJob/Job 水平扩缩容：K8s 天然支持水平扩缩容，可以基于 Pod 的 CPU 利用率、内存利用率以及第三方自定义 metrics 对 Pod 进行水平动态扩缩容。 存储编排：K8s 支持基于 PV 和 PVC 的存储供应模式，可以通过 PV 和 PVC 在 Pod 内部使用存储。 自我修复：举一个例子就是副本保持。比如用 Deployment 来托管一个服务，如果 Deployment 下的一个 Pod 所在的宿主机出现了不可用的情况， K8s 会在可用的节点上重新拉起一个新的 Pod 来提供服务。
API 类服务：可在任意节点上执行。如果要在 K8s 上部署这类服务，可使用 K8s Deployment。 Agent 或 Deamon 类服务：需要部署在每一台机器上，而且每台机器上最多部署一个进程。在 K8s 上可选择 DaemonSet 来完成对应的部署。 还有一类无状态服务对固定的唯一标识有需求。要满足这些需求，可使用 K8s 的 StatefulSet 来满足。虽然 StatefulSet 是用来部署有状态服务的，但它可提供固定的唯一标识，也可用来托管无状态服务。
稳定的唯一标识 有序、优雅地部署和缩放 有序的自动滚动更新
Redis 云原生实践
资源的抽象和交付由 K8s 来完成，无需再关注具体机型。在物理机时代我们需要根据不同机型上的 CPU 和内存配置来决定每个机型的机器上可以部署的 Redis 实例的数量。通过 Redis 云原生，我们只需要跟 K8s 声明需要的 CPU 和内存的大小，剩下的调度、资源供给、机器筛选由 K8s 来完成。 节点的调度由 K8s 来完成。在实际部署一个 Redis 集群时，为了保证高可用，需要让 Redis 集群的一些组件满足一定的放置策略。要满足放置策略，在物理机时代需要运维系统负责完成机器的筛选以及计算的逻辑，这个逻辑相对比较复杂。K8s 本身提供了丰富的调度能力，可以轻松实现这些放置策略，从而降低运维系统的负担。 节点的管理和状态保持由 K8s 完成。在物理机时代，如果某台物理机挂了，需要运维系统介入了解其上部署的服务和组件，然后在另外一些可用的机器节点上重新拉起新的节点，填补因为机器宕机而缺少的节点。如果由 K8s 来完成节点的管理和状态的保持，就可以降低运维系统的复杂度。 标准化 Redis 的部署和运维的模式。尽量减少人工介入，提升运维自动化能力，这是最重要的一点。
Server：存储数据的组件，即 Redis Server，其后端部署模型是一个多分片的模型。分片之间的 Server Pod 没有通信，为 share-nothing 的架构。分片内部为一主多从的模式，可以一主一从、一主两从，甚至更多。 Proxy：承接 client 发来的请求，同时根据读写拓扑，把请求转发给后端的 Server 分片。 Configserver：配置管理组件，本身是无状态的，所有的状态信息都存储在 etcd。集群生命周期里 Server 所有的分片信息都保存在 Configserver 里。Configserver 会对每一个分片的 Master 节点进行定期探活，如果发现某一个分片的 Master 节点不可用，就会执行 Failover，把分片内可用的 Slave 提成新的 Master，保证分片可继续对外提供服务。同时，Configserver 也会定期根据 Failover 或其他一些实例信息的变更来更新自己的读写拓扑关系，保证 Proxy 可以从 Configserver 拉取新的正确的配置。
使用 Deployment 将无状态的 Configserver 部署在 K8s 上。因为 Configserver 可被所有 Redis 集群共用，为了简化运维复杂度，我们规定所有的 Redis 集群共用一个 Configserver。 Proxy 也是无状态的组件，也用 Deployment 来部署。 因为我们有多分片，而且 Server 是有状态的，所以每一个分片用 StatefulSet 进行托管。在新建集群时，我们默认分片内的 0 号 Pod 为 Master Pod，其余所有的 Pod 是 Slave。这是一个初始状态，后续可能会跟随 Failover 或其他异常发生变更，但是 Configserver 里会实时记录最新的状态信息。
同一个 Server 分片下的节点不能在同一台机器上，即，一个分片内的主从节点不能在同一台机器上。转换成 K8s 里面的模型，即我们希望一个 StatefulSet 下所有的 Pod 部署在不同的机器上。我们会利用 Pod-AntiAffinity 下面的 required 语义，来保证 StatefulSet 下所有的 Pod 都部署在不同的机器上。 一个集群下的 Proxy Pod 需要尽可能分布在不同的机器上，可通过 Pod-AntiAffinity 下的 preferred 语义加上拓扑分布约束来满足。preferred 语义只能保证 Pod 尽可能分布在不同的机器上，为了避免极端情况下所有 Pod 都在同一台机器上的情况，我们会使用拓扑分布约束。
Redis 云原生功能介绍
对于常见的新建集群的请求，会先发给 ApiServer。ApiServer 接收到请求之后，会通过 client go 的 watch 机制让 Operator 感知到。 随后 Operator 会请求 ApiServer 创建对应 Server 的 StatefulSet。 K8s 把所有 Server 的 StatefulSet 创建成功之后，等所有的 Pod 都处于 ready 状态，这时所有分片内的 Server Pod 之间是没有主从关系的。 Operator 感知到所有的 StatefulSet 都已经处于 ready 的状态之后，会获取所有 Server Pod 信息，并注册到 Configserver。 Configserver 接下来会连接到所有分片内的 Slave 节点，执行实际的 SLAVEOF 命令，保证建立真正的主从关系。 Operator 会定期查询 Configserver 里建立主从关系的进度。等所有分片的主从关系建立成功之后， Operator 会请求 ApiServer 把对应的 Proxy 创建出来。 Proxy 创建出来之后，会去 Configserver 拉取最新的拓扑，保证对外提供服务的时候可以把请求打给后端正常的分片。
请求发给 ApiServer。 ApiServer 把请求推送给 Operator。 Operator 感知到之后，会先给 ApiServer 发请求，把新的分片对应的 StatefulSet 创建出来。 K8s 会把新分片的 StatefulSet 创建好，在处于 ready 状态之后，一个 StatefulSet 下的每个 Pod 也都是独立的状态，没有建立真正的主从关系。 Operator 获知新创建的 Server StatefulSet 分片已经处于 ready 状态之后，会把新的 Server 分片的实例地址注册到 Configserver。Configserver 现在会有两个阶段： 第一步：指导新分片内真实主从关系的建立。即连到所有的新分片的 Slave 上，执行 SLAVEOF 的命令； 第二步：指导数据从老分片迁移到新分片。这样新的分片才能发挥作用，这一步很重要。 Operator 会一直检查数据迁移或者 rebalance 的进度。等进度结束之后，Operator 会更新 Redis Cluster 里 status 的字段，反映出来当前的分片扩容的操作已经结束了。
先指导数据迁移。考虑到后边的一些分片下线，需要把分片上的数据先迁移到其他可用分片上，保证数据不丢。 Operator 会一直查询 Configserver 指导的数据 rebalance 的进度。等缩容操作在 Configserver 完成之后，Operator 会请求 ApiServer 执行真正的 Server StatefulSet 删除，这时才是安全的删除操作。
Server 组件的升级请求发送给 ApiServer，ApiServer 接收到这个请求之后会把它推送给 Operator。 Operator 首先会按照分片内 Pod 编号从大到小的顺序选择要升级的 Pod。 选定 Pod 之后，会把它从 Configserver 的读拓扑里摘掉。（如果要摘除的这个 Pod 在集群拓扑里是 Master，我们会先调用 Configserver 的 API，执行 Failover，把它变成 Slave，然后再把它从读的拓扑里边给摘除掉。） 之后，Operator 等待 30 秒。这个机制的出发点是： 首先，Proxy 去 Configserver 拉取配置是异步过程，可能需要经过至少一轮的数据同步才能正常拿到数据。等待 30 秒主要是为了保证所有的 Proxy 都已经拿到了最新的读拓扑，新的读请求不会再发送到要升级的 Server 节点上。 另外，我们要保证等待 30 秒的时间，让已经被要升级的 Server Pod 接收的这些请求都成功地被处理，并且返回之后，才能把要升级的 Server Pod kill 掉。 30 秒之后请求 ApiServer 执行实际的 Pod 删除操作。删除之后 K8s 会重新调度一个新的 Pod 起来，这时新创建的 Server Pod 也是一个独立的 Server 的状态，没有跟任何节点建立主从关系。Operator 感知到新的 Server Pod 已经处于 ready 的状态，会把它注册到 Configserver。 Configserver 连到新的 Server Pod 上，根据它所处的分片跟所在分片的 Master 节点建立主从关系，同时进行数据同步。 Operator 会定期检查新的 Server 分片在 Configserver 是否已经完成数据同步。如果是，Operator 才会认为一个 Server Pod 完成了升级。该分片内其他所有 Server pod 的升级流程都是类似的，直到该分片内所有 Server Pod 都升级完，才认为这个分片升级完成。最后 Operator 会更新自己 Redis Cluster 的 CRD 里对应的 Status 状态信息，反映当前组件升级的流程和变更操作已经结束了。
总结展望