分布式、集群、负载均衡
- 分布式和集群的区别
- 负载均衡
- 实现负载均衡的三种方法
- 1、HTTP重定向实现负载均衡
- 2、DNS负载均衡
- 3、反向代理负载均衡
分布式和集群的区别
分布式和集群的区别，也就是“分头做事”和“一堆人”的区别。
干同样事的是集群，分工合作的是分布式。1.分布式是指将不同的业务分布在不同的地方。 而集群指的是将几台服务器集中在一起，实现同一业务。
(1)分布式：一个业务分拆多个子业务，部署在不同的服务器上。这样就是每一个节点，都完成不同的业务，一个节点垮了，这个业务就并不能访问了。
(2)集群：同一个业务，部署在多个服务器上。一台服务器垮了，其他服务器可以顶上来。
举例：就比如新浪网，访问的人多了，他可以做一个群集，前面放一个响应服务器，后面几台服务器完成同一业务，如果有业务访问的时候，响应服务器看哪台服务器的负载不是很重，就将给哪一台去完成。
2.简单说，分布式是以缩短单个任务的执行时间来提升效率的，而集群则是通过提高单位时间内执行的任务数来提升效率。
举例：本来一个业务分为10个子业务，一个子业务执行1小时，则在一台服务器上执行10小时。
(1)分布式：提供10台服务器，每个服务器只负责一个子业务，若同时执行则完成10个子业务只需要1小时。
(2)集群：提供10台服务器，每个服务器都能独立处理这个业务。若同时处理10个业务，提供10个服务器同时执行，10个小时后这10个业务同时完成。相当于还是1小时一个业务（但是每个服务器不再是只执行了一个子业务，而是执行了10个子业务）。
总结：
分布式和集群的区别，也就是“分头做事”和“一堆人”的区别。
可以理解为：干同样事的是集群，分工合作的是分布式。“小饭店原来只有一个厨师，切菜洗菜备料炒菜全干。后来客人多了，厨房一个厨师忙不过来，又请了个厨师，两个厨师都能炒一样的菜，这两个厨师的关系是集群。为了让厨师专心炒菜，把菜做到极致，又请了个配菜师负责切菜，备菜，备料，厨师和配菜师的关系是分布式，一个配菜师也忙不过来了，又请了个配菜师，两个配菜师关系是集群。”
负载均衡
问题：一台服务器处理数据（请求也是一种数据）的能力是有限的，当有大量的用户同时在浏览器上输入网址并按下回车键后，就会有大量的请求产生，远方的服务器就不得不处理这些请求，由于请求数量过多，服务器处理的效率就会变慢，响应时间就会变长，这样用户就不能在可以忍受的时间内看到自己想看到的东西，严重影响体验效果。更严重一点，如果请求数量超过了这台服务器所能处理的最大请求，服务器就会崩溃，直接导致网站瘫痪。
解决：建立一个集群（也就是一群服务器）。
用户请求页面的过程：首先用户在浏览器输入网址并按下回车键，然后会产生一个请求，远方的服务器会处理这个请求…等等，现在远方有很多服务器，到底哪个服务器来处理这个请求呢，总不能所有的服务器都处理这个请求吧。哪个服务器处理这个请求？大家明白了吧，这就是负载均衡所要解决的问题。回到上边请求页面的过程，这个请求此时会被一台专门的服务器来处理，这台服务器其实就是个集群的老大，他负责把这个请求派给下面哪个小弟（服务器）来处理，处理完之后返回页面用户。当有多个请求同时发生时，集群的老大可以将请求派给不同的小弟，这样处理的效率就会大幅提升，充分发挥集群的力量，至于哪个请求到底派给哪个小弟，这就是调度策略的问题了。
实现负载均衡的三种方法
1、HTTP重定向实现负载均衡
请求过程：
当用户向服务器发起请求时，请求首先被集群调度者（集群老大）截获；调度者根据某种分配策略，选择一台服务器（小弟），并将选中的服务器的IP地址封装在HTTP响应消息头部的Location字段中，并将响应消息的状态码设为302，最后将这个响应消息返回给浏览器。
当浏览器收到响应消息后，解析Location字段，并向该URL发起请求，然后指定的服务器处理该用户的请求，最后将结果返回给用户。
在使用HTTP重定向来实现服务器集群负载均衡的过程中，需要一台服务器作为请求调度者。用户的一项操作需要发起两次HTTP请求，一次向调度服务器发送请求，获取后端服务器的IP，第二次向后端服务器发送请求，获取处理结果。
HTTP重定向实现负载均衡
优点：采用HTTP重定向来实现服务器集群的负载均衡实现起来较为容易，逻辑比较简单。
缺点：在HTTP重定向方法中，调度服务器只在客户端第一次向网站发起请求的时候起作用。当调度服务器向浏览器返回响应信息后，客户端此后的操作都基于新的URL进行的(也就是后端服务器)，此后浏览器就不会与调度服务器产生关系，进而会产生如下几个问题：
- 由于不同用户的访问时间、访问页面深度有所不同，从而每个用户对各自的后端服务器所造成的压力也不同。而调度服务器在调度时，无法知道当前用户将会对服务器造成多大的压力，因此这种方式无法实现真正意义上的负载均衡，只不过是把请求次数平均分配给每台服务器罢了。
- 若分配给该用户的后端服务器出现故障，并且如果页面被浏览器缓存，那么当用户再次访问网站时，请求都会发给出现故障的服务器，从而导致访问失败。
2、DNS负载均衡
当用户向我们的域名发起请求时，DNS服务器会自动地根据我们事先设定好的调度策略选一个合适的IP返回给用户，用户再向该IP发起请求。
DNS负载均衡
优点：
- DNS负载均衡最大的优点就是配置简单。服务器集群的调度工作完全由DNS服务器承担，那么我们就可以把精力放在后端服务器上，保证他们的稳定性与吞吐量。而且完全不用担心DNS服务器的性能，即便是使用了轮询策略，它的吞吐率依然卓越。
- DNS负载均衡具有较强了扩展性，你完全可以为一个域名解析较多的IP，而且不用担心性能问题。
缺点：
- 由于把集群调度权交给了DNS服务器，从而我们没办法随心所欲地控制调度者，没办法定制调度策略。
- DNS服务器也没办法了解每台服务器的负载情况，因此没办法实现真正意义上的负载均衡。它和HTTP重定向一样，只不过把所有请求平均分配给后端服务器罢了。
- 当我们发现某一台后端服务器发生故障时，即使我们立即将该服务器从域名解析中去除，但由于DNS服务器会有缓存，该IP仍然会在DNS中保留一段时间，那么就会导致一部分用户无法正常访问网站（可以用动态 DNS来解决）。
3、反向代理负载均衡
用户发来的请求都首先要经过反向代理服务器，服务器根据用户的请求要么直接将结果返回给用户，要么将请求交给后端服务器处理，再返回给用户。
反向代理负载均衡
优点：
- 隐藏后端服务器。与HTTP重定向相比，反向代理能够隐藏后端服务器，所有浏览器都不会与后端服务器直接交互，从而能够确保调度者的控制权，提升集群的整体性能。
- 故障转移。与DNS负载均衡相比，反向代理能够更快速地移除故障结点。当监控程序发现某一后端服务器出现故障时，能够及时通知反向代理服务器，并立即将其删除。
- 合理分配任务 。HTTP重定向和DNS负载均衡都无法实现真正意义上的负载均衡，也就是调度服务器无法根据后端服务器的实际负载情况分配任务。但反向代理服务器支持手动设定每台后端服务器的权重。我们可以根据服务器的配置设置不同的权重，权重的不同会导致被调度者选中的概率的不同。
缺点：
- 调度者压力过大 。由于所有的请求都先由反向代理服务器处理，那么当请求量超过调度服务器的最大负载时，调度服务器的吞吐率降低会直接降低集群的整体性能。
- 制约扩展。当后端服务器也无法满足巨大的吞吐量时，就需要增加后端服务器的数量，可没办法无限量地增加，因为会受到调度服务器的最大吞吐量的制约。
