本篇文章将会从一个朋友的面试题入手,来说一下关于 HTTP 的重定向和负载均衡。
1.HTTP 重定向
1.1 重定向是什么
重定向(Redirect)就是通过各种方法将各种网络请求重新定个方向转到其它位置(如:网页重定向、域名的重定向、路由选择的变化也是对数据报文经由路径的一种重定向)。
上面是百度百科的解释,其实我在想到重定向的时候,第一反应是 Java 中的转发和重定向,其实道理差不多。听我来分析一波。
其实 HTTP 的重定向也算是 URL 的重定向,而URL 重定向,也称为 URL 转发,是一种当实际资源,如单个页面、表单或者整个 Web 应用被迁移到新的 URL 下的时候,保持(原有)链接可用的技术。HTTP 协议提供了一种特殊形式的响应—— HTTP 重定向(HTTP redirects)来执行此类操作,该操作可以应用于多种多样的目标:网站维护期间的临时跳转,网站架构改变后为了保持外部链接继续可用的永久重定向,上传文件时的表示进度的页面。
1.2 为什么要进行重定向
可靠地执行 HTTP 事务;
最小化时延;
节约网络带宽;
出于这些原因,Web 内容通常分布在很多地方。这么做是出于可靠性的考虑。这样,如 果一个位置出问题了,还有其他的可用;如果客户端能去访问较近的资源,就可以更快地 收到所请求的内容,以降低响应时间;将目标服务器分散,还可以减少网络拥塞。
1.3负载均衡的部署方式
负载均衡有三种部署方式:路由模式、桥接模式、服务直接返回模式。路由模式部署灵活,约60%的用户采用这种方式部署;桥接模式不改变现有的网络架构;服务直接返回(DSR)比较适合吞吐量大特别是内容分发的网络应用。约30%的用户采用这种模式。
1、路由模式(推荐)
路由模式的部署方式,服务器的网关必须设置成负载均衡机的LAN口地址,且与WAN口分署不同的逻辑网络。因此所有返回的流量也都经过负载均衡。这种方式对网络的改动小,能均衡任何下行流量。
2、桥接模式
桥接模式配置简单,不改变现有网络。负载均衡的WAN口和LAN口分别连接上行设备和下行服务器。LAN口不需要配置IP(WAN口与LAN口是桥连接),所有的服务器与负载均衡均在同一逻辑网络中。由于这种安装方式容错性差,网络架构缺乏弹性,对广播风暴及其他生成树协议循环相关联的错误敏感,因此一般不推荐这种安装架构。
3、服务直接返回模式
这种安装方式负载均衡的LAN口不使用,WAN口与服务器在同一个网络中,互联网的客户端访问负载均衡的虚IP(VIP),虚IP对应负载均衡机的WAN口,负载均衡根据策略将流量分发到服务器上,服务器直接响应客户端的请求。因此对于客户端而言,响应他的IP不是负载均衡机的虚IP(VIP),而是服务器自身的IP地址。也就是说返回的流量是不经过负载均衡的。因此这种方式适用大流量高带宽要求的服务。
2.常见的软件负载均衡技术
1、基于DNS的负载均衡
由于在DNS服务器中,可以为多个不同的地址配置相同的名字,最终查询这个名字的客户机将在解析这个名字时得到其中一个地址,所以这种代理方式是通过DNS服务中的随机名字解析域名和IP来实现负载均衡。
2、反向代理负载均衡(如Apache+JK2+Tomcat这种组合)
该种代理方式与普通的代理方式不同,标准代理方式是客户使用代理访问多个外部Web服务器,之所以被称为反向代理模式是因为这种代理方式是多个客户使用它访问内部Web服务器,而非访问外部服务器。
3、基于NAT(Network Address Translation)的负载均衡技术(如Linux VirtualServer,简称LVS)
该技术通过一个地址转换网关将每个外部连接均匀转换为不同的内部服务器地址,因此外部网络中的计算机就各自与自己转换得到的地址上的服务器进行通信,从而达到负载均衡的目的。其中网络地址转换网关位于外部地址和内部地址之间,不仅可以实现当外部客户机访问转换网关的某一外部地址时可以转发到某一映射的内部的地址上,还可使内部地址的计算机能访问外部网络。
其实在Nginx里面实现负载均衡的时候,就是通过第二种,反向代理负载均衡,关于这个,之前的文章有专门的实现反向代理实现负载均衡的一篇文章,地址给大家奉上 【https://cmsblogs.cn/1732.html】
3.负载均衡算法(重点)
1、轮询法
轮询法,就是将用户的请求轮流分配给服务器,就像是挨个数数,轮流分配。这种算法比较简单,他具有绝对均衡的优点,但是也正是因为绝对均衡它必须付出很大的代价,例如它无法保证分配任务的合理性,无法根据服务器承受能力来分配任务。
其实说白了就是将请求按顺序轮流地分配到每个节点上,不关心每个节点实际的连接数和当前的系统负载。
这种方式的优点很明显缺点也同样的明显。
优点:简单高效,易于水平扩展,每个节点满足字面意义上的均衡,它无需记录当前所有连接的状态,所以它是一种无状态调度。
缺点:没有考虑机器的性能问题,根据木桶最短木板理论,集群性能瓶颈更多的会受性能差的服务器影响。
给大家个最简单的图:
给大家展示一下简单的代码处理:
public static void main(String[] args) {
int[] arr = { 10, 9, 8, 7, 6, 5, 4, 3, 2, 1, 0 };
int index = 4; // 索引:指定起始位置
for (int i = 0; i < 17; i++) {
int nextIndex = (index + 1) % arr.length;
index = nextIndex;
System.out.println(arr[index] + " ,index=" + index);
}
}
2、随机法
随机法,是随机选择一台服务器来分配任务。它保证了请求的分散性达到了均衡的目的。同时它是没有状态的不需要维持上次的选择状态和均衡因子[5]。但是随着任务量的增大,它的效果趋向轮询后也会具有轮询算法的部分缺点。
其实随机法的优缺点和轮训法的优缺点差不多,不做太多的叙述了。
算法伪代码:
private static Map<String, Integer> serviceWeightMap = new HashMap<String, Integer>();
static {
serviceWeightMap.put("192.168.1.100", 1);
serviceWeightMap.put("192.168.1.101", 1);
serviceWeightMap.put("192.168.1.102", 4);
serviceWeightMap.put("192.168.1.103", 1);
}
public static String testRandom() {
// 重新创建一个map,避免出现由于服务器上线和下线导致的并发问题
Map<String, Integer> serverMap = new HashMap<String, Integer>();
serverMap.putAll(serviceWeightMap);
//取得IP地址list
Set<String> keySet = serverMap.keySet();
ArrayList<String> keyList = new ArrayList<String>();
keyList.addAll(keySet);
Random random = new Random();
int randomPos = random.nextInt(keyList.size());
String server = keyList.get(randomPos);
return server;
}
3、最小连接法
最小连接法,将任务分配给此时具有最小连接数的节点,因此它是动态负载均衡算法。一个节点收到一个任务后连接数就会加1,当节点故障时就将节点权值设置为0,不再给节点分配任务。
最小连接法适用于各个节点处理的性能相似时。任务分发单元会将任务平滑分配给服务器。但当服务器性能差距较大时,就无法达到预期的效果。因为此时连接数并不能准确表明处理能力,连接数小而自身性能很差的服务器可能不及连接数大而自身性能极好的服务器。所以在这个时候就会导致任务无法准确的分配到剩余处理能力强的机器上。
其实还有好几种算法呢,比如说,源地址哈希法 ,加权轮询(Weight Round Robin)法等。
最新评论
Spring Cloud Alibaba 微服务架构实战 https://pan.baidu.com/s/1jF5voFRoeF0lYAzAPBWSbw?pwd=chqk
命令: nload
真是个良心站点哇,大公无私,爱了爱了
还可以直接搞一张映射表,存 uid | time | source_index, 第一次直接查对应的 time 选出前100, 第二次直接用 CompleteFuture 去分别用 source_in
干得漂亮,多个朋友堵条路
2021.2.2版本的不适用吧
现在还可以用么
激活码有用,感谢分享