1.负载均衡架构

      高并发请求，均衡分发给不同的应用服务器。





核心点：均衡分发。

关键点：1.HTTP请求怎么分发？ 

             2.怎么选择目标服务器？



解决问题：HTTP请求分发。

技术实现：



2.HTTP重定向负载均衡



    特点：重定向服务器仅仅做一件事情：在响应头中写入重定向地址。

              利用路由算法，改写请求的目标IP地址，并把IP地址写入到响应的重定向Head中。

然后把请求发送到用户端。

              用户端解析重定向响应，把请求重新发送给Web应用服务器的目标服务器。

    优点：重定向服务器实现简单，部署简单。

    缺点：1.用户的一次应用请求变成两次网络通信----效率低。

              2.安全性问题：用户重定向到应用服务器，应用服务器需要暴露在外网，

才能被用户访问到，但是容易被攻击----整个系统安全性比较低。

              ====>生产环境中，很少使用重定向负载均衡。

3.DNS负载均衡





解析：前提：域名（www.mysite.com）不是TCP/IP协议的一部分。仅靠域名不能直接建立连接，访问到目标服务器。

          1.域名解析：将一个域名解析为IP地址。

          2.基于IP地址访问：

关键点：DNS解析域名时，对同一域名，解析出不同的地址，来实现负载均衡。

优点：1.部署简单：网络运营上提供DNS解析服务。不需要自己部署DNS服务器。

          2.域名解析只需要一次。不会每次请求，每次解析----相对重定向负载均衡效率更高。

缺点：安全性。用户端直接访问应用服务器，应用服务器暴露在外网。---系统安全性降低。



生产环境：大型互联网应用中，使用了两级负载均衡。

                1.一级负载均衡：DNS负载均衡。DNS域名解析完成第一级负载均衡。域名解析出的IP地址----不同负载均衡服务器的IP地址。不是应用服务器的IP。

                2.二级负载均衡：每台负载均衡服务器后面连接若干台应用服务器，多台负载均衡服务器构成集群，集群负责二级负载均衡。                



4.反向代理负载均衡



 解析：

反向代理服务器向后分发请求时，可以实现将不同用户请求分发到不同应用服务器----来实现负载均衡。

生产环境：适用于规模比较小的应用服务器集群：几台到十几台小规模应用服务器集群。

---可在前面加一台或者几台反向代理服务器实现负载均衡。

                大规模应用服务器集群，不使用反向代理服务器实现负载均衡

---原因：反向代理效率低。性能低。

 反向代理效率低： 

                ==>1.请求： 用户请求发送TCP协议数据包到达反向代理服务器， 反向代理服务器需要进行应用层协议转换为完整HTTP请求，才能转发请求到应用服务器，

                ==>2.响应：反向代理服务器将受到的多个TCP数据包，进行应用层协议转换，完整的响应后，在发送给用户。

                如果大规模应用服务器集群（10000台应用服务器），都通过反向代理服务器转发请求，对反向代理服务器的压力比较重。

核心点：负载均衡服务器进行应用层协议转换，导致性能低下。

解决方法：基于更底层的网络协议，获取更底层的数据包后，进行请求转发，也可以实现负载均衡。不再进行HTTP协议转换。

5.IP负载均衡

           基于更底层协议，获取TCP/IP数据包，直接修改数据包中目标服务器IP地址。





  解析：TCP/IP数据包比较小，修改IP地址后，直接转发，不需要应用层协议转换。转发效率快。

           负载均衡服务器本身的处理能力比反向代理高很多。

           性能压力比反向代理小很多。

  问题：响应瓶颈。高并发响应的数据包通过负载均衡服务器，本身的带宽，就会给网卡造成很大的压力。网卡有可能成为瓶颈---响应数据内容太大，处理不过来。

           请求：数据包一般比较小。

           响应：数据包比较多，比较大（数据内容，图片，HTML页面，JS，CSS）。

  解决方法：数据链路层负载均衡。

6.数据链路层负载均衡





解析：

负载均衡服务器，不在修改IP地址，直接在数据链路层修改数据包中mac地址。  应用服务器集群使用虚拟IP。

响应：直接发送会源地址。由于负载均衡服务器没有修改过IP地址，数据包源地址仍然为源地址。响应不在经过负载均衡服务器。性能比较IP负载均衡进一步提升。

 ----------又称三角模式。

生产环境：大型互联网应用，主要使用的是：数据链路层负载均衡-----性能最好。



7.负载均衡算法：

     路由选择（数据包发送到目标服务器）--->请求被分发到不同服务器---->实现负载均衡--->提升整个集群的处理能力

          问题：怎么选择服务器？选择算法有哪些？

          1.轮询：所有请求被依次分发到每个应用服务器上，适合于所有服务器硬件都相同的场景。

          2.加权轮询：根据应用服务器硬件性能的情况，在轮询的基础上，按照配置的权重分发请求到每个服务器，高性能服务器分配更多请求。

          3.随机：请求随机被分配到各个应用服务器，在许多场合下，这种方案都简单实用，因为好的随机数本身就均衡。如果应用服务器硬件配置不同，可以使用加权随机算法。

          4.最少连接：记录每个应用服务器正在处理的连接数（请求数），将新到的请求分发到最少连接的服务器上----这是最符合负载均衡定义的算法。

          5.源地址散列：根据请求来源的IP地址进行Hash计算，得到应用服务器，该算法可以保证同一来源的请求总在同一台服务器上处理，实现会话粘滞。

8.会话管理：

          负载均衡情况下，如何会话管理？同一会话的不同请求，如果被分发到不同的服务器，造成会话状态不一致---用户体验比较差。

          比如：

1.同一应用会话，向购物车添加删除商品两次请求，如果被分发到不同服务器，造成购物车数据不一致。

2.检测用户登录状态：用户登录后，session在A应用服务器上，用户再次请求时，请求被分发到B服务器，

  B没有用户的session，被认为没有登陆，重新要求用户登录----用户体验比较差。

8.1session复制：



解析：通过session复制，每台服务器都保存相同的session。用户请求不管被分发到那台服务器上，都可以获取相同会话。

优点：实现方式简单---只需要在当前服务器上管理session即可。

被修改的session，会被复制到其他服务器上---所有的服务器都保存相同的session。

缺点：

1.集群规模比较大时（10000），修改一次session，需要同步到所有服务器---通信数据量内容比较大

2.每个session都存储----存储数据量比较大



集群目的：压力均摊---降低每台服务器压力。但是session复制策略，增加了每台服务器的负载压力，消耗资源（内存+带宽），与集群目的相违背。

生产环境：很少使用。



8.2session绑定：



解析：源地址散列算法。用户端IP地址，经过负载均衡服务器的源地址散列算法后，被分发到同一台服务器---用户会话在同一台服务器。

生产环境：很少使用，几乎不被使用-------原因：互联网应用关注点：高性能+高可用。

                当服务器宕机后，服务上的session数据丢失（宕机概率较高：故障，迭代发布需要kill进程）

                ---->请求就会分发到其他应用服务器，其他服务器没有当前用户的session上下文

                ---->用户的应用请求操作都不见了（购物车中商品消失）

                ---->用户体验很差

8.3利用cookie记录session：



解析：服务器将会话数据写入cookie，发送到用户终端。用户终端发送请求时，将cookie随请求一起回发给应用服务器，

         集群中任意一台应用服务器，可以从cookie中提取会话数据进行处理。

         ---->实现会话管理(不依赖应用服务器，每台服务器都可以提取cookie中的会话数据，拿到完整的会话内容)

优点：简单高效。

缺点：1.cookie大小有限----不能记录太多的上下文内容----只能记录必要的数据。

          2.cookie有可能被禁止使用----不能传递cookie----无法管理会话。

生产环境：应用实践中比较实用，但并不是常用方法。

8.4session服务器：

session集中化管理





解析：最常用session管理方法：使用session服务器------集中化管理session。

          应用服务器不在记录任何session信息，需要获得session信息时，从session服务器（集群）中获取session信息---实现session管理。

          下次用户请求被分发到不同应用服务器B，B服务器去session服务器获取相同会话。---请求处理完成后，再将session写回session服务器。

          ====>不管请求被分发到那台服务器，都可以拿到完整的会话上下文--->进行正常的业务处理。

优点：1.session服务器宕机，或者扩容，都不影响session管理。

          2.无状态应用服务器：应用服务器不记录任何session信息，不记录任何有状态的数据----应用服务器就是无状态的---更有利于应用服务器集群的伸缩。

          任何一台应用服务器宕机，不影响session数据----应用服务器不存储session数据。

          应用服务器不共享任何信息----share-nothing架构

          3.share-nothing集群架构-----分布式架构中最高效，最容易管理，最容易实现，集群伸缩，运维各个方面都是最好的一种架构。

          4.有状态专用服务器：session集群管理由状态数据。



生产环境：互联网应用中，最常见，经常使用。