e-works数字化企业网  »  文章频道  »  基础信息化  »  企业上云

大规模 codis 集群的治理与实践

2017/12/2    来源:腾讯云    作者:佚名      
关键字:codis  codis集群  
在2015年末,为了解决各类业务大量的排行榜的需求,我们基于redis实现了一个通用的排行榜服务,良好解决了各类业务的痛点,但是随着业务发展到2016年中,其中一个业务就申请了数百万排行榜,并随着增长趋势,破千万指日可待,同时各业务也希望能直接使用redis丰富数据结构来解决更多问题(如存储关关系链、地理位置等)。
    一、背景和概况
 
    在2015年末,为了解决各类业务大量的排行榜的需求,我们基于redis实现了一个通用的排行榜服务,良好解决了各类业务的痛点,但是随着业务发展到2016年中,其中一个业务就申请了数百万排行榜,并随着增长趋势,破千万指日可待,同时各业务也希望能直接使用redis丰富数据结构来解决更多问题(如存储关关系链、地理位置等)。
 
    当时面临的问题与挑战如下:
 
  • 排行榜服务无法支撑千万级排行榜数(排行榜到redis实例映射关系存储在zookeeper,zookeeper容量瓶颈)
 
  • 单机容量无法满足关系链等业务需求
 
  • 排行榜和关系链大部分大于1M,同时存在超大key(>512M),需支持超大key迁移
 
  • SNG的Grocery存储组件,支持redis协议,但又存在单key value大小1M的限制
 
  • 高可用,需要支持redis主备自动切换
 
  • SNG数据运维组未提供redis集群版接入服务,在零运维的支持下如何高效治理众多业务集群?
 
    面对以上挑战,经过多维度的方案选型对比,最终选择了基于codis(3.x版本),结合内部需求和运营环境进行了定制化改造,截止到目前,初步实现了一个支持单机/分布式存储、平滑扩缩容、超大key迁移、高可用、业务自动化接入调度部署、多维度监控、配置管理、容量管理、运营统计的redis服务平台,在CMEM、Grocery不能满足业务需求的场景下,接入了SNG增值产品部等五大部门近30+业务集群(图一),350+实例, 2T+容量。
 
    下文将从方案选型、整体架构、自动化接入、数据迁移、高可用、运营实践等方面详细介绍我们在生产环境中的实践情况。
 
部分接入业务列表
图一 部分接入业务列表
 
    二、方案选型
 
    Redis因其丰富的数据结构、易用性越来越受到广大开发者欢迎,根据DB-Engines的最新统计,已经是稳居数据库产品的top10(见图一)。云计算服务产商AWS、AZURE、阿里云、腾讯云都提供了Redis产品,各云计算产商主流方案都是基于开源Redis内核做定制化优化,解决Redis不足之处,在提升Redis稳定性、性能的同时最大程度兼容开源Redis。单机主备版各厂商差异不大,都是基于原生Redis内核,但是集群版,AWS使用的原生的Redis自带的Cluster Mode模式(加强版),,阿里云基于Proxy、原生Redis内核实现,路由等元存储数据保存在RDS,架构类似Codis, 腾讯云集群版是基于内部Grocery。了解完云计算产商解决方案,再看业界开源、公司内部,上文提到我们面临问题之一就是单机容量瓶颈,因此需要一款集群版产品,目前业界开源的主流的Redis集群解决方案有Codis,Redis Cluster,Twemproxy,公司内部的有SNG Grocery、IEG的TRedis,从以下几个维度进行对比,详细结果如表一所示(2016年10月时数据):
 
数据库流行度排名
图二 数据库流行度排名
 
Redis集群产品对比
    表一 Redis集群产品对比
 
    云计算产商和业界开源、公司内部的解决方案从整体架构分类,分别是基于Proxy中心节点和无中心节点,在这点上我们更偏爱基于Proxy中心节点架构设计,运维成本更低、更加可控,从存储引擎分类,分别是基于原生Redis内核和第三方存储引擎(如Grocery的多阶HASH+LinkTable、TRedis的Rocksdb),在这点上我们更偏爱基于原生Redis内核,因为我们要解决业务场景就是Grocery和CMem无法满足的地方,我们业务大部分使用的数据结构是ZSET且Key一般超过1M,几十万级元素的ZSET Key是常态,Grocery的Value 1M大小限制无法满足我们的需求,同时我们需要ZSET的ZRank的时间复杂度是O(LogN),基于RocksDb的存储引擎时间复杂度是O(N),因此这也是无法接受的。随着业务发展,容量势必会发生变化,因此扩缩容是常态,而TwemProxy并不支持平滑扩缩容,因此也无法满足要求。最后,我们需要结合内部运营环境和需求做定制化改造,在零运维的支持下,通过技术手段,最大程度自动化治理、运营众多多业务集群,而Codis代码结构清晰,开发语言又是现在比较流行的Go,无论是运行性能、还是开发效率都较高效,因此我们最终选择了Codis.
 
    三、整体架构
 
    基于Codis定制开发而成的Redis服务平台整体架构如图二所示,其包含以下组件:
 
  • Proxy:实现了Redis协议,除少数命令不支持外,对外表现和原生Redis一样。解析请求时,计算key对应的哈希槽,将请求分发到对应的Redis,业务通过L5/CMLB进行寻址。
 
  • Redis: Redis在内存中实现了string/list/hash/set/zset等数据结构,对外提供数据读写服务、持久化等,默认一主一备部署。
 
  • Dashboard:提供管理集群的API和访问元数据存储的通用API(CURD操作,屏蔽后端元数据存储差异)。
 
  • Zk/Etcd/Mysql:第三方元数据存储,保存集群的proxy、redis、各哈希槽对应的redis 地址等信息。
 
  • HA:基于Redis Sentinel实现Redis主备高可用,部署在多个IDC,采用Quorum机制、状态机进行主备自动切换。
 
  • Scheduler:调度服务,负责对业务接入申请单进行自动调度部署、集群自动化扩容、各集群运营数据统计等。
 
  • 运维管理系统: Web可视化管理集群,提供业务接入、集群管理、容量管理、配置管理等功能。
   
  • CDB:存储业务申请单、各节点容量等信息。
 
  • Agent:负责定时监控和采集Redis、Proxy、Dashboard运行统计信息,上报到米格监控系统和CDB。
 
  • HDFS:冷备集群,Redis冷备文件每天会定时上传到HDFS,提供给业务下载和在主备皆故障的情况下做数据恢复使用。
 
整体架构
    图三 整体架构
 
    四、自动化接入
 
    当面对成百上千乃至上万个Redis实例时,人工根据业务申请单去过滤无效节点、筛选符合业务要求的节点、再从候选节点中找出最优节点等执行一些列繁琐枯燥流程,这不仅会导致工作乏味、效率低,而且更会大大提升系统的不稳定性,引发运营事故。当繁琐、复杂的流程变成自动化后,工作就会变得充满乐趣,图三是业务接入调度流程,用户在运维管理系统提单接入后,调度器会定时从CDB中读取待调度的业务申请单,首先是筛选过滤流程,此流程包含一系列模块,在设计上是可以动态扩展,目前实现的筛选模块如下:
 
    Health: 健康探测模块,过滤宕机、裁测下线的节点IP
 
    Lable:标签模块,根据业务申请单匹配部署环境(测试、现网)、部署城市、业务模块、Redis存储类型(单机版、分布式存储版)
 
    Instance: 检查当前节点上是否有空余的Redis实例(筛选Redis实例时)
 
    Capacity: 检查当前节点CPU、Memory是否超过安全阀值
 
    Role:检查当前节点角色是否满足要求(如Redis实例所属节点机器必须是Redis Node),角色分为三类Proxy Node,Redis Node,Dashboard Node
 
    以上筛选模块,适用Proxy、Redis、Dashboard节点的筛选,在完成以上筛选模块后,返回的是符合要求的候选节点,对候选节点我们又需要对其评分,从中评出最优节点,目前实现的评分模块有最小内存调度、最大内存调度、最小CPU调度、随机调度等。
 
业务接入调度流程
    图四 业务接入调度流程
 
    通过运行以上一系列筛选和评分模块后,就可以准确、快速的获取到新集群的Dashboard、Proxy、Redis的部署节点地址,但是离自动化交付给业务使用还差一个重要环节(部署)。目前主要是通过以下三个方面来解决自动化部署,其一,Codis本身是基于配置文件部署的,每新增一个业务集群必须在配置文件指定集群名字,新建一个PKG包,维护成本非常高,我们通过监听指定网卡+核心配置项迁移到ZooKeeper,实现配置管理API化,同时部署包标准统一化。其二,在各节点上都会部署Agent,Agent会定时采集上报各节点信息入库到容量表,无需人工干预,容量管理自动化,未使用的实例形成一个小型资源buffer池。其三,部署是个多阶段的流程,需要分解成各状态,并保证每个状态都是可重入、幂等性的,当所有状态完成后,则调度结束,某状态失败时,下次调度检查到申请单非完成状态,会自动重试失败的流程,直至完成,拆分后的部署状态流程图如图四所示。
 

责任编辑:李欢
本文为授权转载文章,任何人未经原授权方同意,不得复制、转载、摘编等任何方式进行使用,e-works不承担由此而产生的任何法律责任! 如有异议请及时告之,以便进行及时处理。联系方式:editor@e-works.net.cn tel:027-87592219/20/21。
兴趣阅读
相关资料
e-works
官方微信
掌上
信息化
编辑推荐
新闻推荐
博客推荐
视频推荐