标签：硬件 http 服务器集群 服务器ip 灾难 内核 分配 实践 width
随着网站的业务越来越多，网站的服务就变的很重要，假设某天你的服务器挂了，会不会是一个天大的灾难呢？而且这种事情发生的概率还不小，断电了，服务器硬盘坏了，内存坏了等等，都会使你的系统挂掉，而且高并发的访问有时候也会使系统资源耗尽，然后导致服务器宕机，那么解决方案呢，那就是集群，将相同的系统分别放到不同的web服务器或者硬件服务器，这样其中一个挂掉了，网站还可以正常运营。
首先我们应该对web前置做集群，我们的方案是用Haproxy做http协议层的负载均衡，后端部署多个web前置，当然也可以用LVS，负载均衡效率更高，请参考我的另一篇博文：LVS实现负载均衡http://www.cnblogs.com/tangyanbo/p/4305589.html，这篇文章讲的是mysql的负载均衡，当然做web应用的集群原理是一样的，当然还有其他的一些中间件，如Ngnix也是可以的，关于负载均衡的中间件我会另起博客详细讲解的。
理解ip负载均衡和数据链路层负载均衡，需要熟悉tcp/ip协议。
反向代理负载均衡
典型的反向代理中间件有Haproxy和Ngnix，请求转发在http协议层面，其优点是和反向代理服务器功能集成在一起，部署简单，缺点是需要在中间件做http的转发，工作在应用层，且请求和响应都要经过反向代理服务器，容易成为性能瓶颈。
系统架构图：
Ip层负载均衡
通过修改请求目标地址进行负载均衡
具体实现：LVS
优点：ip负载均衡在内核完成ip转发，较反向代理性能要好，但请求和响应都要经过仍然要经过ip负载均衡服务器，因此吞吐量的瓶颈会出现在ip负载均衡服务器的网卡上。
系统架构图：
数据链路层负载均衡
通过修改mac地址来完成请求的转发，负载均衡数据分发过程中不修改IP地址，只修改目的mac地址，通过配置真实服务器集群所有机器虚拟IP和负载均衡IP地址一致，从而达到不修改数据包的源地址和目的地址就可以进行数据分发的目的，由于实际处理请求的真实服务器IP和数据请求目的IP一致，不需要通过负载均衡服务器进行地址转换，可将响应数据包直接返回给用户浏览器，避免负载均衡服务器网卡宽带成为瓶颈。
系统架构图：
Web应用一般都是需要保持用户会话的，因此做集群之后会出现问题，默认情况下，客户端请求是被均匀的分发到后端服务器的，那么同一个会话的两次请求可能会被分配到不同的服务器，那么session就会丢失。
如何解决这个问题呢？
方案1：session复制
就是将1台服务器的session复制到其它所有的服务器上，这样无论访问哪台服务器，都会得到用户的session
该方案的缺点
当服务器的数量比较大时，session同步将会变得相当耗时
方案2：session粘滞
就是用户请求一个服务器之后，同一个会话的其它请求，都会被分配到这台服务器，session粘滞的功能由负载均衡中间件完成。
该方案的优点，解决了session复制的性能问题
该方案的缺点，由于用户的会话被保存到单一的服务器，就容易出现单点故障。
那么有没有更好的解决方案呢？
方案3：session服务器
部署一个专门的服务，保存用户session，同时在web服务器本地也保存一份，当本地没有或者失效时，去访问session服务器，当然session服务器就成了单点，当用户量大的时候也容易宕机，这时可以做一个session服务器集群，做主备同步备份，这样就达到了较好的效果，具体实现可以用redies，memcached等缓存中间件。
系统架构图：
结语：负载均衡至少有2个优点
1. 多点部署，解决了单点故障问题，提高了网站的可用性
2. 能通过利用更多的硬件资源提高系统性能
标签：硬件 http 服务器集群 服务器ip 灾难 内核 分配 实践 width
原文地址：https://www.cnblogs.com/capacity-yang/p/13140581.html
