京东11.11:数据库运营实践——智能化、自动化、平台化

jopen 8年前

 

从2012年618订单中心使用MySQL,到2013年618大促中MySQL数据库已经支撑起了京东交易系统的半壁江山。目前京东的核心数据库都已基本运行在MySQL上,规模十分庞大,日常的PV已达千亿级别。这些年来,618、双11大促数据库的准备越来越精细,本文以最近4次大促为基点,从智能化、自动化、平台化三个方面来谈一谈京东在MySQL数据库方面的探索和实践。

另,ArchSummit全球架构师峰会北京站将于2015年12月18日~19日在北京国际会议中心召开,大会设置了《 揭秘双十一背后的技术较量 》专题来深入解读双十一背后的技术故事,欢迎关注。

这里不得不提下JMySQL,全称是“京东MySQL数据库智能管理平台”,是开源数据库运营部近4年来自主开发的数据库管理平台,集MySQL 监控系统、MySQL性能智能分析系统、MySQL自动部署系统、MySQL切换系统、MySQL备份恢复系统、MySQL故障智能处理系统、MySQL 日常运维管理系统、MySQL安全系统于一体的管理系统。既然是双11专题,我就顺势举例介绍下其中几项功能在双11中的作用。

MySQL性能智能分析

这是JMySQL智能管理平台的重要功能之一,对于当前MySQL数据库运行性能情况、压力情况、瓶颈、潜在的风险进行分析、汇总,风险点一目了然,让DBA知道立刻需要处理什么样的问题,这个在平时数据库管理中已发挥了重要作用,在大促前更是如此。

本次双11数据库是按照前端流量可能增加20倍进行备战的,对于“抵挡”前端流量的数据库来讲风险非常大,算法上我们为这类数据库确定了压力倍数 A,负责后端处理的数据库压力倍数通常小于A,因为有中间一系列环节处理,它的压力倍数被确定为B,有些系统压力会增加的非常大,DBA从研发处得到可能增加的压力倍数,则这个系统的特定压力倍数为C,在当前性能指标的基础上,可计算出性能是否满足,需要增加多少,哪种方式增加。对于不同类型应用对数据库的压力也不同,如IO型、CPU计算型、网络IO型、混合型等,会对数据库及服务器产生不同程度的影响。一定要避免木桶效应,并考虑峰值,举个简单例子:假设一个数据库别的指标都忽略,IO使用率均值是20%,但峰值达到30%,那这个数据库就不是能再抗4倍压力的,因为有峰值,如果确定压力真的会再增加 4倍,那就要采取解决措施了。如果因为特定原因,不能进行数据库改造,则一定要制定预案,一旦压力上来,抗不住了,确保数据库不被打死。

特别强调下对于核心数据库不只是单纯的先进行指标评估分析,然后扩容改造就行了的,还要尽量进行压测,通过压测进行把关,既:要尊重指标分析,但还要注重实际情况。

现在系统设计时大都会在应用和数据库层之间加Cache层,对于“抵挡”流量的数据库一定要考虑到Cache层被打穿或者关键时刻Cache层异常的情况,DBA这里会按照一个比例预留。基于资源考虑不可能为所有风险点无限制的改造,会按个比例进行,一旦异常情况超出压力范围,马上采用预案,比如该限流的限流、该降级的降级,首先保证主要的核心服务正常,不被打死。这里并不是说只对核心服务这样处理,时间允许、资源允许的话所有重要服务、服务都需要这样做。

性能智能分析及故障自动处理技术都依赖着MySQL监控系统,这个系统会对所有MySQL数据库进行监控。另外,SQL是影响数据库性能的重要因素,系统会对慢查询SQL进行分析,分析后的慢查询自动发给相关研发和DBA进行优化。SQL优化是大促的必要准备工作,当然这个工作是平时需要持续做的。

MySQL自动扩容、部署

在平时,流量上来后数据库的性能出现瓶颈时,要具体问题具体分析,不能盲目的进行扩容、拆分、硬件升级等,先要根据具体的SQL效率、性能,结合数据库本身情况分析判定,也许调整一下索引,SQL语句做一下调整即可解决并发量上来后的性能问题。数据库的扩容、拆分、硬件升级,是需要综合考虑各项性能指标、业务量变化情况来判定,否则造成人力、物力等资源浪费。研发在开发的过程中,涉及到数据库的,特别是重要系统,都会有DBA的参与,通过技术手段在上线前就确保性能情况。功夫要下在平时,不能光靠大促前的准备。

在双11阶段,因为流量突增,会有不少数据库需要提前改造。如主从库全部更换高IO硬件、增加读库、数据库水平拆分、数据库垂直拆分等情况,部分服务双11后还需要缩回到之前规模。这么多年来MySQL数据库扩容、部署系统已经比较成熟,功能也健全了,结合数据库切换系统,改造工作已没技术难度,只是量比较大,不能因为改造影响服务,往往需要在几周内就要改造完成,改造的系统众多,除了增加读库的场景外,其他的改造都会在流量低的时间段进行,DBA和研发紧密配合,自动化技术手段+改造方案。

为了防止机房毁灭性情况出现,增加了专门的机房可提供灾备切换,为几千台的数据库系统完成了跨机房同步库的部署、同步。

MySQL本地、跨机房切换

在大规模部署中,数据库在多个机房都会有从库,再加上多中心双活交易,会有双活的写库,场景会相对复杂。数据库宕机或网络异常后的切换是DBA一项重要工作,在MHA基础上DBA开发了自动切换程序JDSWITCH,在可接受自动切换的数据库上部署,其他的数据库因为业务原因会使用切换平台进行切换。切换平台也是JMySQL的一个重要功能,支持按单台切换、按数据库集群切换、按子系统集群切换、整个机房进行切换。在可连通情况下,切换时会自动挂同步关系,所有数据不需要重做,如连不通则切换后有程序检验数据情况,能补齐的补齐,如无法补齐用自动部署系统重做。一旦大促时机房异常,所有MySQL 集群可在几分钟完成跨机房切换,防止挖土机关键时刻的绝杀。

预案和压测军演

通过对故障的统计、分析,数据库预案越来越多精细,会发生的故障都有相关的处理方案,有相关脚本、程序、平台执行,并会多次演练,经受实践的检验。

压测、军演是大促必不可少的组成部分,会进行多次军演,发现潜在性能隐患进行处理。在稳妥、准备充足的前提下,不要怕军演,现在不去真枪实弹,到了生死瞬间就只能祈祷了。好比模拟了老机房宕机,把核心数据库切到新机房运行跑着,再把这些数据库集群无缝切回去,这次军演完成后信心更加十足了。

各种细节、小事情的处理

细节决定成败,在一个真实的N个机房、大几千台规模的MySQL数据库规模下,真不是以上这些做好大促就高枕无忧了,要重视和处理很多细节,往往这些细节和小事情会在关键时刻绝杀,让人遗憾,有过大促经验的朋友们应该很理解这点。每次大促我都在想,还有哪些细节、“小事情”没考虑清楚,要尽快处理。

总结

618、双11作为期中、期末2次大考,锻炼了技术团队,特别是开源数据库运营部的DBA们,面对各种紧急情况早就成竹在胸了。大促推动了MySQL等开源数据在京东的发展,推动了MySQL运维自动化、自助化的发展。