00:00
好,同学们,刚刚我们给大家讲解了负载均衡的基本策略,就是它的轮群策略,那接下来呢,我们再给大家来看看一些不太常用的这些负载均衡策略,之所以说它不太常用的是基本上不会在我们的生产环境当中使用,在这呢只做了解,我就在课上呢,不会再带着大家来配置演示了,大家也没必要去花太多的时间去研究这个东西,我也会给大家说清楚道理的啊呃,这剩下这几种这个,嗯,负载均衡的这种模式呢,和前面这些呢,前面的这个轮询和权重呢,有一点不同,这轮询的这种策略啊,其实它是有一个问题的,这个问题就是它无法保持绘画,什么叫无法保持绘画呢?给大家画一张,再给大家画一张图来看一下啊,还是一张图吧。我们在轮询后端的几台服务器的时候。后端呢,一般来说我们都是应用服务器,比如tomcat。这tomcat我们是不是在访问的时候,更多的时候需要用户去认证,去登录啊,那么你在正常情况下去访问一个tomcat的时候,我们在这台机器上登录了,那么接下来我在访问的时候呢,他给我转到了另外另外一台机器上,那这个登录之后是不是会给我们下发cookie,在服务器端去存储session,那它存在哪了?是不是就存在当前这一台里了?
01:21
对吧,那么你再放另外一台这个tomca的时候,由于它是轮巡的,那么这会儿会这这会儿会怎么着,这会儿它这没有它这个存储的session,它的cookie和这边的session它对不上他要或者他压根就没有,它会提示它重复,再还需要再去登录,不止登录啊,只要是一系列需要维持和保持会话的一系列操作,比如说一些需要有流程化的操作,我点了一下鼠标,接下来它提示我之前内部操作没有保存。这个是不是也是不行,所以这里边儿需要保持绘画轮询这种方式单纯的使用是肯定不行的,因为这样没法去保持绘画。
02:01
那么另外这几种这个负载均衡策略呢,就是为了让我们去保持会话的,首先我们先来看第一种,这叫IP哈希的呃负载均衡策略,IP哈希这种负载均衡策略呢,会让我们的客户端在请求到我们的NG格的负载均衡器的时候,会让他定向去转发到同一台服务器,它的判别的呃依据是来源的IP地址。IP哈希。他会判断来源的IP地址。相同的IP指向相同的服务器,那么这会儿我们在请求这个NG的时候,是不是我的客户端的IP,呃,只要不变,它就会指向呃相同的一台服务器啊,对吧?啊,那如果IP变了呢,这会儿是不是也是不好使了,为什么说它不常用,因为这些这个固定这种配置的和现在的这个当前的互联网环境对比起来,已经是已经是这个无法适应了,比如说我们现在是手机的移动端,那手机信号时好时坏,我走着走着走着,他给我切换了一个移动的基站。
03:04
那么这会儿这个IP地址是不是就变了,我的点着点着稍微一动,坐车的时候可能就不太行了,对不对。对吧,所以IP哈希也没法去保证这个绘画,那所以一般来说我们也不会用这个IP哈希去做这种负载均衡策略来维持绘画。那么再看另外一种。这是IP哈希啊,叫list,呃,Connection conn这最少连接数的访问,这个是为了保证我们后端的服务器能够达到,呃,它这个负载更加均衡。当有一台服务器连接的次数过多,比如这有1000个用户在连接了,这边呢只有20个,那么把额外的这些请求了转发到这20个上边。那其实这样合理吗?感觉上好像是比较合理,但实际的应用的时候呢,也是不合理的,我们想一想,一般来说它分配的比较少是因为什么?是因为他轮询的时候没有给他更多的用户,对不对?
04:01
那么一旦他的用户真的是变少了之后,我们把。这些这个额外新的这些用户全都给的这台机器,那么这台机器用户就变多了。那么它之所以少,可能是因为我们配置的这个权重它比较低,因为它机器的配置比较低,所以我们才让他这个接受的用户比较少,才会造造成这种流量倾斜,流量不一致,这有1000个用户,这只有20个用户,不然的话,正常情况下这是不可能的。啊,另外呢,这种固定化的配置,它也不支持我们的服务动态上下线,比如我们现在有三台机器,那么上新一台机器,这台机器的连接数当前是零,那其他机器呢,现在都有一两百个这个连接上了一个零,那么接下来把最少连接的这个分配给我们这个用户,这个也是不行的,因为你上线一台新的机器,你需要reload重新加载一下这个配置,那就会造成你的这个服务在短时之间内会中断,我们也之前给跟家讲了这个reload的过程是啥,他会把原来这些工作进程给他给停掉。
05:05
对吧,然后把这个新的这个工作进程给它给起来,新的工作进程起来之后,监测后端的这个。服务呃,也会在这个呃短时间之内把这个服务呢,基本给他完成,完成之后,那后端的服务是不是也基本上就趋近于平衡状态,基本也就是差不多都都都归零了,如果还没归零的话,那么这会儿我们可以认为它是这种比较耗时的服务。诶,他可能是比较耗时的服务。那么只有在这么一种情况下,比如说请求打到我们的后端的服务,后端的服务呢,需要一两分钟,比如两分钟才能完成一个用户的请求。那么这两分钟,他要保证在这两分钟之内不和客户端断开连接,同时这两分钟呢。处理完成之后,还能正常的把这个数据给我返回给我们的用户,那这个用户还得在这等待两分钟,大家想想有没有这种应用,我们点击了一个,呃,提交的按钮,在后端的服务呢,需要好长的时间,比较耗时,然后才把这个请求给我们反馈回来。
06:18
有没有这种请求?是不是几乎见不到?那遇到这种请求我们会怎么办?一般来说都会异步化处理。在我服务地端做一步化处理的时候啊,学过这个消息中间件的同学应该比较了解,我可以把它写到消息中间件里等着呢,真正的这个后端慢服务啊,比较厚实的服务,那些处理这个慢服务的。啊,慢服务的应用服务器,真正把这个数据处理完成之后,在异步以异步消息通知,或者以异步数据存储的方式通知给我们的用户就好了。所以这种呃,List connection这种方式呢,其实也是非常不常用的。
07:02
啊,几乎是用不着。那我们再看这个这个fair。啊,这个fair啊这呃,这种方式呢,其实它也怎么说呢,这种方式它需要用到这个第三方的插件,我们需要下载下载第三方的这个组件,然后配置到我们原始的这个NG里才可以使用,这种方式呢,是根据后端服务器的响应时间去转发请求,这其实想想啊,也不是特别的合理,比如说我们的NG到这台服务器需要100毫秒,到这台服务器呢,需要五毫秒,那我们把请求全都转发给五毫秒这台机器,那是不是会势必会造成流量倾斜。那接下来所有的请求全都打到这台机器上了,那可能只是因为网络延迟瞬时比较高,什么情况会造成网络延迟瞬时比较高呢?比如说交换机过热,这台机器的所接入这个,呃,网络的交换机和另外两台呢,它不一样。
08:01
对吧,交换机过热了,另外两台呢,还还不热,还这个还比较这个清爽,现在工作状态呢还比较正常,只有他一台机器过热了,那么导致把所有的流量都倾斜到了另外两台机器上,导致他们两台机器的负载呢,会瞬间变高,那有可能直接就把它给压垮了,这是非常有可能的,所以这种情况呢,我们也不会采用这种这个。呃,这种按照服务器响应时间来去转发请求,因为它会有流量倾斜的风险,对吧,同时这个这种情况呢,还得需要这个我们去下载一些第三方的插件。它和官方的又不太一样了。呃,再有就是URL哈希,这URL哈希是啥意思呢?这也需要第三方的插件啊,它默认也是不支持的,URL哈希呢,也是为了保持这个会话来使用的。呃,URL哈希就可以完成这种定向的流量转发。注意它叫定向流量转发啊,它不一定是定向的用户转发,我们前面说这IP哈希,它是以用户的IP地址为基础,相同的IP分到一台服务器上,这URL哈希呢,把URL我们访问的,比如说HTTP冒号双斜杠,At硅谷。
09:20
点。com斜杠。呃,注册个用户吧,啊,在我们的这个。呃,这个这个上硅谷的官网啊。在注册的这个页面,当他访问到注册的页面,它会根据当前的完整的URL给我们取一个哈希值。相同的哈希值呢,我给他转到相同的服务器上,这叫定向流量转发,这不是定向用户转发,它会造成什么情况,他去注册用户的时候。被转发到了这台服务器。
10:02
哎,是不是发现问题了,原本我们以为他能够帮我们去维持会话,对吧,那如果要是接下来下一个地址啊,我们要这个登录了login。这个取出来的哈气值呢,和前面的又不一样。诶,那他可能会被转发到。这台服务器你想想需要重新登录吗?或者是这个session,呃,Cookie的绘画能不能保持也不能这个呢,嗯。幼儿哈希,它比较适用于什么场景呢?它比较适用于我们去呃。访问固定资源的时候,而不是呃维持绘画,维持绘画他做不到固定资源。不在同一服务器。假设说我们现在有100个文件。
11:04
这100个文件,我们是散落在不同的服务器上的,哎,比如说前边33个我在第一台,后边33个在第二台,啊,这也33个,最后只有一个。只有一个文件在这。那么想要去找这个文件,我就必须得从这台服务器去找,那怎么去找,根据URL去定位,定位到这个文件它在哪台服务器,它定位到别的服务器上,他找不着。只有这么一种情况,我们才需要用到这个URL哈希。大家听明白了吗?这是ul哈希定向流量转发啊呃,这三种,这个再给大家说一下,额外的这是三种四种,IP哈希,List connection UR哈希和这个fire。基本上在我们的生产环境当中都不会用,它有一个最核心的问题就是他没法去动态去上线项,我这一组服务器当中,呃,我想要去改变,比如说现在想想要让他下线一台服务器,接下来我动态上线了两台服务器,这是做不到的啊,动态上下线做不到,然后呃,这些这个固定的这些转发地址呢,只能从我们的配置文件里,这个固定的配置文件里去转发这些地址。
12:14
啊,所以它非常的这个不灵活,呃,非常的死板,那么真要用到这些这个特殊的场景的时候,我们会怎么做,我们会在后边的课程里边会给大家讲到用撸啊脚本的方式。却在我们的NG里边去编程,诶来动态去管理我们当前这个服务的列表,包括我们也可以去检测后端服务器的上下线的情况,包括我们也可以在里边去配置这个权重值,包括我们可以去做定向的这种流量的转发,以及这个IP的这个来源。啊,当然一般来说,我们不会去以IP来源去固定转发这个用户的请求啊,这种这种这个呃,IP以IP的这个来源来固定转发请求呢,也会有相同的问题,就是。它的这个流量有可能会倾斜,流量倾斜这个问题是非常严重的,比如我们现在有四台服务器。
13:06
后边三台都在这闲着,只有一台非常忙,这是非常非常有可能造成这种情况啊,流量一旦要倾斜了,有可能这一台机器就被击垮了,后边那些机器呢,诶还还很还很空闲,所以我们在呃真正的实战的环境当中,就是企业的这个实际的场景当中,呃,要么呢,就只用这个RR,就是轮询的方式,这种轮询的方式呢,没有什么不好的,唯一的不好的就是它的绘画没法保持,要么呢,我们就是用呃撸R脚本去自定义的转发规则啊,用这种第三方的非常非常的少啊,因为它非常不灵活,你想要去更改的话,就必须得把服务的配置文件重新加载重启啊。那么在这个呃轮询的过程当中,我跟大家说了,这是最常用的,那么绘画又没法保持,那怎么办?如果你学过Java的话,或者Java的学的比较多的话,你会学到这么一个东西啊,就基于客户端的这个绘画呃保持工具啊,因为后端的所有的服务呢,只要你做到这个轮询就没法做到有状态,有状态指的就是在独立的一台服务器上的,我们存储用户的一些固定的信息,比如说session,这就是状态信息,因为一个session对应到一个cookie上。
14:21
比如在这产生的session。那么他就会下发一个cookie给一个用户。一个session对应一个cookie,这是一一对应的啊,你要在这个服务器端存储这个session,那下次才能找得着这台服务器上的,没存储啊,这就不行,什么叫状态信息?这就是状态信息,Session存到服务器上,这就是状态。那如果我们做到这种集群的话,就必须要做无状态的,就是在服务端不存session,那有什么方案呢?比如说呃,你学过spring session的话。那我们就可以通过这个技术框架呢,把session啊,统一的写到另外的一台独立的服务器里,比如说我们把它存到里,它的默认解决方案也是把这个session存到服务器上。
15:11
当用户提交cookie上来之后,啊,Cookie和session的这个原理大家都理解吧?啊cookie提交上来,然后我们的服务器端呢,比如tomcad,他会找这个session,那在本机上没有了,那你更改了配置之后,他会去这个服务器上去找这个session。那这样就达到了三生共享对吧,这是最基本的这个呃集群化啊,这个三生共享的,呃,这种这个这种方案啊,当然这也是有状态啊,但是这个状态不存在于每一台独立的服务器上了,我不管你怎么轮询,他都去这个里去找。啊,相同的这个cookie都能找得着啊,当然这个这种场景啊,不适用于大大规模的高并发这种场景,高并发的场景呢,我们会用到完整的这种,或者真正的这种无状态绘画,就是下发这个token。
16:01
这下发token呢,大家呃,做过的话应该也都比较理解了啊,我简单给大家带一嘴啊,这下发token是啥意思?用户请求到我们的N这个的服务器,N这个服务器会找到一台专门负责权限校验认证的服务器。就这台服务器吧。专门去做权限校验,当用户的请求到这个权限校验这台服务器上,比如说他登录了在这台机器上,呃,他会校验他的权限,校验成功之后呢,给他下发权限,全都记录到一个文件里,或者记录一个比较长的的符串,这这个就是token token有自身的校验方式,就像下发cookie一样,把它给下发到我们的这个,呃,这个客户端它替换掉了cookie,原本的cookie呢,只有一个这个session ID,在这个token里边呢,不记session ID了,它记录的是什么呢?当前用户的信息,并且两方呢,给他做了一层加密。因为这个token呢,客户端是无法更改的。那么接下来用户在访问我们的服务器的时候,我们的服务器会拿一个token啊。
17:04
把它给解开,如果他改了之后啊,篡改之后这个脱N就解不开了,正常情况下能给能给它解开这个脱客里边存储的就是这些状态信息,把session和cookie整合到了一个文件里,服务器端又不存它,服务器端只做校验,相当于一个压缩包啊怎么说呢,比如说我的用户登录之后呢,登录成功了,我们给他下发这个token,呃,这个token里边呢,嗯,比如说我们打包一个,呃,压缩包2A2给他加了一个密码。这个密码呢,只在我们服务器端有,客户端没有,那我下载下发给我们的客户端,客户端呢,也不需要读得懂这个toke里边究竟是啥,但是你每次访问只需要带着这个token来就可以了,它带过来之后呢,只有我服器端有这个密码,我可以把它给解开,你客户端它解不开,解开之后你改了之后到服务器端就解不开了,服务端解不开的话,我就认为你这次全限教验失败了,那以这种方式叫无状态的绘画保持方式来维持这种,呃,这个绘画这是现在比较主流的方式,而不是用这种像什么IP哈希啊,呃,或者一些其他的方式去做这个,呃绘画保持这基本上也是在企业里边没人这么用的啊,如果这么用的话,肯定会出问题。
18:19
啊,这是额外的几种这个负载均衡的策略,这些都是不常用的。
我来说两句