一、背景:
公司有好几个项目,其中有App的相关项目,计划下个月开始推广app,担心到时并发量大时,后台无法支撑;也为了让后台系统更稳定,以及在后台发布更新时不用刻意避开用户使用时间到半夜才能操作;因此开始着手搭建后台系统的负载均衡。
目前有两台可用的阿里云服务器,并且是在同一个机房的,简称A、B。A配置是CPU4核、内存4GB,B配置是CPU2核、内存2GB 都是好弱的服务器 -_- 。
二、实现思路
在A、B两台服务器都跑一样的项目,然后在A机器上使用Nginx作负载,关键要解决的问题是session共享。
三、Nginx 基本配置
worker_processes 和 worker_cpu_affinity,在nginx.conf 配置文件中配置这两个参数。
1、worker_processes:可以创建多少个进程,默认值为1 ,为了获得更好的性能,应该跟服务器的CPU总数或CPU核总数相同;
查看A服务器核数:
# 总核数 = 物理CPU个数 X 每颗物理CPU的核数
# 查看物理CPU个数 cat /proc/cpuinfo| grep "physical id"| sort| uniq| wc -l # 查看每个物理CPU中core的个数(即核数) cat /proc/cpuinfo| grep "cpu cores"| uniq
为4核,所以worker_processes 设置为 4 ;
2、worker_cpu_affinity :cpu上二进制位掩码,将work process绑定到特定cpu上,避免进程在cpu间切换的开销,一般如 worker_cpu_affinity 0001 0010 0100 1000 ;
Gzip压缩
nginx 支持传送数据的压缩,分为两个模块,1.gzip模块;2.gzip预压缩模块,可同时启用。
注意:压缩数据本身也是需要一定的消耗,需要考虑清楚压缩的等级、压缩什么文件类型等,应该避免去压缩那些压缩效果很差的文件,如图片、音乐、PDF等,同时对太小的文件进行压缩还不如直接传输更高效,有以下关键配置:
gzip on; #启用压缩
gzip_static on; #启用静态压缩 (需要编译时增加模块)
gzip_min_length 1k; #压缩的最小长度,默认1024。尽量大于1k。如果小于1k可能反而起不到压缩效果
gzip_buffers 4 4k;#压缩缓冲区,默认为4k递增。注意这里的是 4 4k,不是44k;表示以原始数据4k为单位,4倍申请内存
gzip_http_version 1.0; #识别http的协议版本(1.0/1.1)
gzip_comp_level 2;#gzip压缩比,1压缩比最小处理速度最快,9压缩比最大但处理速度最慢(传输快但比较消耗cpu)
gzip_types text/plain application/x-javascript text/css application/xml;
修改参数后重启 nginx :
cd /usr/local/nginx/sbin ./nginx -s reload
如果出现
nginx: [emerg] unknown directive "gzip_static" in /usr/local/nginx/conf/nginx.conf
则目前nginx不支持gzip_static,可以去掉,也可重新编译支持 gzip_static on ,可参考:
http://blog.csdn.net/u013091013/article/details/51181995
查看效果 curl -I -H "Accept-Encoding: gzip,deflate" http://www.xxx.cn/xxx.js
查看Content-Length 以及Content-Encoding: gzip