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