降本40%!Redis多租户集群的容器化实践

石鹏 2021-02-05 16:03:42

 

本文根据石鹏老师在〖deeplus直播第260期〗线上分享演讲内容整理而成。(文末有获取本期PPT&回放的方式,不要错过)

 

石鹏

VIPKID基础架构存储平台负责人

 

  • 曾就职于摩托罗拉、爱奇艺,10余年专注于高并发、高可用、分布式存储方向,发表过相关专利20余篇;

  • 目前负责VIPKID基础架构存储平台,包括Redis平台、Kafka平台、RocketMQ平台、 ElasticSearch搜索平台、数据库访问平台、对象存储平台等。

 

本文主要分享内容如下:

 

 

一、为什么需要Redis多租户平台

 

1、Redis集群最初的样子
 

在公司发展初期,公司只有虚机环境,没有容器。Redis集群分两种,一种是独享集群,即一个集群里只有一个应用;另一种是混部的集群,即多个应用共享同一个集群。

 

 

现在看他们各自的优缺点:

 

1)独享部署

 

优点:

 

  • 稳定性高,相比混部集群,不会被其他应用影响。

 

缺点:

 

  • 资源利用率低,不同应用无法共享Redis服务器资源:虚机最低配2C4G,且对Redis Cluster集群模式1个Redis集群至少需要3台服务器,对于访问量少的集群,会浪费成本;

  • Redis集群数多,运维成本高:虚机环境下,集群的创建、销毁、扩容、缩容、容灾等,都依赖人工运维,运维工作量跟集群数成正比。

 

2)混合部署

 

优点:

 

  • 相比独享集群,资源利用率更高;

  • 相比独享集群,集群数少,运维成本低。

 

缺点:

 

  • 不同应用可能互相影响;

  • 不用应用存在key重复的风险。

 

对于初创型公司,如果也有同样的Case,可以借鉴我接下来讲的方案优化,降本提效、提升稳定性。

 

2、Redis多租户平台建设的初衷
 

 

我们建设Redis多租户平台,就是为了保留上面提到的独享集群和混部集群的优点,避免他们的不足。

 

建设多租户平台的目的:

 

  • 提升资源利用率;

  • 降低运维成本;

  • 确保不同租户间互不影响。

 

二、Redis多租户平台方案

 

在最初做Redis多租户平台时,公司只有虚机环境,还没有容器环境。

 

1、Redis多租户平台的设计方案
 

 

Redis多租户平台的设计图如下:

 

 

Redis多租户平台分为三部分,分别是Redis管理后台、Redis的客户端、Redis集群。

 

对于Redis集群的部署,我们没有做持久化,通过一主一从数据冗余来保证高可用:其中”主“承接所有读写流量,”从“不承接任何读写流量,仅用于”主“故障时做灾备。

 

集群模式采用的Redis Cluster。

 

某个节点的部署:

 

  • 1个虚机节点部署2个Redis实例,一主一从;

    主从不是一对:避免单个虚机节点故障时,主从同时不可用  导致丢数据,且影响业务。

  • 对于同一个redis实例,可以多个应用(即多个namespace)共享。

 

业务应用在使用Redis多租户平台前需要做什么呢?

 

  • 首先,一个业务应用要去Redis管理后台去申请一个属于这个应用的namespace,通常namespace由"集群名@应用名"组成,他作为该应用在Redis多租户平台上的唯一标识;

  • 其次,这个业务应用的负责人要提供这个应用历史的内存峰值。假设应用1的内存峰值是2G,应用2的内存峰值是3G,那么新的Redis多租户申请的资源预留2倍,及(2G+3G)*2 = 10G;

  • 最后,这个应用需要接入由我们基础架构提供的Redis客户端来访问Redis多租户集群。

 

业务应用在访问Redis多租户集群时,假设执行指令“set key1 abc”,那么Redis客户端会自动把原来的key前面加上“namespace:”前缀,即指令变成“set cluster1@app1:key1 abc",其中cluster1是Redis集群名,app1是应用名。

 

这样,我们就可以根据namespace来区分不同应用在Redis集群中的数据了。

 

但是,这个方案仍然是多个应用共享Redis集群资源,仍存在不同租户(应用)间互相影响的风险。

 

2、如何保证租户间资源互不影响
 

 

保证不同租户间资源互不影响,我们是通过“监控、告警、问题根因定位、限流or禁用指令”这四步来完成的。

 

1)监控

对于Redis集群,我们会监控ops,热key等等多维度指标,重点是内存使用率。

 

2)告警

由于我们Redis多租户集群,为用户峰值还多预留了一倍的资源,所以当用户达到内存使用峰值时,只会占用50%的内存。

 

  • 内存使用率达到60%,通过企业IM做1级告警;

  • 内存使用率达到75%,通过短信做2级告警;

  • 内存使用率达到85%,通过电话做3级告警。

 

3)问题根因定位

当告警1级时,管理员就要分析告警原因了,首先执行”RDB内存分析工具“,分析内存不足是哪个应用流量激增导致的,然后分析是bigkey导致的还是就是请求量大导致的。

 

4)限流or禁用指令

定位到问题后,通过限流或禁用指令来确保Redis集群不被激增流量打挂:

 

  • bigkey导致:采用禁用指令方式

    禁用指令的实现方案为,通过管理后台,定时下发配置给Redis客户端,指明要对该应用下的哪个key做禁用指令。

  • 流量高导致:采用限流

    限流也是管理后台下发配置给Redis客户端,做应用维度的限流。

 

3、RDB分析工具的原理
 

 

上面”问题根因定位“时用到了RDB内存分析工具,这里我们基于开源做了一些定制化开发,原理是伪装成Redis从节点,Dump RDB数据到本地内存,然后逐个key解析,分析出各应用的内存占比、bigkey top 10、key的总数。

 

另外,RDB内存分析工具会在每天业务低峰时段执行,这样,在故障时再执行RDB内存分析工具,把结果跟低峰时段的执行结果做比较,就能定位出是哪个业务应用增长快导致的告警。

 

4、问题与挑战
 

 

1)租户间资源“假”隔离

 

如果流量增长太快,来不及做限流或禁用指令,那么不同租户间理论上仍存在互相影响的微小可能。

 

挑战:怎样既能“真”隔离又能共享资源,租户间资源如果“真”隔离,就不会互相影响了。

 

2)解决激增流量告警时做限流或禁用指令都是对业务有损的

 

虽然限流或禁用指令的目标是异常使用redis的某个应用的key, 但这样做对业务是有损的。

 

挑战:能否做到租户间既不互相影响又对业务无损呢?

 

3)集群数虽减少了但运维工作量仍不小

 

相比独享集群,集群数虽少了,但集群的创建、销毁、扩容、缩容、故障容灾等,仍需要人工运维,运维工作量跟集群数成正比。

 

挑战:运维成本是否有进一步降低的空间?

 

对于这几个问题,我们在Redis容器云的方案中都一一解决了。

 

三、Redis容器云数据库平台优化实战

 

在这个阶段,我们公司开始支持容器环境,这时我们想,Redis作为有状态服务,通过上容器是否可以解决我们当前存在的问题。

 

1、为什么需要租户间资源严格隔离
 

 

按上面的分析,大家知道不同租户间的资源仅做到逻辑隔离,存在互相影响的风险,因此要消除风险,需要做到租户间严格隔离资源边界。

 

这里有人会问,Redis多租户的目的,本来就是为了共享资源提升资源利用率以降低成本,如果严格隔离了租户间的资源,那多租户的意义何在呢?

 

通常服务器的最低配是有限制的,例如2C4G,但可能我的应用仅需要0.5C1G,假设我们可以做到资源边界的严格隔离,那么2C4G的资源就仅分配给4个0.5C1G的应用,这样这4个应用就都没有了互相影响的风险。

 

达到这样的效果,我们很容易想到借助容器来实现。但做了严格的资源边界隔离,在保证租户间不会互相影响的同时,带来的弊端是不能够充分共享资源。

 

综上,我们推荐的做法是:

 

  • 对于Redis可用性非常敏感的应用,推荐采用资源的严格边界隔离方式,即一个Pod里只部署一个应用;

  • 对于Redis可用性不是非常敏感的应用,推荐采用资源的逻辑隔离方式,即一个Pod里同时部署多个应用,当激增流量时,通过容器水平扩容来解决。

 

这样在稳定性与最大限度提高资源利用率之间,根据应用对稳定性的不同要求,做出了相应的取舍。

 

2、如何借助K8S容器化Redis多租户集群
 

 

1)K8S容器化Redis多租户集群的目的

 

  • 可做租户间资源边界的严格隔离:通过容器Pod最小化资源单位;

  • 解决激增流量对集群的影响:借助Redis集群节点水平扩容机制来解决激增流量时租户间互相影响,且不再有虚机方案时限流或禁用指令对业务有损的问题;

  • 降低运维成本:容器环境运维自动化,解决Redis集群规模大,人工运维成本高的问题。

 

2)K8S容器化Redis集群面临的挑战

 

  • K8S如何部署Redis有状态服务;

  • 容器Crash后如何不影响服务可用性;

  • 容器重启后如何保证Redis内存中的数据不丢;

  • 节点水平扩容时如何做到slots迁移时不影响业务。

 

3)Redis多租户容器化的架构设计

 

 

上图主要分四个部分:

 

  • K8s管理的Redis集群;

  • K8s控制器面板;

  • Redis管理后台;

  • 由我们基础架构提供的Redis客户端。

 

由K8S管理的Redis集群设计要点:

 

  • 一个node中部署2个Pod,一主一从,但主从不是一对,避免一个node宕机一主一从同时故障导致丢数据;同时这一主已从也不是同一个集群,目的是确保一个node宕机时,最多只影响一个集群中的一个主节点;

  • 基于开源实现了定制化的Redis Operator;

  • 用anti-affinity来确保同一组master和slave不会部署到同一个node上;

  • VKShark服务为K8s的api-server的代理和controller:当访问k8s api-server时,通过VKShark做代理;同时VKShark作为controller会监听k8s node的节点的变化,然后通知Redis管理后台;

  • 通过Redis operator的CRD来配置一组主从节点作为相同的StatefulSet管理。

     

节点扩容调用流程:

 

  • 由Redis管理后台选择集群,输入扩容节点数如1后,点击按钮发起节点扩容请求;

  • 扩容请求经由VKShark做代理,访问k8s api-server, api-server会把相应的CRD持久化到ETCD中;

  • Redis operator监控api-server, 发现有扩容请求,会创建statefulset,通过api-server调用k8s API做节点扩容,新建一主一从两个Pod;

  • Redis operator经过api-server监听Pod的变化,并把新节点加入到Redis Cluster集群;

  • VKShark通过api-server监听Pod的变化,发现有新节点,通知Redis管理后台;

  • Redis管理后台先检测新的Pod是否已加入到了Redis Cluster集群,如已加入则只需migrate指令做槽位迁移;

  • Redis管理后台会定时下发Redis的集群节点信息给Redis客户端;

  • Redis客户端用最新的节点信息计算key的slot。

 

3、如何让激增流量租户互不影响且对业务无损
 

 

1)容器可快速自动水平扩容  

 

有了容器环境,对于Redis可用性敏感的应用,可以一个Pod只部署一个应用,这个应用间不会互相争抢资源。那么对于某个应用,如果他的流量激增,容器环境也可以通过自动水平扩容来解决,而不必像虚机时Redis多租户方案那样通过限流或禁用指令对业务有损的方式。

 

当然,这里节点不能无限制扩容,当扩容节点数达到我们预先设置的最大阈值时,说明该流量激增属于”非正常“,有可能是系统bug等导致,这时会采取限流与禁用指令的方式

 

2)Redis Cluster集群扩容时迁移槽位是否会影响业务

 

访问正在迁移的槽位中的某个key:

 

槽位中key的迁移指令的迁移指令是同步阻塞的,所以访问正在迁移的key,请求会被拒绝,这时利用我们基础架构封装的Jedis的客户端来做重试,在重试周期内,如果key迁移完成,就可以正常访问了,这在绝大多数情况下都是正常的。但如果迁移的key是bigkey, 可能迁移时间很久,在Redis客户端重试周期内没有完成迁移,那么此时业务对这个key的访问就是失败的,后面会讲怎样解决bigkey的问题。

 

一个slot下可能有部分key被迁移完成,部分key正在等待迁移,如果被读写的key所属的slot正在被迁移,则Redis Cluster会自动处理:先去源节点找,没找到则重定向到目标节点,这个处理过程是Redis Cluster自带的,详细过程不再赘述。

 

3)如何解决大Key、热Key等原因导致的Redis集群热点问题

 

对于Redis某些数据结构,如集群类型,会导致大key; 某些节点访问频繁,会产生热key。大key或热key都会导致集群中某节点成为热点。

 

如何定位大key热key:

 

  • 大key:通过RDB内存分析工具,可获取top n的大key;

  • 热key:通过Redis客户端向服务端监控投递监控数据。

 

解决方案:

 

  • 定位到导致问题的Key后,通过Key计算出对应的slot,然后扩容个新节点,把除大Key或热Key之外的槽位迁移至新节点中。然后在集群节点扩容缩容做槽位迁移时,排除掉大key热key槽位所在的节点;

  • 大key热key通常是业务使用不当导致,也会线下通知业务进行治理。

 

4)如何做Redis多租户平台故障容灾

 

①Redis节点故障怎样做故障容灾

 

Redis上容器后,单个节点故障:

 

  • 如故障的是从节点,对服务无影响,因为主节点承接所有读写流量,从节点仅作为主节点灾备,从故障后,Redis operator会监听到,并拉起新的从节点,然后加入到Redis cluster集群,再从主节点向从节点同步数据,这时仅在数据同步时对主节点的资源有些消耗,在实际使用中我们发现对主节点资源的消耗对集群基本无大的影响;

     

  • 如故障的是主节点,主节点是承接业务所有的读写流量,确认主节点故障的时间是可配置的,如配置5秒,那么在确认周期内,对业务是有影响的,待确认主节点故障后,从节点会顶替主节点。由于主节点向从节点做数据同步是异步的,所以在主节点故障时,还没来得及向从节点同步的数据,是会丢失的。在从节点顶替主节点后,Redis Operator会拉起新的Pod作为从节点,然后加入Redis cluster集群,从主节点同步数据。

 

②如何做Redis机房故障容灾

 

当前公司有A、B两个机房,假设A机房故障时,公司监控系统会监控发现,然后可通过Redis管理平台下发B机房的Redis集群节点地址给Redis客户端,Redis客户端收到后,会自动重连到机房B,从而做到了机房故障容灾切换。

 

当然原理A机房中Redis中的数据是全部丢失的,这个方案主要用于Redis作为缓存,同时业务可降级的场景。重点核心业务不强依赖于Redis。

 

5)如何保证容器中Redis节点重启后数据不丢

 

Redis目前公司内几乎所有的业务使用都作为缓存数据使用,无需持久化,其高可用通过主从节点数据冗余来保证。

 

对于个别需要持久化的Redis需求,K8S可通过存储持久化数据到文件存储,当容器重启后可从文件存储中重新获取持久化数据,这里我们验证了持久化数据到PVC共享存储,采用的阿里云的NAS文件存储,测试是OK的,待线上实际场景验证。

 

6)多租户共享Key的解决方案

 

多租户共享key,是指两个不同的应用要使用相同的key来共享数据。由于只有相同namespace的中的key的前缀才相同,要两个应用共享key,就需要让这两个应用在同一个namespace中,Redis平台会把这两个应用视为同一个应用。

 

由于namespace是资源配额的最小单位,这两个应用需要共同申请资源配额:即不只key共享,申请的资源配额也要共享。

 

四、Redis多租户平台收益总结

 

1、降低服务器使用成本  资源共享

 

在VIPKID实战中,对比Redis容器云优化前后,服务器使用成本减少了40%。

 

2、提升运维效率 – 从人工运维到自动化运维

 

在Redis集群部署在虚机时代,Redis集群需要人工维护,集群数越多,运维成本越高。当Redis上K8S容器后,一切运维操作都是自动的,这时我们已经不再关注集群数的多少,依赖K8S与Redis管理平台配合,做到了全自动化运维。

 

3、提升系统稳定性  故障容灾自动化

 

借助于Redis多租户平台对节点故障容灾与机房故障容灾的能力,做到了故障容灾的自动化,大大缩短了故障容灾的处理时间。

 

>>>>

Q&A

 
 

Q1:Redis集群,一个服务器和另一个服务器是怎样均衡负载的?监控工具么?

A1:A1:我们Redis集群采用Redis Cluster集群模式,slot的范围是0~16383,通过算法把槽位平均负载到Redis集群的每个节点中。

 

Q2:Redis在K8S环境自动扩容后,slot也是自动迁移吗?

A2:K8S自动扩容后,slot是自动迁移的,但在扩容时,不是由redis operator触发的,而是由Redis管理后台触发,因为扩容时做槽位到节点的负载均衡,是不包含bigkey所在槽位专用的节点的,管理后台才知道哪个节点是bigkey专用的。

 

Q3:如何避免多个用户同时读取Redis中相同的数据?

A3:这位同学是想问,不同租户间数据怎样不会互相读取到吧?这是通过每个应用申请不同的namespace来区分的,例如,应用1和应用2在同一个Redis多租户集群,他们都执行了set aaa bbb指令,但应用1的namespace是 cluster1@app1, 应用2的namespace是 cluster1@app2,那么他们的set aaa bbb指令经过Redis客户端后,变成了"set cluster1@app1:aaa bbb"和“set cluster1@app2:aaa bbb”,通过key的不同前缀来区分。

 

Q4:Pod的IP是固定的吗?

A4:Pod的IP重启后是变化的。具体细节详见问题6答案。

 

Q5: Redis内存大小配置多少?配置rdb吗?

A5:Redis多租户集群的内存分配,跟里面应用的峰值内存有关,例如有两个应用共享Redis集群,一个应用内存峰值是2G,另一个应用内存峰值是3G,那么虚机环境下,集群的内存会预留2倍,即分配10G(10G=(2G+3G)*2);容器环境下,预留1.5倍,即7.5G(7.5G = (2G+3G)* 1.5)。

 

我们公司的Redis场景全部是内存场景,无持久化场景,Redis数据的高可用是通过一主一从冗余实现,其中”主“承接业务的全部读写流量,”从“不承接流量,仅用于”主“故障时做灾备。做RDB仅在故障定位时,dump RDB模型做问题分析定位。

 

Q6:Redis是通过容器IP访问,还是通过K8S访问?

A6:通过容器中Pod的IP访问。当Pod重启后,IP会变化。Redis客户端会缓存集群中所有IP列表,Redis管理后台会定时同步最新的集群IP列表给Redis客户端,假设Pod重启IP变化了,但Redis客户端还没来得及从Redis管理后台同步到最新IP,那么Redis客户端会访问旧的IP,这时它找不到该IP,会访问集群中的其他IP来拉取集群中最新的IP列表,从而访问到变化的IP。

 

Q7:Redis管理平台有演示环境吗?

A7Redis管理平台,主要提供监控、数据展示、自动化运维等能力,有机会可以单独交流。

 

Q8:Redis是共享存储还是本地存储,如果用共享存储,是否遇到过aof刷缓存导致的线程阻塞?

A8:当前我们公司的场景Redis数据全部存在内存中,通过主从数据冗余来保证数据高可用,暂没有持久化场景。

 

Q9:Redis集群如何解决key分布不均的问题呢?

A9:某个key具体落到哪个槽位,是通过负载均衡算法保证每个槽位中的key数量保持均衡,然后确保槽位平均分配到Redis集群中的每个节点。

 

当然每个槽位中key数量基本相同的情况下,每个key的大小不同,对于bigkey的治理方案,请参考我发的PPT及文档;对于槽位落点不均衡的情况,我们在业务低峰时段有巡检,然后通过自定义算法,平均负责槽位到每个Redis节点(大key、热key的槽位除外)。

 

Q10:Redis集群压测工具有推荐么?

A10:都可以,无特别推荐,我们QA选的redis-benchmark。

 

Q11:Key生命周期更新策略的优化?

A11 : 对于Redis无过期时间的key的治理,我们的策略是通过RDB内存分析工具按key的大小从大到小排名,找出top n的key, 再用debug命令逐个查找每个key有多久没有被访问了,然后拿着这个结果找对应的业务聊,逐步进行治理。


↓点这里回看本期直播

阅读原文

最新评论
访客 2024年04月08日

如果字段的最大可能长度超过255字节,那么长度值可能…

访客 2024年03月04日

只能说作者太用心了,优秀

访客 2024年02月23日

感谢详解

访客 2024年02月20日

一般干个7-8年(即30岁左右),能做到年入40w-50w;有…

访客 2023年08月20日

230721

活动预告