记一次Nginx负载均衡
前因
今天收到客服反馈很多用户说播放视频卡,甚至无法播放,检查后发现分布式存储系统里的某台服务器带宽满了,而导致带宽突然跑满的原因是由于某视频爆火,带宽一下子增加了3G。
过程
简单说下这块的访问流程:当用户访问 http://file.example.com/a.mp4 ,根据DNS解析,这个请求会先到达调度器(100.0.0.1),调度器经过数据库查询,得知这个文件存储在存储服务器1(200.0.0.1)上,然后会给用户返回一个302,把地址指向到 http://200.0.0.1/file.example.com/a.mp4 ,用户请求302后的地址,即得到了资源。
服务器物理带宽跑满,那没其他办法了,只能把带宽调度均摊到其他服务器上。这就有一个问题了,调度器给的地址,是以IP开头的地址,而要修改调度器的话,就要去改数据库了,这个不是一个规范的操作,而且是个危险的操作,所以这个方案直接排除。调度器这块不能更改,那只能从存储服务器1上动手了,当用户访问302后的地址也就是 http://200.0.0.1/file.example.com/a.mp4 时,实际上访问的是Nginx的80端口,这就有文章可以做了,下面是具体思路。
存储1(高流量):当收到用户请求时,先在Nginx里对请求做一个处理,将60%的流量302到存储2和存储3的8080端口,同时新开放一个81端口,用于存储2以及存储3服务器的回源。
存储2、存储3(低流量):安装OCT软件(一个内容缓存服务,类似squid服务),从存储1的81端口进行缓存资源,OCT开放8080端口。
下面是存储1的Nginx配置文件,在对应的location里添加了lua代码,这个是这个架构的核心所在。
1 | server { |
存储2以及存储3上OCT的配置文件则如下:
1 | threads 4 #4线程 |
配置文件配置好后,分别重载服务,即可生效。此时用户再来访问 http://file.example.com/a.mp4 ,那过程就是先到调度器,调度器302到 http://200.0.0.1/file.example.com/a.mp4 ,而后面有60%的概率再返回一个302,将用户302到 http://200.0.0.2:8080/file.example.com/a.mp4 。
结果
原来流量跑满的服务器,流量成功降了下来,而低流量的服务器,流量瞬间上升,客服回访用户,均恢复正常。
记一次Nginx负载均衡