关于自己挖的一个Nginx做视频文件加速的坑

手里有一个中型的网站项目，项目上的图片等静态文件使用自己搭建的多台Nginx服务器做缓存加速，不要问我为什么不用OSS等云存储，当有持续的大量的请求量的时候你就知道按流量计费到底有多坑。

由于考虑到部分图片及js等静态文件可能会有更新的情况，所以缓存的有效期设为了1个小时。也就是每过一个小时Nginx缓存服务器都会去重新请求一次源服务器，以获取最新版本的静态文件。

整套系统稳定运行了几个月以后，通过流量监控系统分析了历史数据发现源服务器的带宽使用一直保持在1-3M之间，偶尔突发流量也会不超过5M，本着够用就好的原则，就把源服务器的带宽调整成了5M（这就是给自己挖了个大坑，真是自作孽不可活啊）。

带宽调整完的几个月里，系统运行也还算稳定，带宽使用也都在正常范围内。就在上个月的一天凌晨，产品经理一个电话把睡梦中我的给召唤起来，说是网站图片加载缓慢。第一反应是Nginx缓存服务器的带宽不够用了，马上查了一下各个节点的带宽使用情况，都不高，或者说低的有些不正常，而且伴随有持续的下行流量，这就不对劲了。

然后马上又去查看源服务器，带宽持续顶满在了5M，已经持续了几个小时了。。。。

翻看日志文件发现几台缓存服务器在不间断的请求源服务器，感觉所有的请求全部都不经过缓存直接转发到了源服务器上了，要知道几台Nginx缓存服务器的带宽使用高峰时期加在一起可是超过500M的，这怎么可能顶得住。

然后又去Nginx缓存服务器上看日志，发现大部分的请求都没有进行缓存，全部转发到了源服务器上，这种情况只有在缓存过期需要从源服务器上更新文件的情况下才会发生啊。要是一台Nginx缓存服务器出现这种情况那有可能是配置问题，目前十几台服务器同时出现这种情况，肯定不是配置问题啊。

顺着日志文件一路看下去，发现有一个mp4的视频文件频繁出现在了缓存日志里，而且每次请求都是缓存失败，字节数每次还都是不同的，然后我就突然意识到了什么。

赶紧上服务器的控制台，把带宽临时调整到了50M，再经过了大约5分钟的满带宽状态后，带宽占用又回到了不到1M的状态，所有的Nginx缓存服务器的状态全部都恢复正常了。

早上9点上班以后，从其他同事那里得知，昨天前端的MM在一个宣传页面上增加了一个视频展示，视频文件甚至都没有做转码，足足有100多M的大小，直接就上传到了源服务器上了。这就是这次事故的罪魁祸首了。

当大量的用户同时请求这个视频文件时，由于缓存服务器上并没有这个大文件的缓存，只能去源服务器请求，由于视频文件过大，无法在短时间内完成请求，即便用户端已经把视频页面关闭的情况下，Nginx缓存服务器还在继续对源服务器的视频文件进行请求，这样在短时间内就会产生大量的回源请求。

在源服务器的带宽又不足的情况下就会出现恶性循环，Nginx缓存服务器一直获取不到完整的视频文件版本进行缓存服务，用户还在不断的发起新的请求，Nginx缓存服务器只能继续向源服务器发起新的请求，导致源服务器的带宽完全被Nginx缓存服务器请求视频文件的请求耗尽，其他正常的请求也一并受到牵连。

知道问题出现的原因了，就好解决了，问前端MM要来那个大视频文件，重新做了一下转码并调整分辨率后，视频文件只有不到20M了，重新替换掉原来的视频文件后，继续观察了一天的源服务器带宽使用情况，峰值带宽降回到了10-20M的样子。这次保险起见，把固定带宽调整到了20M，问题解决！血的教训啊，带宽这个钱是真不能省啊。。。