转载

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

从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运维自动化、自助化的发展。

感谢郭蕾对本文的审校。

给InfoQ中文站投稿或者参与内容翻译工作，请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博（@InfoQ，@丁晓昀），微信（微信号： InfoQChina ）关注我们，并与我们的编辑和其他读者朋友交流（欢迎加入InfoQ读者交流群京东11.11：数据库运营实践——智能化、自动化、平台化）。