负载均衡（2019.4.9）

前言

       本博客为个人复习时总结用，无商业目的，其大多数内容皆为博主整理所得，并非原创。侵删。

---

正向代理：

正向代理类似一个跳板机，代理访问外部资源。

---

反向代理：

        反向代理（Reverse Proxy）实际运行方式是指以代理服务器来接受internet上的连接请求，然后将请求转发给内部网络上的服务器，并将从服务器上得到的结果返回给internet上请求连接的客户端，此时代理服务器对外就表现为一个服务器。

优点:

1. 隐藏后端服务器。
   与HTTP重定向相比，反向代理能够隐藏后端服务器，所有浏览器都不会与后端服务器直接交互，从而能够确保调度者的控制权，提升集群的整体性能。
2. 故障转移
   与DNS负载均衡相比，反向代理能够更快速地移除故障结点。当监控程序发现某一后端服务器出现故障时，能够及时通知反向代理服务器，并立即将其删除。
3. 合理分配任务
   HTTP重定向和DNS负载均衡都无法实现真正意义上的负载均衡，也就是调度服务器无法根据后端服务器的实际负载情况分配任务。但反向代理服务器支持手动设定每台后端服务器的权重。我们可以根据服务器的配置设置不同的权重，权重的不同会导致被调度者选中的概率的不同。

缺点

1. 调度者压力过大
   由于所有的请求都先由反向代理服务器处理，那么当请求量超过调度服务器的最大负载时，调度服务器的吞吐率降低会直接降低集群的整体性能。
2. 制约扩展
   当后端服务器也无法满足巨大的吞吐量时，就需要增加后端服务器的数量，可没办法无限量地增加，因为会受到调度服务器的最大吞吐量的制约。

---

nginx

        负载均衡的算法怎么实现的 ：

1. 轮询（默认）
   每个请求按时间顺序逐一分配到不同的后端服务器，如果后端服务器down掉，能自动剔除。
2. weight
   指定轮询几率，weight和访问比率成正比，用于后端服务器性能不均的情况。
3. ip_hash
   每个请求按访问ip的hash结果分配，这样每个访客固定访问一个后端服务器，可以解决session的问题。
4. fair（第三方）
   按后端服务器的响应时间来分配请求。响应时间短的优先分配。与weight分配策略相似。
   upstream favresin{
   server 10.0.0.10:8080;
   server 10.0.0.11:8080;
   fair;
   }
5. url_hash（第三方）
   按訪问url的hash结果来分配请求，使每一个url定向到同一个后端服务器。后端服务器为缓存时比較有效。
   注意：在upstream中加入hash语句。server语句中不能写入weight等其他的參数，hash_method是使用的hash算法。
   upstream resinserver{
   server 10.0.0.10:7777;
   server 10.0.0.11:8888;
   hash $request_uri;
   hash_method crc32;
   }

session 共享：

        当nginx做了负载均衡之后，同一个ip的url请求服务器的时候，负载均衡会根据每台服务器的权重等一些设置将请求转发到不同的服务器上去进行处理，这样的话针对一些带有状态请求的情况来说就是个很大的问题，因为是带有状态的请求就好比登陆状态一样，A用户登陆系统，负载均衡机制把A用户的登陆请求分发给了s1服务器，这个时候s1服务器上就会记录A用户登陆的session信息，登陆成功后，当A用户进行相应的操作，比如进入个人中心，这时候这个请求经过反向代理服务器的时候，负载均衡机制根据当前集群中的各个服务器的压力性能等情况可能把请求分发给了s2服务器处理，那么这个时候会去验证用户的状态是否登录，也就是验证session，可是A用户的session保存在了s1服务器上，造成再s2服务器上请求验证状态找不到对应的session，就会认为用户未登录而做的异常操作，就会提醒用户去登录，从而跳转到登录页面，那么这就是负载均衡针对带有状态的请求的一个弊端。

1. 不使用session，使用cookie

        session是存放在服务器端的，cookie是存放在客户端的，我们可以把用户访问页面产生的session放到cookie里面，就是以cookie为中转站。你访问web服务器A，产生了session然后把它放到cookie里面，当你的请求被分配到B服务器时，服务器B先判断服务器有没有这个session，如果没有，再去看看客户端的cookie里面有没有这个session，如果也没有，说明session真的不存，如果cookie里面有，就把cookie里面的sessoin同步到服务器B，这样就可以实现session的同步了。

        说明：这种方法实现起来简单，方便，也不会加大数据库的负担，但是如果客户端把cookie禁掉了的话，那么session就无从同步了，这样会给网站带来损失；cookie的安全性不高，虽然它已经加了密，但是还是可以伪造的，所以这种方式也是不推荐的。

2. session存在数据库mysql

        session保存在数据库中，是把session表和其他的数据表存放在一起，那么当用户只要登录后随便操作了些什么就要去数据库验证一下session的状态，这样无疑加重了mysql数据库的压力；如果数据库也做了集群的话，那么也就是说每个数据库集群的节点都得保存这个session表，而且要保证每个集群的节点中数据库的session表的数据保持一致，实时同步

        说明：session保持在数据库，加重了数据库的IO，增大数据库的压力和负担，从而影响数据库的读写性能，而且mysql集群的话也不利于session的实时同步

3. session存在缓存memcache或者redis中

        memcache可以做分布式，php配置文件中设置存储方式为memcache，这样php自己会建立一个session集群，将session数据存储在memcache中。

        说明：这种方式来同步session，不会加大数据库的负担，而且安全性比用cookie保存session大大的提高，把session放到内存里面，比从文件中读取要快很多。但是memcache把内存分成很多种规格的存储块，有块就有大小，这种方式也就决定了，memcache不能完全利用内存，会产生内存碎片，如果存储块不足，还会产生内存溢出。

4. ip_hash技术，nginx中可以配置，当某个ip下的客户端请求指定（固定，因为根据IP地址计算出一个hash值，根据hash值来判断分配给那台服务器，从而每次该ip请求都分配到指定的服务器）的服务器，这样就可以保证有状态请求的状态的完整性，不至于出现状态丢失的情况。
5. 其他： 例如数据存储服务器。