负载均衡学习笔记

一、背景：

    公司有好几个项目，其中有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

转载于:https://my.oschina.net/u/943166/blog/754202