cover-image 先来看一下数据, 因为26号是出成绩的日子, 所以PV几乎是一个爆炸 PV

Background

先说说背景, 四六级查询其实是瞬时性很高的一块业务, 因为一年只考两次, 然而成绩是在某一天的某一点公布的, 所以注定了那一天的查询量会是一个爆炸.

这一次腾讯微校方面也给予了较大的支持, 赞助提供了腾讯云的资源, 所以我也才能够有信心去支撑如此大的并发量.

Why Node?

从 Node 以及其生态圈 (npm) 这几年的迅速发展来看, Node 的程序健壮性, 稳定性都已经得到了很大的提升, 天猫双十一流量的考验至少证明了这一点. Node 的特性: 事件驱动, 异步编程, 非阻塞式 IO 决定了它非常适合做一些高流量, 低逻辑的中间层业务, 而四六级查询完全符合这一点. 之前我提过, Node 其实是一个平台, 不要把它看做一门编程语言. Node 背靠几十万三方包的 npm, 往下可以完全使用 C/C++ 来实现逻辑, 加上 ES2015 的普及, 从网页到桌面端(nwjs), 从 Web 到客户端(RN), JS 已经可以做很多很多事情了.

方案

用几个关键字来说就是 静态化 + SPA + SLB
前端页面用的是 Vue + Zepto, 把静态资源全部交给 CDN 来承担, 后端只提供 JSON 接口专心处理查询业务.

后端使用了75团的 thinkjs 框架, 不选择Express与Koa的原因是它们太轻量级了, 不适于快速开发, 而且thinkjs直接支持 ES6 (babel), 省去了很多烦恼. 我们预测这次的峰值流量在 300W 左右, 所以使用了 Redis 做快速缓存, 数据库 Mysql. 关于无准考证查询, 专门写了一个 C++ 模块来处理加解密(openssl).

后端除了提供 JSON 接口, 还要负责渲染页面 html, 这是由于涉及到微信 JSAPI 的认证逻辑, 所以需要动态渲染.

部署方案上, 腾讯云提供了4台8核心的机器配合 SLB (负载均衡)转发, 单台机器上使用 PM2, cluster模式跑8个业务进程, 以利用多核心的优势.

数据

oneapm 这是某一台服务器的监控数据, 可以看到26号明显是一个峰值, 但是并没有触顶. 从当天的表现来看, 除了数据库(优化不当), 其余数据都在一个非常低的水平线上, 也就是说完全可以承载更大的流量.

今年的失误

1.没有启用 Mysql 连接池, 导致无法发挥最大的数据库性能

thinkjs有mysql的连接池功能, 为了更大的压榨数据库性能, 把这个开启能减少数据库查询时间.

2.有一个关键查询没有使用索引, 导致性能瓶颈. ★

这个是属于压测失误, 当数据库数据上升到十万级的时候, 索引与否的性能已经很明显了. 开启之后性能直线上升.

扫描二维码,分享此文章

Ling.'s Picture
Ling.

Web开发者. 前端,NodeJS 😈 大三, 找实习啦 ⬇️戳简历⬇️