要安装Nginx，至少需要先安装pcre, zlib、ssl

1. PCRE(Perl Compatible Regular Expressions)这是一个Perl库，用来实现重写rewrite的目的//cmdyum -y install gcc gcc-c++cd /usr/local/ wget ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/pcre-8.35.zip unzip pcre-8.35.zip cd pcre-8.35 ./configure make make install 2. zlib 这是一个gzip压缩库，是提供数据压缩用的函式库 //cmd cd /usr/local/ wget http://zlib.net/zlib-1.2.8.tar.gz tar -zxvf zlib-1.2.8.tar.gz cd zlib-1.2.8 ./configure make make install //或者直接用yum安装 yum -y install zlib* 3. ssl //cmd cd /usr/local/ wget http://www.openssl.org/source/openssl-1.0.1i.tar.gz tar -zxvf openssl-1.0.1i.tar.gz cd openssl-1.0.1i ./config make make install Nginx安装

cd /usr/local/wget http://nginx.org/download/nginx-1.7.4.zipunzip nginx-1.7.4.zip cd nginx-1.7.4 ./configure --prefix=/usr/local/nginx make make install //或者 [nginx] name=nginx repo baseurl=http://nginx.org/packages/rhel/6/i386/ gpgcheck=0 enabled=1 //这里baseurl根据系统和版本填写

1. 单独为每个服务器建立专用账户例如nginx帐号cat /etc/passwd | grep nginxnginx:x:496:492:nginx user:/var/cache/nginx:/sbin/nologin 这个nginx账户是一个nologin账户，关于"nologin"这个安全机制，我们简单了解一下 "nologin"这种配置仍然允许这个用户执行重要的日常任务，比如收发信件，FTP，访问网络共享目录和其他任务。它只是阻止用户登录服务器。如果服务器是一个主域控制器，用户主要在他们的工作站上使用Linux，那么采用这样的配 置是个好方法。这个方法也可以阻止因为用户设置了脆弱的密码而导致的非法登录服务器的事件发生 nologin的配置指令如下 1) 存在的用户，执行这个命令： usermod -s /sbin/nologin 
    
      2) 对新用户，可以使用这个命令： useradd -s /sbin/nologin 
     
       3) 用-D选项把每个用户的登录shell设置成缺省的/sbin/nolgin(这个需要在环境变量中定义一下别名) useradd -D -s /sbin/nologin 这样，在使用useradd增加新用户的时候，就不需要用-s选项指定登录shell了，缺省的登录shell就是/sbin/nologin
     
    

反向代理(Reverse Proxy)方式是指以代理服务器来接受Internet上的连接请求，然后将请求转发给内部网络上的服务器，并将从服务器上得到的结果返回给Internet上请求连接的客户端，此时代理服务器对外就表现为一个服务器(其原理非常类似用iptables实现的IP复用技术，通过处于网关处的iptables将内网的DMZ区域的服务器流量NAT出来，向外部提供服务)

使用反向代理是可以降低原始WEB服务器的负载。反向代理服务器承担了对原始WEB服务器的静态页面的请求，防止原始服务器过载。它位于本地WEB服务器和Internet之间，处理所有对WEB服务器的请求，阻止了WEB服务器和Internet的直接通信。如果互联网用户请求的页面在代理服务器上有缓冲的话，代理服务器直接将缓冲内容发送给用户。如果没有缓冲则先向WEB服务器发出请求，取回数据，本地缓存后再发送给用户。这种方式通过降低了向WEB服务器的请求数从而降低了WEB服务器的负载(反向代理可以作为提高性能的一种方案)

1. 普通的代理服务器通常的代理服务器，只用于代理内部网络对Internet的连接请求，客户机必须指定代理服务器,并将本来要直接发送到Web服务器上的http请求发送到代理服务器中。2. 反向代理服务器    2.1 从名字上就可以看出来，反向代理的连接方向和普通代理是相反的。当一个代理服务器能够代理外部网络上的主机，访问内部网络时，这种代理服务的方式称为反向代理服务。 2.2 在反向代理的场景下，代理服务器对外就表现为一个Web服务器，外部网络就可以简单把它当作一个标准的Web服务器而不需要特定的配置。不同之处在于，这个服务器没有保存任何网页的真实数据，所有的静态网页或者CGI程 序，都保存在内部的Web服务器上。因此2.3 对反向代理服务器的攻击并不会使得网页信息遭到破坏，这样就增强了Web服务器的安全性。 3.4 反向代理方式和包过滤方式或普通代理方式并无冲突，因此可以在防火墙设备中同时使用这两种方式 1) 反向代理 用于外部网络访问内部网络时使用 2) 正向代理 提供内部网络对外部网络的访问能力 3) 包过滤方式 在实际的网络架构中，可以结合这些方式提供最佳的安全访问方式 nginx不单可以作为强大的web服务器，也可以作为一个反向代理服务器 最重要的是nginx还具备实现负载均衡的效果

1. nginx还可以按照调度规则实现动态、静态页面的分离2. 可以按照轮询、ip哈希、URL哈希、权重等多种方式对后端服务器做负载均衡3. 同时还支持后端服务器的健康检查

负载均衡下SESSION共享同步问题

在负载均衡模式下，最关键的一个问题是怎么实现多台服务器之间session的共享(例如串号、webshell间断可用访问等都和负载均衡下的session共享机制有关)

1. 使用cookie替代session能把session改成cookie，就能避开session的一些弊端，在从前看的一本J2EE的书上，也指明在集群系统中不能用session，否则惹出祸端来就不好办。如果系统不复杂，就优先考虑能否将session去掉。但是使用cookie也就意味着将http状态信息的保存任务放到用户身上，一旦用户禁用了cookie，则会给应用系统的交互体验代理很大的影响2. 应用服务器自行实现共享可以用数据库或memcached来保存session，从而在应用系统本身建立了一个session集群，用这样的方式可以令 session保证稳定，即使某个节点有故障，session也不会丢失，适用于较为严格但请求量不高的场合。但是它的效率是 不会很高的，不适用于对效率 要求高的场合(这种方式也给我们带来一个启示: 如果某种数据的同步共享存在难题，则可以在架构上将它"后移"，通过更后端的一个统一的节点服务器来进行统一调度) 3. ip_hash nginx中的ip_hash技术能够将某个ip的请求定向到同一台后端，这样一来这个ip下的某个客户端和某个后端就能建立起稳固的session，原理简单解释如下： result = function hash(ip); 由于hash函数的单向陷门特性，但来源ip足够大的时候，所有的ip就会被"平均"地映射到另一个空间域中(也就是后端集群中) ip_hash是在upstream配置中定义的： upstream backend { server 127.0.0.1:8080 ; server 127.0.0.1:9090 ; ip_hash; } ip_hash是容易理解的，但是因为仅仅能用ip这个因子来分配后端，因此ip_hash是有缺陷的，不能在一些情况下使用： 1) nginx不是最前端的服务器 ip_hash要求nginx一定是最前端的服务器，否则nginx得不到正确源ip，就不能根据ip作hash。譬如使用的是squid为最前端，那么nginx取ip时只能得到squid的服务器ip地址，用这个地址来作分流是肯定错乱的 (即源ip不是真实的源ip空间域，可能只有几个前端负载均衡，那ip_hash的作用自然就体现不出来了) 2) nginx的后端还有其它方式的负载均衡 假如nginx后端又有其它负载均衡，将请求又通过另外的方式分流了，那么某个客户端的请求肯定不能定位到同一台session应用服务器上。这么算起来，nginx后端只能直接指向应用服务器，或者再搭一个squid，然后指向应用服 务器。最好的办法是用location作一次分流，将需要session的部分请求通过ip_hash分流，剩下的走其它后端去。 4. upstream_hash 为了解决ip_hash的一些问题，可以使用upstream_hash这个第三方模块，这个模块多数情况下是用作url_hash的，但是并不妨碍将它用来做session共享： 1) 假如前端是squid，他会将ip加入x_forwarded_for这个http_header里，用upstream_hash可以用这个头做因子，将请求定向到指定的后端： 2) 假如在php中配置的session为无cookie方式，配合nginx自己的一个userid_module模块就可以用nginx自发一个cookie，可参见 2.1) userid模块的英文文档： http://wiki.nginx.org/HttpUseridModule 2.2) upstream_jvm_route模块 http://code.google.com/p/nginx-upstream-jvm-route/