1、背景：javascript
公司有好几个项目，其中有App的相关项目，计划下个月开始推广app，担忧到时并发量大时，后台没法支撑；也为了让后台系统更稳定，以及在后台发布更新时不用刻意避开用户使用时间到半夜才能操做；所以开始着手搭建后台系统的负载均衡。css
目前有两台可用的阿里云服务器，而且是在同一个机房的，简称A、B。A配置是CPU4核、内存4GB，B配置是CPU2核、内存2GB 都是好弱的服务器 -_- 。java
2、实现思路nginx
在A、B两台服务器都跑同样的项目，而后在A机器上使用Nginx做负载，关键要解决的问题是session共享。服务器
3、Nginx 基本配置session
worker_processes 和 worker_cpu_affinity，在nginx.conf 配置文件中配置这两个参数。并发
一、worker_processes：能够建立多少个进程，默认值为1 ，为了得到更好的性能，应该跟服务器的CPU总数或CPU核总数相同；app
查看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 ；curl
二、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