数据库作为应用系统的最后一道防线，可以说是所有的系统的基石。如何保证在面对618和双11这样的超大流量访问下，数据库依然能做到高性能和高可用，对数据库运维管理团队来说，是一个严峻的挑战。 本次演讲具体内容介绍： 1、京东数据库的技术架构和自动化运维平台； 2、大促前需要做的各种准备工作； 3、大促前解决隐患的思路和方法； 4、大促期间的各种性能保障方法和应急处理； 5、大促之后的经验总结和展望。

以下为演讲实录：

大家下午好，我是来自京东商城的史季强，今天跟大家分享的是高并发大流量下的数据库保障的技术实践。大家都知道对于电商企业而言，每年都有两个重要的节点就是618和双11。这两个节点对公司的整体销售额的贡献具有决定性的作用，在这种压力下我们技术团队如何保障呢？今天就跟大家一起探讨交流一下。

今天分四个章节跟大家交流一下，第一是我们的基础架构以及负载在大促压力下的变化情况；第二是大促之前未雨绸缪，我们如何准备的。第三个是在大促期间严阵以待，如何进行处理和技术保障。第四个是大促之后继往开来，如何总结，如何迎接下一个挑战。

一．架构和负载

先看一下基础的架构，这是我画的简图，京东的应用基础架构在业界也是主流的。首先用户访问过来以后会通过网络CDN加速，CDN加速之后是应用集群，应用集群下面是消息队列，主要用JMQ来支撑消息的任务。从消息集群往下就是缓存的集群，使用的分布式内存数据库是我们自己研发的JIMDB，是分布式的数据库集群，当然也会用原生的Redis产品。最下面的是数据库集群，现在京东线上的数据库95%以上都是MySQL的数据库，还有少量的以Oracle或者SQLServer为代表的商业数据库，主要用于一些内部的系统，此外还有MongoDB代表的NoSQL。大家可以看到这个图，京东的数据库是处于整个应用的基础架构的最底层，不仅承担数据持久化的任务，也是整个软件基础架构的基石。数据库在大促期间是否稳定，决定了这个大促的保障的成败，今天跟大家分享的就是数据库集群这块的保障工作。

接下来说一下京东数据库的基本架构，应用层下面有一个数据库的代理层Jproxy。通过数据库的代理层会对应用做流量管理、链接管理、读写分离等等管理工作。通过代理层往下，业务会路由到生产环节。京东现在采用的还是比较传统的MySQL主从架构，并没有用分布式的架构。因为主从架构经过了很多年的考验，对电商这种交易系统来说，还是更稳定一些。第二就是性能方面还是比分布式的架构更好。通过测试，分布式的集群数据库性能损耗还是非常大的，对延迟要求非常低的系统而言还是不太适用的。第三种，这种主层架构可维护上比较好，少了很多坑。因为分布式的数据库有很多未知的情况，业内也有很多的案例。可以看到京东的生产环节会有一台主库，生产环境的MySQL，会有一个从库。灾备环境有两个从库，灾备环境已经完全私有云化，完全Docker化了。生产环境超过75%以上的数据库MySQL的实例已经部署在Docker上了，所以这个量级非常大。

下面看一个大促真实的数据采集，负载对比的情况。第一张图是网络流量的变化。从大促开始，比如说618从6月1号就陆陆续续有促销开始了。网络流量的变化急剧升高，达到两到三倍，从网络的情况看似乎不是非常大的变化。底下的这张图是从数据库端采集的MySQL的QPS的变化，这个变化就非常大。从平时的高峰点到大促的最顶峰的时刻，看到几乎接近10倍的变化。所以说这个变化的负载量级非常大，对数据库比较熟悉的朋友都了解，数据库承载的流量是一定的。如果是一个很平稳的状态，那数据库可以很稳定、很高效的运行下去。如果突然间有链接风暴过来，可能数据库就很难承受这种压力了。

我在之前维护Oracle数据库的时候就经常会碰到这种问题，本来很正常的数据库，突然遇到链接风暴后，整个数据库可能会有很多的索引冲突或者回滚段冲突，从而导致系统基本上就不可用了，DBA也是手足无措，没什么好办法。但是MySQL相对好一些，因为采用了大量的水平拆分，把负载都分散到很多的服务器上。即便是这种流量有这么大的变化，但是反映到整体来说还是可以承受的。这就是直观的看到在大促期间这种负载的变化。

二．大促之前-未雨绸缪

企业IT规模发展到一定阶段之后都是殊途同归。可能很多地方的理念都比较像，很多内容是相通的。在大促之前需要有这么几个步骤去进行备战。首先就是沟通交流，跟研发去开各种备战会，讨论一些备战方案、应急方案、处理流程，然后就是SQL优化，下面是扩容升级，还有数据结转，所谓数据结转就是数据历史归档，还有压测演练，架构层面的优化。我详细介绍一下。

1、沟通交流

沟通交流有两个最重要的事情，一个就是要确认今年重点保障的项目和系统，明确薄弱环节，然后进行专项的优化改造。像京东现在线上的系统成千上万，从DBA的角度来说，根本无法分清是哪个系统比较重要。这种业务系统的迭代、增加、业务需求太快了，DBA很难跟上节奏。第二个就是协商应急方案和降级方案，我们运维有个理念，无论是多么缜密和细致的准备，一定要按会出问题的角度去做准备。每次都和研发团队沟通应急方案和降级方案，万一真出了问题，一定会有相应的策略去处理。

分享一个案例，某个大促期间某系统不稳定，导致线上交易受到影响。直观表现就是系统的CPU接近100%。前端业务操作超时，数据库访问很慢，几乎无法操作。从表层的DBA介入分析了压力，有大量高并发的慢SQL进行读取导致数据响应慢。从架构来看，这种大量读取业务，应该放到从库上读取，进行读写分离的架构设计。深层次的原因是在于这是他们今年新增加的功能，也没有跟我们DBA进行交流就上线了，而且还是交易环节当中比较重要的。DBA每天的任务也很多，我们虽然看到了这些慢SQL，慢SQL平台也抓取到了这些SQL。但是我们不了解这个系统的重要程度，所以它的优先级就会相应往后排，没有引起足够的重视。研发人员的编码不规范、SQL写得很差，架构设计不合理。这种大量的读写、读的操作，应该放到读库上进行操作的。通过这个案例之后，我们在每次大促之前当会跟研发团队进行多次详细的沟通，确认今年大促期间可能会有哪些新的重要的系统上线，或者老系统是否增加了新的功能。这些重点保障，确认有问题的地方会安排专门的DBA一直跟踪这个系统，直到确认这个系统优化完毕。确认符合了大促期间的性能和容量的需求。

2、关于SQL优化

下面讲解大促之前的SQL优化。SQL优化对DBA来说是重中之重，也是在大促备战期间最重要的一项工作。差的SQL语句对系统性能的影响最为致命。但这种烂SQL对DBA来说却是解决问题最有成效的。优化一个烂SQL，对系统的负载可能就从60%降到20%。能最快的解决系统问题。对于DBA来说这是能主动去处理的一个地方。所以DBA永恒的目标是消灭所有的慢SQL。

京东进行SQL优化，原来的平台就是基于开源的Box anemometer做的。这个平台虽然能很全面利用PT的插件，把慢SQL收集上来。但是这个平台是被动式的。只有研发和DBA主动登陆这个平台，才可以看到相关系统的一些慢SQL等。人都是有惰性的，因此我们又在平台的基础上增加了一个邮件功能。收集上来的慢SQL会在后台程序把它通过邮件发送给所有相关慢SQL所属系统的研发人员。研发人员还要通过这个系统跟踪这个慢SQL优化的情况。我们从年初在做一个新的优化平台，系统运维的架构、规模达到一定程度的时候，就自然而然需要相应的东西去支撑它。

看这个图，功能点会有AWR还有ASH。SQL的AWR和ASH是Oracle数据库优化的两个神器，功能非常强大，对历史数据以及实时数据的收集和分析，这两个功能都是非常有效的。还有一些性能对比，对慢SQL进行优化，优化之后后台也会有一些相应的规则。这种参数优化、负载对象优化、OS优化，也是这种基线，也有这方面的考虑。以及负载，底下有快照的方式。如何去采集数据，会有定时、实时、手动的形式。有些数据要现实抓，还有调度中心，底层的数据存储，我们采用MySQL还有ES的架构去做。MySQL是展现实时的东西。ES是做性能分析的东西，通过ES的集散能力去展示。这个平台会在今年双11左右投到线上使用。这个平台上线之后，很多DBA的优化工作量会大大降低，也会给研发提供一个非常也好的接口。研发是主要使用的对象，让研发更深入到数据库优化的层面。

3、扩容升级工作

关于扩容升级的工作，对DBA来说非常头疼。因为涉及到设备部署、数据迁移，还有数据库的切换，最后还有应用的迁移。大促期间这个工作非常耗时耗力。京东经过多年积累，做了一个自动化平台。这个自动化平台会把扩容设备放到自动化扩容平台的资源池里面。具体的拆分、升级的方案，我们会跟研发之前沟通好。比如要通过垂直拆分去中心化、系统解耦、降低相互之间的影响；还是说通过水平拆分提高系统性能、系统可用性；硬件升级。现在业界都是主流配置的SSD，会优先去使用这种设备。自动化平台重点分析下，京东已经可以一键做到扩容升级。

现在有一个平台会把要扩容的系统，主库的IP输入进去，会自动把现有架构刷出来，底下有相应的选择框。比如说主库现在一主三从，再扩两个从库，底下就选出相应的设备和IP。点击下一步就可以不用管了，会自动同步相关域名、相关IP、监控的数据，同时备份。工单结束，扩容完毕后会跟研发讨论，是否需要迁移？再找合适的机会做切换。所以通过这种平台之后，DBA的人力被大量解放。原来618或者双11之前，每天晚上加班做这些事情。现在通过平台化一键部署，以这次618为例，我们一晚上就可以做上百套系统的扩容。就是说效率提升近百倍，是非常高效的平台。而且之所以这么快，是京东现在大量使用Docker的环境，所以弹性扩容部署非常快。

4、数据结转

聊聊京东的数据结转。数据库是IO密集型的系统，对IO的敏感度非常高。IO的变化表现到数据库上是非常明显的。另外数据都有生命周期，不能永远的存在生产主库里面。有在线、归档、销毁的三个阶段。以这个框架图来分析，在线数据必然是存在生产库里面。在线数据随着时间的推移会有两种结果，一个是从上面直接清理掉。有些是操作log数据，还有一些配送的路由信息，没有价值的，直接会进入清理阶段销毁。另外一种状态，是进入结转状态，进行历史归档。进入归档阶段有近线数据状态、离线数据状态。近线数据依然有使用价值，比如历史订单。看一下自己一年前、两年前的购物信息都是需要保存的。但是进行结转归档之后会放在相对低成本，比较差的存储上面。另外离线数据是完全不使用了。但是每个公司都有自己的法律法规，包括国家有相关的审计要求这种数据不能删除，必须保存起来放在归档库里。随着时间推移，近线历史数据逐渐转变为离线数据，也要保存在归档库里。这些数据随着时间的推移我们会刻录到磁带机上，进行介质化保存。之后从历史库还有归档库中清理掉。整个过程已经做了数据的结转平台，实现完全自动化处理。相当于对研发开放了一个接口，会有一个申请界面。只要输入系统，输入数据库，加上相应结转的条件。比如一年前的数据不要了，加上时间字段，进行时间限制，提交之后整个数据就会自动的进行相应流程的操作完成。申请可以做一次性的结转完成，或者是每天都结转。每天都把符合要求的数据结转归档到历史库、归档库里面。这种历史库、归档库，我们采用的就是MySQL的高压缩比的Tokudb存储引擎。

通过这种模式工作日常也会做，但是大促之前会强化这个事情。就是我刚才说的第一点，数据库是IO密集型的系统，要尽量减少在线的数据。每次应用和其他方面的读取，尽量减少IO的读取，对系统的应用性有极大提高。

5、压测演练过程

做了历史数据归档、SQL优化、扩容改造。怎么验证是否可以达到预期？其实就是通过压测演练来获取数据，优化改造是不是完成了，支撑你的备战是不是达到目的了。切换演练的系统主要是基于业界主流的MHA系统进行内部改造的。通过切换演练主要有四方面的工作：

验证应急预案，确认方案可行性。大促之前京东都会进行多轮的切换演练，走一遍重要的系统，确认设备可用性；

发现潜在问题。比如MHA的Bug、集群架构的问题、域名生效、JDBC缓存、线上复制关系的用户权限等。线上的实例数以万计，有些地方不规范，通过演练才能发现。

验证主从性能，京东的应用系统架构都使用了域名，通过域名去连接数据库。包括JDBC缓存问题，因为域名记录到JDBC客户端的缓存里，生效比较慢，切换后还会往原来的主库上连接，这时候就需要人为介入验证主从的性能。

定制切换策略，当宿主机宕了的话，宿主机会向所有相关的MySQL实例都进行自动的切换，会按机群、按项目、按机房进行定制这种策略。

另外进行压测主要通过两个方面，一个全链路的压测，一个是独立系统的压测。所谓全链路的压测是从下单到最后配送整个黄金链路全面压测，是线上真实进行的。通过数据隔离等等方式，在线上真实模拟。因为互联网公司的系统太多，在线下模拟线上几乎不可能。所以很多压测是在线上进行模拟的。京东今年618之前全链路压测做到了自动化模拟压测，在网络的CDN端部署机器人模拟下单，下单的数据在整个链路下来进行全链路的压测。

独立系统压测，比如某些关键系统也会找DBA配合他们一起做这方面的压测。这个压测包括切换演练和压测过程中能发现很多的问题。举个案例，系统压测期间某个系统的服务异常，数据访问出错，导致线上交易受到影响。表面原因是DBA检查发现主库有大量的高并发写入操作，导致了从库的延迟加大，超过了300秒，影响到了从库读的业务，进而影响到系统的可用性。因为超时太严重，读不到需要的数据导致了线上数据错乱，最终交易受到影响。

深层次的原因是研发对系统架构方面的设计不合理，对一致要求很高的业务，不能放在从库上读取。随着负载增大，还有网络影响，无法保证不延迟。我们在大促之前就介入和研发讨论这个问题的整改方案，应用架构这方面就修改程序里面的超时时间，关闭非核心表的写入，减少IO的压力，并且要做好限流和降级的开关。同时如果通过这种方式仍然延迟，必要的时候需要直接把读的业务切换到主库读取，这个是折中的方案。从数据库层面扩容已经比较快，所以我们紧急调拨了一台高性能的物理机，在搭的数据库下面做一个从库，把它对读一致要求比较高的业务迁移到高性能的服务器上，同时对核心表进行碎片整理，删除低效和无用的索引。

另外从数据库端有一个托底方案，就是修改MySQL的log刷盘模式。相对应的在最高峰的时刻稍微降低数据安全方面的考虑，从而提高IO性能，以减少延迟。我们也做了自动化的程序，等高峰期过了，比如说618晚上或者双11晚上，再改回标准值。这就是京东在大促的时候如果压测演练发现问题如何紧急处理的案例。

6、架构优化

如果做了以上各种的优化和改造之后还发现有一些性能问题，只能从架构层面优化了。我们现在的原则是像这种高并发的频繁读取的数据会放在Redis，或者京东自研的JIMDb里进行缓存。一些大字段放在NoSQL、京东自研的JSF存储系统里，比如线上的图片，要存的图片、视频，就会放到这里面去。

三．大促期间-严阵以待

做完优化工作就进入大促阶段，6月份之后很多工作不能再做了，只做一些特别影响到线上交易的事情。进入保证期核心点就是顺利、平稳。刚才开篇跟大家讨论了对于电商企业每年的节点非常重要，要力保。大促期间第一个要进行24小时值班，24小时公司都有人，有问题随时进行处理。

第二个就是严格控制上线。很多经验发现系统如果运行的很稳定，上线一个新功能或者有一个其他改动，可能会有连锁反应，导致有各种各样的问题。如果一定是业务需求驱动的非常必要的上线，需要部门总监VP级的审批。审批通过之后审核操作是多维度的，从数据库的角度来说要进行数据库的改动。京东会进行双人的审核和操作，并且还要跟研发反复确认。第三个就是集中办公，把相关核心交易链条DBA和研发聚在一起。如果发生故障后通过微信、电话去联系，时效性非常差。面对面可以马上进行处理。包括突发事情的应急处理。

最后说京东的JDBS自动化运营平台，包括前面的优化扩容、迁移、切换。如果通过人工去做工作量非常大，没有那么多的DBA和工作量去支撑。所以必须依赖平台化去做工作。下面讲一下京东自动化运维平台所具备的功能以及如何辅助进行大促的。

资源管理，因为京东的环境比较复杂，大量虚拟化的Docker环境、物理机，京东的数据库团队必须对这些资产有详细的记录。所以容器、Docker，还有实例、库，以及集群、服务器的上下线的管理，整个涉及到的资产都会有详细的管理。依赖于详细的资产管理之上还有业务信息、服务器信息。

自动化运维，像MySQL集群的自动搭建，完全不用人为部署数据库实例，都是用平台化处理。还有MHA自动切换，DNS自动写换，包括自动备份恢复系统。线上上万台MySQL的实例，备份恢复都是自动化处理的。尤其是恢复的地方已经做到恢复不需要人为参与，每天都通过平台对线上的备份进行恢复的检测。这非常有用，因为从去年到今年已经发生了很多数据库被删除或者数据库发现问题，结果发现备份不可用，我们每天的验证备份解决了这个问题。

自助化上线，京东DBA已经不用去参与研发上线的需求了，研发只要把SQL语句写进去，DBA做一个审核，90%以上的操作都可以自动化处理，解放了大量的DBA资源以投入到业务里。跟研发讨论业务需求，做自动化的工具和平台。

全方位监控，对容器和服务器做统一的监控。在数据库端京东还有自己定制的数据库监控平台，也在整体的自动化运维平台里，包括有研发提供查询的功能，应用集群的架构、连接数等等。这是前三天我们在大促期间做的工作。

四．大促之后-继往开来

大促之后就要总结经验，总结每次大促期间的得与失，这个很重要。犯错误的地方下次绝对不能再犯。大促前后两个月或三个月就完了，剩下的时间大量的DBA是集中在运维的可视化、自动化、平台化的上面开发的。包括现在比较热的SRE的概念。京东在实践这些东西。在非大促期间所有DBA除了一些日常工作之外需要参加到软件工程的项目里。软件工程项目就是我说的这些可视化、自动化、智能化，这些平台的开发。所以说现在的运维没有纯粹的运维，不是只管数据库，基本上DBA、运维都要向开发的方向转变，因为现在需求的是复合型的人才。

这就是今天跟大家分享的京东在大促期间，高并发大流量的情况下如何进行数据库的经验，欢迎大家交流，谢谢大家。