可同时支撑5~10个618大促的数据库做了哪些性能优化？

“如果你有机会走进京东 618 作战指挥中心，看到数字不停变换的监控大屏和各个版块集中应战的京东技术人，你会惊讶地发现，从技术角度而言，我们度过的是一个近乎完美的，一切尽在掌握的 618，订单洪峰在经过千锤百炼的技术系统前被有条不紊地化解。”—— 京东集团 CTO 张晨《技术创造价值的几个层面》

为了有条不紊的化解订单洪峰，每年京东 618 大促之前，都会对系统进行一些优化和测试，以保证订单系统、库存系统、结算系统等正常运转。数据库系统作为重要的基础设备，就好比人的大脑记忆系统，没有了数据库就没有了记忆系统，而一旦数据库性能出现问题，整个网站就不能正常使用了，所以数据库优化是一件持久的事情。

在 APMCon 2017 大会数据库性能调优专题里，我们邀请到了京东商城资深架构师，兼数据库团队负责人 史季强老师，介绍基于 618 大促活动，京东在数据库方面所做的优化实践。在此之前，我们有幸问了一些相关的技术话题，以飨读者。

在 618 之前，京东数据库团队会在尤其是自动化切换、监控智能分析、故障自动处理方面做一些预案，史季强说，准备部分会分以下几个步骤进行：

1. 首先会和研发同学进行交流，确认今年重点保障的项目和系统，明确薄弱环节，然后进行重点的优化改造；

2. 其次会对数据库应急预案进行梳理，查缺补漏；

3. 最后会配合研发进行大量的切换演练，来验证系统的高可用，并将演练过程中发现的问题及时整改。

目前京东数据库团队自主研发的 JDBS 自动化运维平台，可以进行数据库自动切换，监控分析，部分故障的自动处理。

为了应对高流量、高访问的促销活动，京东数据库架构设计上主要还是遵循了业内普遍使用的几个原则：

1. 通过垂直拆分的模式去中心化，系统解耦，减少相互之间的影响；

2. 通过水平拆分的模式提高系统的可用性；

3. 通过读写分离的模式分散系统的压力；

4. 通过 Redis 缓存数据来减轻数据库压力。

史季强介绍说，当前的数据库是基于 MySQL 主从复制的架构，主机房一主一从，备机房两个从库，主库出故障优先切到本地从库，机房级别的故障切换到备机房，基本上不会对业务产生什么影响。

那么，针对数据库资源、架构、高可用等进行优化、改造方面做了哪些创新性项目，史季强说到，京东数据库团队从 15 年就开始进行数据库 Docker 化的尝试，经过几年的实践，当前 70% 以上的数据库实例，都运行在 Docker 上面。

大规模部署 Docker 后，服务器资源利用率大幅提高，一台高性能的宿主机上面，可以同时支撑至少 5 个系统的数据库。 数据库部署的时间，也从原来的小时级别，缩短到了现在的分钟级别。

记得之前有人问过一个很模糊的问题，经过这几年的研发和实战历练，现在的京东数据库系统，同一时间能承担多少个 618 大促活动？ 史季强说，为了保证应用系统面对短时间内高并发大流量的冲击，设计时要估算好足够的容量和性能，团队一般都是按照上年度 618 或者双 11 业务量的 5~10 倍来准备，所以理论情况下，同一时间承担 5~10 个 618 活动是没有问题的。

最后介绍一下，史季强老师会在 8 月份的 APMCon 上做分享，主要会介绍京东数据库团队为了应对 618 这样的大促活动，在数据库保障方面所做的一些工作，在建设数据库团队中遇到的坑和解决办法，很多内容都是根据实际案例所总结的宝贵经验，希望能对参会者有帮助。