00:00
那同学们这节课我们一起来看看NGS对于上游服务器的健康检查这种机制啊,首先呢,我们先看看它这个重试机制,呃,在NG的这个内部就已经帮我们去呃做好的这种重失败重试这种机制了,也就是如果我在upstream里配置好了两台上游服务器,其中有一台如果要是不可用的话,那么它会把这个请求转转向下一台。然后再把这个结果给我们发回来,而不是在请求的一次上游服务器不可用而直接给我们报错。那这呢,我们先看一下,还是老规矩啊,我们看一下它的这个官方文档。在这儿。呃,Per next upstream,这是在我们做反向代理的时候可以去配置的,那么它可以选的这个参数呢比较多,这里边所指的就是当发生了呃哪些错误之后,然后开始去尝试使用下一个upstream里的呃,这个上游服务器。
01:01
比如说发生了一些严重的错误,呃,连接超时,你像这个错误呢,比如说我们再去发送一些这个,呃请求的时候,上游服务器报错了啊,报了一个非正常的状态码,然后呢,这会儿我们就认为它是error状态,然后turn out就是连接。失败,然后这个无效的header,包括这个具体的什么状态码,五百五零二五零三五零四四零三四零三四零三四零四等等等等啊,或者说直接把它给off掉,如果把它off掉的话,它就不会再去帮我们去重置下一个这个服务了,那么在这个配置文件里呢。我们打开看一下。嗯,这个是配在这个upstream上的。User local in。Cuf这儿。啊,首先呢,我们在这儿呢,是有这upstream的,有这么几台机器可以去这个,呃,让他去尝试去访问,比如说他访问第一台失败,然后呢,它进入到第二台里边,然后在这里边就可以配置这个,呃,具体的错误了,但是现在咱们的这个是呃,Stream的啊,HTTP的也是一样,这里边也是我们在这呢,再复制出来一个我们看看。
02:18
104,然后105。两台机器,然后在这下边儿。我们的pro pass,这比如在这儿呢,我们去pass。HTTP这个。那么在这呢,就可以去配置它的这个,呃,失败的策略,比如在这儿,Process next upstream。啊,在这呢,就可以去配置它具体的这个错误了,它默认情况下就是这两个,一个是arrow,一个是timeout。
03:02
这个其实是不太需要盖的。就是发生什么错误,这指的是发生什么错误的时候,开始去尝试下一个服务器arrow就压根就连不上啊,或者是这个呃,报了一些这个呃,这个这个这个头部的错误啊,404了什么的,然后这个连接超时啊,这个也属于这个呃一种错误,这两种都可以呃引发他下一步操作。那么他下一步呢啊。再看在这儿next upstream timeout啊,这是指的是。呃,去上游服务器再去做失败重试的时候啊,它所允许使用的总时间,它默认是零零,就是不限制啊,我们只是在这儿呢,设置它总共你再去做这种这个失败重试的时候呢,你可以去消耗15秒的时间,超过了15秒之后呢,就认为这次请求呢,就彻底失败了,直接告诉我们的用户。
04:05
这就失败了啊,然后这个是per next afternoon。这指的是在呃总时间内,它可以尝试多少次,它默认是零次,这个也是设置成零的,它就不限制你有几个呢,它就设置它就来几次,直到最后一个啊。呃,比如说我们就可以允许让它,呃这个这个这个RERE5次尝试,在这试五个机器,然后如果再不行,那总的时间15秒之内,我就让他这个呃这个这个彻底失败,当然这个设置这个时间啊,在重失败重置这设置这个时间,你一定要注意,如果设置的特别长的话。啊,并且你的这个upstream的列表里机器特别多,它就非常有可能,呃,他在访问一台机器时候呢,它卡死了。啊,然后这个第二台机器呢,它没法得到这个重试,在一台机器上呢,就已经直接让它,呃,这个这个把所有我可以让它使用的时间全部都消耗了,但是如果要是不设置这个总共可以使用的时间呢,用户这一端呢,又没法做这种快速失败,也就是他在访问你的站点的时候。
05:17
他会有可能会在这儿一直等着啊,而没得到这个结果,如果要是一下没取出来,其实我们可以直接反馈一个这个错误告诉用户呢,一会儿你再试一试啊,这样可能他的这个,呃,这个这个用户的体验度吧,他可能会更好那么一点啊,嗯,那么这是针对于一次请求的,他来了之后啊,我怎么去按照什么规则去,呃,请求下一台服务器的。那如果下一次这个请求再来了,那么这个呃,这台机器刚刚就已经刚这个这个没访问成功,那么接下来还会再去访问它,那这样就显得挺挺没有效率的,那所以这里边儿呢,还有额外的两个配置。呃。
06:00
在这儿。一个是这个max files,这个max files呢,是在这个uptre里边,针对于每个server来配置的。这个max style呢,就指的是这台机器呢,它总共呃失败多少次,允许它失败多少次啊,在允许这么失,比如说它允许失败他五次啊失失败五次我都能忍,如果要超过五次之后,我就直接给你标记成不可用。那么下次再有用户来请求的时候呢,就不会再向这台机器发送请求了。那如果一直他是下线的状态,那么这会儿他可能又缓过来了,比如说又有一些网络这种丢包这种情况出现啊,那一会儿缓过来之后呢,什么时候让它上线呢?这呢就有另外一个呃,参数叫file time out。这个他们out。指的是。在他失败五次之后啊,会给它给摘下线,就不在这个列表里了,那超过十秒之后啊,过了摘下去之后十秒,那我还可以再给它重置,再给它上线一次啊,这是file time out的第一层含义,它有第二层含义,就是这五次是在十秒之内失败的。
07:20
啊,我会给他给摘下线,如果要是这五次呢,就是今天一次,明天一次,然后下个月又来了一次。那这会儿累积了五次给他摘下线也不合理,所以要标记一个时间,比如十秒之内五次失败。然后呢,我就让他下这个这个下线,这是双重双重约束,上边这个是约束他什么时候下线的,不在这个列表里,下边这是标记了他去寻找,寻找这个这个呃,上游服务器的时候。在重试的阶段的一些限制,比如说重试的次数啊,可以重试多少次,然后呃,这个在重试的过程当中,整个过程的所消耗的时间允许他有多长啊,这是它的这个失败重试机制,在这还有一点需要注意,它这个retres重试的这个次数是包含你第一次请求的。
08:13
既然ret踹了嘛,这retre就是第二次了,第一次没成功它才会ret踹这个时间啊,你千万不要把它设置的特别特别的小,然后这个ret踹的次数也别设置太多啊,就特别容易造成那种呃,他还没来得及尝试的,然后直接就。这个这个这个反馈给客户端啊,他他直他直接就挂掉了啊,并没有进行这个重置操作啊,还有就是容易有一个这个请求啊,如果这在这不配置这个fair time out有一个请求打过去啊,然后这个嗯。延延迟过长而导致他的这个这个请求这个无效,当然还有这个process pass time out啊,去标记这个每一次请求的这个延迟的时长,所以在这儿呢,呃,对于一个请求失败重试呢,是有很多参数可以来配合使用的。
我来说两句