1核2G如何扛住单日TB级的流量？

最近做了一个关于微信投票的项目，由于某些预算原因，以及对用户群体的预估不到位，导致上线后，服务器被拖垮。也被行业大佬喷了，😂😂😂😂，没办法，只有连夜起来进行项目优化，保证用户的正常使用。为此在这里作出一些记录。

项目介绍

该项目可能为某个 xx 单位的项目，经过各种艰难曲折之后进入我手中。项目前端采用 uniapp，因为客户需要小程序+h5，后端使用 golang，数据库 mysql。服务器是自用的阿里云 1 核 2G😂（由于甲方预算太低，加上起初认为这种项目应该不会有多大的流量，就给他提供了这个自用的服务器）。

项目上线，问题展露

当天是周五，下午对方说需要进行上线推广了。于是就直接上线了。下班之后回到家，突然接到阿里的账户余额提醒。由于服务器是采用的按量计费，带宽直接是拉到最大的 100M，所以账户余额疯狂扣费。这可不得了，毕竟这个项目预算有限，就当机立断，把按量改为带宽，把带宽限制降低。降低之后，接到消息说，很多用户打不开页面。进入控制台一看，我靠，带宽满了。

然后进行紧急的带宽升级到 20M，发现还是瞬间被拉满。升级到 50M，依旧如此。想了一下，带宽升级不划算，毕竟升级到 100M，依旧无法解决载入缓慢问题。于是就开始排查载入缓慢的原因。

全站 CDN

经过测试排查，发现是由于该项目中，使用到了一个背景音乐 5M，一个字体 4M，都是甲方提供要求的。这两个文件加载实在是太大了，并且项目中的静态资源也都比较大，影响加载速度。可这大半夜的也联系不到甲方的美工啊，我也不会压缩图片（试了一下，把透明压缩黑了 😂），没办法，先上个 CDN，全站加速。所有资源文件 js、图片、字体、bgm 全部用上 CDN。瞬间，页面加载就流畅了，bgm 也不卡顿了。终于可以安心的睡下了。

第二天出去玩，在路上都是时刻盯着手机，看着这个流量飞速的跑，还是有点虚。毕竟地主家也没有余粮啊。想着回去怎么优化。

重新流回服务器

CDN 流量也是要烧钱的啊。查看热门资源是哪些


除了上面的一些 BGM、字体文件外，就是一些图片。于是就开始进行图片压缩。将部分小文件流量重新导到服务器，毕竟现在服务器带宽有 50M。


处理前带宽峰值达到了 365M，处理之后带宽峰值直接下降到了 68M

部分流量导回服务器后，服务器带宽占用 35M，也算是不浪费服务器带宽了。

后端压力处理

前端访问流畅之后，似乎访问量增加了还是这么的，后台压力激增。服务器 cpu 占用暴涨，直接 100%。进入 mysql，执行SHOW PROCESSLIST;命令，发现大量的查询语句，调用的是一个存储过程。由于前端功能需要，所以封装了一个存储过程。应该是这个存储过程的锅，于是对查询增加索引。优化分页的时机，先进行分页然后在进行相关数据查询处理。cpu 问题暂时解决了。


活动的最后两天，访问突然增加，服务器 cpu 再次满了。依然是 mysql 的锅。前端一个统计接口，频繁查询统计，加上数据量太大。于是手动给后台增加了一个缓存（项目起初没计划使用缓存）。手动实现一个缓存，数据缓存一分钟，然后过期重新进入数据库查询。乍一看没什么问题，就提上去了。后面经过观察发现，隔一分钟 cpu 就要疯一次，虽然不是直接跑满，但是也是跑到了六七十。应该是缓存的问题，设计缓存的时候没考虑缓存过期时，有多少查询落到数据库。由于只做了时候过期判断。导致数据过期的一瞬间，大量查询落入数据，缓存击穿了。由于单机服务，就给查询操作加了锁，进行二次判断。

ok，问题解决。基本服务器 cpu 占用在 30 左右，数据库 cpu 占用在维持在个位数。

总结

本次问题产生的原因，首先是对于用户量的判断不准确，以及前端资源的处理。导致服务器带宽被占用完。经过了一系列的折腾、优化，算是基本扛住了。高并发并非只是对于后端接口来说的，前端也是需要处理的。后端接口并发高，可能对应的前端页面访问量也是非常巨大的，流量的增加，阻塞服务器，直接影响前端用户体验。所以前端开发，使用的资源文件要尽量小。服务器支撑不住，可以上 cdn。后端接口上，需要考虑的就非常多了，业务流程，数据处理，数据库端的处理等等，都要提前考虑。建议上线前进行压力测试。