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

从 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 集群可在几分钟完成跨机房切换，防止挖土机关键时刻的绝杀。