赶考状元：如何快速应对数据库QPS暴涨20倍？我们做了三次决策

受疫情影响，全国各学校的开学均被延期。为避免耽误学生的课业，教育部推出了“停课不停学”政策，鼓励师生积极开展线上教学模式。

赶考状元（上海亿山睦教育科技有限公司）为此积极响应政府号召，向湖北全省一年级到高三的学子免费开放教材的同步在线教学课程，后来进一步扩大至全国范围。这一公益活动获得了很大反响，网站用户注册量和浏览量超过平时数倍。

虽然活动从策划到上线总共只有4天时间，赶考网技术团队通过科学决策，及时精密的实施，完成了业务代码改造、架构评估、扩容升级、SQL优化等工作，期间也和UCloud UDB团队紧密合作，在其协助下实现了数据库的架构改造和扩容，很好地承接了QPS暴涨20倍的访问压力，圆满完成技术保障任务。

下面分享一些我们在此过程中的细节和思考，供有快速扩容需要的企业参考。

面临的业务痛点

公司自2005年成立一直专注于K12在线教育，此次疫情公益活动构想阶段，业务侧运用此前超过十年的互联网及线下教育经验，快速设计了有效可行的方案，在不少细节上下了功夫，例如加速审核通道，只需两步即可学习的易用性，面向家长推广的二维码等。

技术团队的任务则是提前预判后台流量的迅猛增长，未雨绸缪设计行之有效的预案，查漏补缺，切实保障活动顺利流畅运行。为此我们细致梳理了现有架构的薄弱点，并相应制定了精准有效的扩容方案。

由于我们原先的扩容是稳定慢节奏的，这次预见到了大量访问需求，首要工作是分析现有架构的能力和不足。

此前业务的主应用架构为ULB负载+双UHost单体架构+分布式缓存+单实例高可用UDB，用了大量UCloud的云组件。我们全面梳理了架构各层模块，对每一层的能力做了评估。ULB有扛大流量的能力，主要关注后端。UHost上是应用服务，我们测算了一个部署于8核16GB UHost上的主站模块能够扛住多大并发请求、应用模块垂直扩容和平行扩容两个方案的优劣对比，最终决定水平扩展。考虑到外围的单体服务接口受主应用流量的带动，也进行了扩容承压的调整。缓存的做法是加大分布式缓存、优化访问缓存。压力最大的是数据库，可能带来性能上的严重瓶颈。

不管是MySQL、PostgreSQL还是MongoDB，我们都采用了UCloud 的 UDB 托管服务，其中包括核心数据库。相比自建数据库，UDB提供的高健壮高可用以及免维护的服务，可以让我们更安心专注于上层业务逻辑的构建上。且在数据的安全问题上，UDB提供了完善的备份和恢复机制，避免数据意外丢失。

快速扩容的三次决策

1、在线垂直升级

最初我们的业务核心数据库选用了高可用UDB部署。在业务平稳期，从性价比角度考虑，最开始UDB实例配置不高，预估QPS最大负载在3000以内。业务爆发前夜，首先对UDB实例做了垂直升级，大幅度提升了数据库的内存和磁盘配置。这个操作很快，几乎不影响业务访问（只在磁盘升级时有秒级访问中断），实例的处理性能迅速得到提升。

2、高性能读写分离

但高速增长的业务，给数据库带来的压力预计很快便超过单个UDB实例所能承受的极限，因此数据库从单机升级为集群势在必行。

我们设计方案时，获得了UDB团队的协助。分析业务的SQL请求后，发现读写比例在50 : 1左右，属于典型的读多写少业务，于是向我们推荐了一主多从 + 读写分离Proxy 的数据库集群架构。

在该架构下，主（高可用UDB）和从（单节点UDB）之间通过异步复制保持数据同步，业务数据库IP改指向读写分离Proxy的IP，由读写分离Proxy识别业务SQL的读写类型，将写SQL、事务读SQL转发到主，普通读SQL按比例转发到从，转发比例控制台可自由配置。同时，读写分离Proxy几乎100%兼容MySQL语法和协议，业务无需改造即可顺畅接入。

通过该架构，似乎可完美解决读多写少业务对数据库的大流量压力问题，但实际上仍有一些至关重要的技术细节需要把握。

其中之一就是读写分离中间件的转发性能问题。从理论上看，可以通过横向添加从节点的办法线性提升数据库集群的读性能，但如果底层从节点数量加上去了，读写分离中间件又是否会成为新的瓶颈？

我们十分重视这个问题，为此首先做了一系列的数据指标估算，包括现有UDB实例的性能上限、UDB在垂直升级后根据现有访问模型估算性能上限、UDB升级为读写分离主从集群后对读写请求的处理性能和从节点数量的关系等。

第二步则是和UDB团队配合做了读写分离Proxy的压测。

上述压测实验采用Sysbench程序，在两台物理机上模拟了底层UDB节点从1主线性增长到1主6从的情况下，整个读写分离集群的读处理性能。从结果可以看出，得益于读写分离Proxy对多核CPU的充分利用，以及代码层面的多个性能调优，读写分离Proxy具备可靠的转发性能，不构成集群的性能瓶颈。从而保证集群的读性能，能够随着从节点的线性增长，呈现几乎完美的线性增长。

实测数据令人放心，UDB团队继而帮助制定了整套UDB扩容计划，我们的业务代码也相应做了调整，整个方案可以在网站用户几乎零感知的情况下实施。此后，我们后端服务的扩容有条不紊地开始，每天凌晨在业务低谷时执行扩容，先扩容主站应用集群，将数据库升级到读写分离集群，然后逐层向外扩容外围单体服务，整个扩容工作设计合理，快马加鞭实施到位。

运营情况

公益项目开始后，2月1号到2月10号短短10天内，赶考状元平均日注册用户量由0.83万上升到3万，最大单日注册用户达5.8万。平稳承压了单日20万用户的web/App访问，顺利地为全国各地区超过100万学生免费赠送了在线微课学习、题库练习、作业组等线上服务，为停课不停学“添砖加瓦”，贡献了优质的公益教育资源。

在此期间，我们业务数据库的吞吐量（QPS）暴涨了近20倍，目前线上读写分离Proxy单实例最高QPS已达到20万以上，升级到读写分离集群后，通过1主6从加2节点双活读写分离Proxy的集群配置，平稳扛住了业务流量的高速增长。我们的技术架构，也成长为一个具有相当规模的中型互联网服务。

3、高可用新架构：扩充连接数

在渡过2月10号这个线上开学高峰后，业务依然在高速发展，虽然主从读写分离集群在应对业务高QPS访问上不成问题，但随着业务模块的增多，在2月12号上午高峰期业务向数据库发起的连接数，已经达到高可用版UDB产品6000的上限。

为了从根本上解决这个问题，UDB研发团队建议，将高可用UDB的后台架构，从传统的VIP+代理+DB 的架构升级为其最新开发的漂移 VIP+DB 双主新架构。为此他们连夜制定了透明升级的方案，能够不迁数据在2分钟内从旧架构原地升级为新架构，获得我们认可并在凌晨实施，确保第二天业务的正常运行。

新的高可用UDB架构，利用稳定的UCloud虚拟网络VIP管理服务，将架构简化为更朴素的漂移 VIP+DB 双主的实现，在数据链路上减少一次转发，消除一个潜在性能瓶颈，并且简化控制模块，减少不可控因素。同时新架构对数据库（MySQL 和 PG）原生的兼容度更高。

慢查询优化

提前规划和快速扩容，给了我们更多的余裕，能去快速应对和解决大流量突发时暴露的其它隐藏问题，最典型的例子是数据库慢查询。

我们后台代码采用了ORM框架连接MySQL，由于ORM层屏蔽了底层MySQL库表的细节，小部分访问MySQL的代码没有考虑到底层MySQL的执行逻辑，存在慢查询过多的问题。慢查询的问题，在平时小流量慢增长的情况下影响并不明显，但是疫情期间大流量压力下就变得不容忽视。

UCloud DBA团队期间提供了诸多帮助，他们在慢查询问题的定位和解决上有丰富的经验。疫情期间，他们克服在家办公干扰多,远程沟通不便等不利因素，通过微信、远程会议等方法随时和我们保持联系，结合我们对业务逻辑的理解，协同定位问题，一起梳理了业务近半年所有新增数据库表并增加索引，最终慢查询的问题得到有效解决。