饿了么Redis Cluster集群化演进

  1. 云栖社区>
  2. 博客>
  3. 正文

饿了么Redis Cluster集群化演进

【云行】 2017-04-24 19:43:06 浏览8091
展开阅读全文

2017运维/DevOps在线技术峰会上,饿了么运维负责人程炎岭带来题为“饿了么Redis Cluster集群化演进”的演讲。本文主要从数据和背景开始谈起,并对redis的治理进行分析,接着分享了redis cluster的优缺点,重点分析了corvus,包括commands、逻辑架构和物理部署等,最后分享了redis的运维和开发,并作了简要总结,一起来瞧瞧吧。

 

以下是精彩内容整理:

近几个月,运维事件频发。从“炉石数据被删”到“MongoDB遭黑客勒索”,从“Gitlab数据库被误删”到某家公司漏洞被组合攻击。这些事件,无一不在呐喊——做好运维工作的重要性。然而,从传统IT部署到云,人肉运维已经是过去式,云上运维该怎么开展?尤其是云2.0时代,运维已经向全局化、流程化和精细化模式转变。与此同时,人工智能的发展,“威胁论”也随之袭来——运维是不是快要无用武之地了?如何去做更智能的活,当下很多运维人在不断思考和探寻答案。

Redis Cluster在业内有唯品会、优酷蓝鲸等很多公司都已经在线上有了一定规模的Redis Cluster集群,那么,饿了么是怎样从现有的Redis技术迁移到Redis Cluster集群上的呢?

 

背景和数据

2015-2016年是饿了么的业务爆炸式增长阶段,订单量从几十w到到峰值900w/天,在增长的过程中我们也遇到了一些问题,我们有服务化治理诉求、应用性能和稳定诉求、人肉运维成本诉求,并且还要为未来的PAAS平台池化准备。

6d83e3eca689127d68ba7847ca24244fdc2e174a

横坐标是订单量,纵坐标是集群数量,在多机房下整个集群规模是double的,可以看到,千万订单的集群规模大概在200个,在一个机房内我们有近200套集群,近4T数据在Redis里面,整个节点数大约在10000个左右。

49b30753f514b4d7a6eaddb65486ab54b46cf730

上图表示在高峰期时每天不同订单量下,整个Redis集群承载OPS的需求。

使用场景

外卖行业的使用场景要结合业务来看,所有需要高性能、高并发、降级数据库场景下都用到了Redis做缓存,包括用户端、商户端和物流配送,搜索排序、热卖、画像等目前也是往Redis里推送,除了缓存外,还有各类cache、计数器、分布式锁等。

为什么会考虑向Redis Cluster演进呢?

因为Redis存在很多问题,比如单点的内存上限受限制,将Redis当成DB或cache混用,共用一个redis、大key阻塞整个实例,经常需要扩容、扩容很痛苦,使用复杂且基础环境非标、存在各种配置,监控缺失以及不能统一配置等诸多问题。

 

治理

由于Redis请求量太大,打满了机器网卡,所以在2016年5月启动了治理redis的项目。

在自研选型部分,在OPS推广治理时我们与业内成熟技术做了比较,包括Redis vs redis Cluster,以及Twenproxy vs Codis vs Redis Cluster,比较了单节点的redis和redis Cluster,还有业内经过生产考验的proxy,最后决定自研自己的Redis Cluster + proxy。

 

Redis Cluster 的优缺点

为什么选择redis cluster作为我们的底层存储呢?

Redis cluster自带迁移功能,性能快、高可用,支持在线分片,丰富集群管理命令等。自研proxy在初期快速在生产上应用时候可以省略掉这部分,让redis  cluster本身给我们提供这项功能就足够了。

Redis cluster也有一些不足:

  • Client 实现复杂,需要缓存slot mapping关系并及时更新;
  • Client不成熟导致提高开发难度;
  • 存储和分布式逻辑耦合,节点太多时节点之间的检测占大量网卡带宽;
  • 3.0.6版本前,只能单个key迁移,并且同时只允许一个slot处于迁移状态。

 

Corvus

19fe78b5ada802b5e8f694d666d0d5f7246d4c76

图中为corvus时序设计,可以看到,actor到后面的redis,中间的proxy、client和server是在corvus中实现的逻辑,proxy处理connect操作,接收用户的请求发送到client,server最终实现命令的处理。我们分成三个分类,对于单key、特殊命令和多key的处理,对复合命令操作做了单独操作,并对返回结果做聚合,同时还有一些特殊命令,比如cluster命令的处理逻辑。

corvus封装了redis cluster 协议,提供redis 协议,这样用原来成熟的redis client操作redis cluster集群,接入到corvus,这时可以做到无缝的改动;扩容缩容应用无感知,corvus服务是注册的机制,对应用程序来说,连接是通过一层本地proxy,我们对应用程序提供SDK,但目前我们通过本地proxy连接接入corvus已经能够满足大部分应用;corvus实时缓存了slots mapping,它会不停的发送corvus notes去获取redis node与slots mapping的关系,并更新到corvus本身的缓存中,还有Multiple Thread、Lightweight和Reuseport support等。

Corvus commands

  • Corvus支持Pipeline;
  • Modified commands,对复合命令做spring操作,我们已经对命令本身进行了修改,但可能对我们看监控数据有疑惑,统计端节点命中率与应用程序命中率可能不一样;
  • Restricted commands;
  • Unsupported commands,比如对GU的处理,目前还没有在redis cluster中使用GU的应用,暂时不会支持。

Corvus performance

df977790235ef689a1ccea073bcda3bdb5de5f8d

图中为corvus的测试报告,这是很极端的压测情况,set/get可以达到140万QPS数据。

Corvus 逻辑架构

8ab3baaf60ebce4f4f8131dec64a1fff1b7ad81b

可以看到,底层存储用redis cluster,web console通过后端ruskit操作redis cluster,当我们注册redis cluster时,APPid存储在storage里,监控部分我们通过Esm agent发送到Grafana,corvus本身也会采集server log发送到Statsd去收集,corvus agent去部署时首先要初始化corvus agent注册到host console里,通过corvus agent去拉起或回收某一套redis cluster,Huskar是我们的集中配置管理,对应到我们后端的zk技术。

Corvus 物理部署

03fef9c3f4d80e11656297771814a970caf3fa3f

Corvus的物理部署如图所示,上面是应用程序端,应用程序连接到本地的corvus服务端口,corvus服务端口作为本地的sam port,一个corvus实例对应到redis cluster的一些master节点,会部署在不同的物理服务器上,根据不同的和数去创建corvus服务实例以及redis节点。

这里有两层proxy,首先连接本地的sam,也就是go proxy,go proxy这层提供应用服务化、本地接入,corvus是redis cluster proxy这一层,两层proxy意味着两层的性能损耗,在这个基础上,我们也做了针对redis cluster相同的直连的性能损失,对比来看,proxy层性能损耗相比运维成本以及服务化成本而言,是可以接受的。

 

Redis 运维和开发

Redis运维

  • 我们将redis移交数据库团队运维
  • 统一redis 物理部署架构
  • 标准化redis/corvus 服务器以及单机容量
  • 设定redis 开发设计规范
  • 设定redis资源申请流程,做好容量评估
  • 完善监控,监控分corvus和redis cluster两部分,跟进全链路压测,从最前端打进来,到底层的redis和数据库
  • 根据压测结果做隔离关键集群,比如整个外卖后端和商户的redis,将它们做单独隔离,redis cluster本身对网卡要求很高,分专用资源和公共资源,专用资源的corvus或redis cluster机器独栈给到APPid,公共资源是混布情况,我们只需监控网卡流量、cpu等
  • 升级万兆网卡,新采购的服务器都是万兆配置

Redis 开发约定

Redis开发约定如下:

  • Key 格式约定:object-type:id:field。用":"分隔域,用"."作为单词间的连接,对于整个field怎样分隔,我们有很多种改法;
  • 禁止大k-v,我们基于全链路压测,比如一套集群有多种类型的pattern的key,其中某一个的key value很长,占用内存很大,我们就要告诉开发者像这种使用姿势是不对的,须被禁止;
  • 只用作cache, Key TTL设置;
  • 做好容量评估,由于redis cluster的迁移限制,所以前期我们要做好容量评估,比如整套集群申请100G,我们需要计算需要的内存容量以及所在的应用场景负载;
  • 设定集群上限,规定redis cluster集群数不超过200,单个节点容量4~8G;
  • 接入统一为本地goproxy

Redis 改造

我们要定义一个节奏,对redis进行改造,具体如下:

1.         将Redis 迁移cluster

2.         完善system、redis、corvus监控

3.         对线上redis拆分、扩容

4.         非标机器腾挪下线

5.         大key、热节点、大节点扫描,比如同一个redis cluster集群某个节点明显高于其它节点,我们会做节点分析和key的分析等

6.         网卡Bond,多队列绑定

7.         修改jedis源码,加入matrix埋点上报etrace,就可以在etrace看到每个应用trace到整条链路到哪一个端口,它的响应时间、请求频次、命中率等。

 

经验总结

对于redis我们可谓经验丰富,总结如下:

  • Redis 更适合cache,cluster下更不合适做持久化存储
  • 一致性保证,不做读写分离(尽管corvus支持)
  • 单实例不宜过大,节点槽位要均衡
  • 发现问题,复盘,积累经验
  • 不跨机房部署,性能优先
  • 异地多活通过订阅消息更新缓存
  • 大部分的故障都是由于hot-key/big-key
  • 关心流量,必要时立刻升级万兆

遗留问题

目前redis还不够自动化,某些操作还是分成多个步骤来实现,大集群Reshard扩容慢;遇到版本升级问题时,可以新起一条集群;Sam->corvus->redis链路分析,应用程序在etrace上访问端口会很慢,需要从redis和corvus层层自证等;多活跨机房写缓存同步;我们通过定时任务的发起AOF/RDB来保证数据尽快恢复,实际上我们是关闭掉的;冷数据也是不够完善的,还有集群自愈,当遇到问题时我们可以快速拉起另外一套集群将数据更新过去,或者通过数据更新预热将缓存更新过去。

池化

我们在根据全链路压测时的一些特性或数据去做集群隔离,分放公共池和专用池,以及对整个池内资源做buffer的监控;资源申请只需关注容量以及使用方式,无需关心机器;另外,新申请以及扩容缩容按组(group)操作,运维操作自动化,不需要登录到某个机器上执行某个命令。

开发自助

我们最终的目标是在缓存部分实现开发自助,具体步骤如下:

1.         开发自助申请redis 资源

2.         填入demo key/value,自动计算容量

3.         状态,告警推送,对线上实时运行情况的透明化

4.         各类文档齐全

目前我们还做不到,需要OPS团队干预开发。

 

 

网友评论

登录后评论
0/500
评论
【云行】
+ 关注