饿了么Redis Cluster集群化演进

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平台池化准备。

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

上图表示在高峰期时每天不同订单量下，整个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

图中为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

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

Corvus 逻辑架构

可以看到，底层存储用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 物理部署

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团队干预开发。