二、Nginx的负载结构
三、LVS和Nginx的对比
四、负载均衡选型
五、在高并发环境中LVS,Nginx的角色
一、LVS负载均衡结构
LVS负载均衡：
针对高可伸缩、高可用网络服务的需求，基于IP层的负载平衡调度解决方法，并在Linux内核中实现了这些方法，将一组服务器构成一个实现可伸缩的、高可用网络服务的虚拟服务器。
IPVS的总体结构主要如下：
客户端访问–IPVS检测负载均衡算法和调度算法–IPVS处理IP包—IPVS根据虚拟服务器与真实服务器链表发往真实服务器(RS)-RS返回数据。
LVS的实现方式：
VS/NAT
VS/TUN
VS/DR
图1
LVS 在生产中的环境：
图2
LVS各种解构的性能分析：
LVS本身是基于ＩＰ层的负载均衡，可以说是最高效的一个种方式。但基于ＮＡＴ方式的，往往在流量的环境中会出现性能问题，ＮＡＴ模式是需要资源最多的模式，其实是TUN模式，ＴＵＮ模式对系统要求也比较高。
目前来说推荐用ＤＲ方式，目前没遇到性能问题。
二、Nginx的负载结构
Nginx的负载均衡是一个基于内容和应用的七层交换负载均衡的实现。
同样Nginx也是一个Http的服务端。
负载均衡主要使用的Nginx的ngx_http_upstream_hash_module模块。
Nginx的负载结构：
图3
Nginx的性能分析：
优点：
Ｎｇｉｎｘ的负均衡实现比较简单，默认对后端有健康检查的能力。后端机器少的情况下（少于１０台）负载均衡能力表现好。
缺点：
所以访问从一个出口出去，容易引起流量浪涌连接失败。后面机器较多时（多于１０）无法良好的发挥机器性能。
三、LVS和Nginx的对比
LVS：
是基于ＩＰ层的负载均衡，特别ＤＲ和ＴＵＮ两种模式可以由后端机器直接对外服务。性能提升明显，负载均衡对资源占用较少。
Ｎｇｉｎｘ：
是基于内容的负载均衡实现，实现模式和ＬＶＳ的ＮＡＴ模式相似，但性能比ＬＶＳ的ＮＡＴ高。
四、负载均衡的选型原则
使用什么样的负载均衡器，不重要，重要的是是公司愿意在这个上面花多少成本来维护他。
下面我们将会为大家提供一个针对ＷＥＢ服务的一个负载均衡方案
LVS=>Nginx=>Cache
对比web1.0和web2.0的解决方案碰到的困难
Web1.0
1、源数据量小，单台squid即可达到很高的命中率。
2、请求量大，用lvs+squid或者dns轮询即可解决问题。
3、squid服务器磁盘IO压力大，用超大内存做cache。
web 2.0
1、数据变化频繁，数据总量大，squid的hast table较大，命中下降。
2、请求量大，种类多，数据源上Ｔ是正常现象，squid的Ｃａｃｈｅ更新现象严重。
3、Cache的IO更新严重，致使效率低下
4、基于ＨＡＳＨ的ＵＲＬ ＣＡＣＨＥ，其中一台Ｃａｃｈｅ死掉，必将引起Hash ReHash
5、压力过大导致的hit ratio抖动
负载均衡的选型总结
总结上面问题如果只是简单的负载均衡，难于解决WEB2.0的问题。Nginx可以说是一个完美的方案，但一个大的网站流量不只是一个千兆网卡能挡住的。
五、在高并发环境中LVS、Nginx的角色
图4
Nginx的实现代码：
部分代码如下：
upstream img1{
server 192.168.100.1;
server 192.168.100.2;
}
upstream img2{
server 192.168.100.1:81;
server 192.168.100.2:82;
}
…
部分代码如下：
location ~ ^/[0-1][0-f]/ {
proxy_pass http://img1;
}
location ~ ^/[2-3][0-f]/ {
proxy_pass http://img2;
}
…
这种结构的优点：
实现了高可用性，最大程度上防止单点，又保证架构的伸缩性。
在后端服务器中模拟url hash的算法来找到内容所在的squid，提高了命中率。
充分发挥机器的性能，架构可扩展性，层次分明。