Nignx

代理

在 Java 设计模式中，代理模式是这样定义的：给某个对象提供一个代理对象，并由代理对象控制
原对象的引用。

正向代理

访问外网 ( 指在客户端进行一些设置 )

反向代理

反向代理和正向代理的区别就是：正向代理代理客户端，反向代理代理服务器。
反向代理，其实客户端对代理是无感知的，因为客户端不需要任何配置就可以访问，我们只需要
将请求发送到反向代理服务器，由反向代理服务器去选择目标服务器获取数据后，在返回给客户
端，此时反向代理服务器和目标服务器对外就是一个服务器，暴露的是代理服务器地址，隐藏了
真实服务器 IP 地址
百度百科的说法：反向代理（ Reverse Proxy ）方式是指以代理服务器来接受 internet 上的连接请
求，然后将请求转发给内部网络上的服务器，并将从服务器上得到的结果返回给 internet 上请求
连接的客户端，此时代理服务器对外就表现为一个反向代理服务器。简单来说就是真实的服务器
不能直接被外部网络访问，所以需要一台代理服务器，而代理服务器能被外部网络访问的同时又
跟真实服务器在同一个网络环境，当然也可能是同一台服务器，端口不同而已。

负载均衡

负载均衡也是 Nginx 常用的一个功能，负载均衡其意思就是分摊到多个操作单元上进行执行，例如
Web 服务器、 FTP 服务器、企业关键应用服务器和其它关键任务服务器等，从而共同完成工作任
务。简单而言就是当有 2 台或以上服务器时，根据规则随机的将请求分发到指定的服务器上处理，
负载均衡配置一般都需要同时配置反向代理，通过反向代理跳转到负载均衡。而 Nginx 目前支持自
带 3 种负载均衡策略，还有 2 种常用的第三方策略。

nginx安装

1. 下载nginx包后解压到某盘（如：D盘nginx文件夹下）

2. 打开cmd，进入nginx下，输入命令start nginx.exe启动nginx

3. 浏览器输入127.0.0.1，进入nginx欢迎页面

4. 服务停止命令nginx -s stop 服务重启命令nginx -s reload

负载均衡简单设置

1.打开D:\nginx\conf目录下nginx.conf文件

upstream servertest {
server 192.168.1.146 : 8080 down ;
server 192.168.1.146 : 8081 weight = 3 ;
server 192.168.1.146 : 8082 ;
server 192.168.1.146 : 8083 backup ;
}
server {
listen 80 ; # 监听端口
server_name localhost ; # 监听地址
location / {
proxy_pass http : // servertest ; # 请求转向 servertest 定义的服务器列表
root html ;
index index . html index . htm ;
}
}
说明：
down ：表示单前的 server 暂时不参与负载
Weight ：默认为 1 . weight 越大，负载的权重就越大。
max_fails ：允许请求失败的次数默认为 1 . 当超过最大次数时，返回 proxy_next_upstream 模块定义的
错误
fail_timeout ： max_fails 次失败后，暂停的时间。
Backup ：其它所有的非 backup 机器 down 或者忙的时候，请求 backup 机器。所以这台机器压力会

域名映射

找到电脑 C:\Windows\System32\drivers\etc 下 host 文件并打开
127.0.0.1 www.wzy.com 将 www.wzy.com 映射到 127.0.0.1 上
在 nginx 中配置 server 中 server_name www.wzy.com
session 共享解决方案
1. 使用客户端的 cookie 作为存放登录信息的媒介
cookie 是将用户登录信息存储在用户终端的数据载体，与 session 的最大区别就是， session 是存
储在服务器端的；所以这就很容易解决这种 session 的多台服务器共享问题。当我们客户端进行登
录的时候，访问的是服务器 a ，登录成功之后我们将 session 抽取出来存放在客户端的 cookie 里
面；然后当我们客户端第二次进行访问的时候，访问的是服务器 b ，这次我们先在服务器 b 去查找
是否有登录成功的 session ，如果为空，我们再对客户端的 cookie 进行查找，如果 cookie 里面已经
存储有 session ，那么再将 cookie 里面的 session 同步到服务器 b ，那么整个流程就能走通了，用户
也不用再次登录；
优点：这种方法实现起来简单，方便，很容易上手操作，不会加大数据库的负担；
缺点：如果客户端把 cookie 禁掉了的话，那么 session 就无法同步了，而且 cookie 的安全性不高，
很容易外部被伪造使用；

2.使用mysql数据库存储session

既然每个服务器都需要使用同一个 session ，那么我们可以将 session 存放在同一个数据库里面，
每次访问的时候，我们去数据库 check 一下是否有这个 session 或者这个 session 是否过期，然后就
可以进行多台服务器的 session 同步了；
优点：使用这种方法简单、方便，很容易上手操作；
缺点：使用数据库来同步 session ，会加大数据库的 IO ，增加数据库的负担；同时，每次访问都需
要拦截请求、查询数据库，导致多一层访问的业务层以及浪费读取数据库 session 时间；

3.使用memcache或者redis等缓存机制存放session

使用 memcache 或者 redis 等分布式缓存机制存放 session 数据，是现在很多大型项目负载均衡同
步 session 的热门方案；它的原理是项目都使用的是同一个地方的 memcache 或者 redis 的缓存，
当用户登录的时候，会把 session 存放在缓存里面，之后不管访问的是项目的那一台服务器，都会
从同一个地方去获取 session 缓存，这样就很轻松实现了 session 同步；
优点：用缓存来同步 session ，不会加大数据库的负担，也不用手动去判断 session 是否存在或过
期，省去部分业务逻辑，同时，由于 redis 等缓存是存放于服务器端，安全性也大大提高；
root html ;
index index . html index . htm ;
}
}
说明：
down ：表示单前的 server 暂时不参与负载
Weight ：默认为 1 . weight 越大，负载的权重就越大。
max_fails ：允许请求失败的次数默认为 1 . 当超过最大次数时，返回 proxy_next_upstream 模块定义的
错误
fail_timeout ： max_fails 次失败后，暂停的时间。
Backup ：其它所有的非 backup 机器 down 或者忙的时候，请求 backup 机器。所以这台机器压力会最轻缺点： memcache 或 redis 把内存分成很多种规格的存储块，有块就有大小，这种方式也就决定
了， memcache 或 redis 不能完全利用内存，会产生内存碎片，如果存储块不足，还会产生内存溢
出。

4.ip_hash

nginx 中的 ip_hash 技术能够将某个 ip 的请求固定到同一台后端应用服务器，这样一来这个 ip 下的
某个客户端和某个后端就能建立起稳固的 session ， ip_hash 是在 upstream 配置中定义的：

upstream servertest {
server 192.168.1.146 : 8080 down ;
server 192.168.1.146 : 8081 weight = 3 ;
server 192.168.1.146 : 8082 ;
server 192.168.1.146 : 8083 backup ;
ip_hash ;
}
优点： ip_hash 算法可以把一个 ip 映射到一台服务器上，这样可以解决 session 同步的问题。这样
每个访客固定访问一个后端服务器，可以解决 session 的问题；
缺点：使用 ip_hash 进行 session 共享，它的原理是为每个访问者提供一个固定的访问 ip ，让用户
只能在当前访问的服务器上进行操作，保持了 session 同步的，但是也造成了负载不均衡的问题，
如果当前用户访问的服务器挂了的话，那就会出现问题了；

5.springsession

XML 复制代码

导入jar
<dependency>
<groupId>org.springframework.session</groupId>
<artifactId>spring-session-data-redis</artifactId>
<version>2.0.4.RELEASE</version>
</dependency>

java 复制代码

编写
@Configuration
@EnableRedisHttpSession
public class RedisSessionConfig {
}

代理