各位老铁们，大家好，今天由我来为大家分享阿里轻量级开源Web服务器Tengine负载均衡算法-阿里的轻量级服务器，以及的相关问题知识，希望对大家有所帮助。如果可以帮助到大家，还望关注收藏下本站，您的支持是我们最大的动力，谢谢大家了哈，下面我们开始吧！
前言在阿里巴巴七层流量入口接入层（应用网关）的场景下，Nginx官方的Smooth Weighted Round-Robin（SWRR）负载均衡算法已经无法完美施展身手了。通过实现新的负载均衡算法Virtual Node Smooth Weighted Round-Robin（VNSWRR），Tengine不仅优雅地解决了SWRR算法的缺点，而且相比Nginx官方的SWRR算法，QPS处理能力提升了60%左右。
问题接入层Tengine通过自研的动态上游模块实现动态服务发现，即运行时动态感知后端应用机器扩缩容、权重调整、健康检查等信息。同时，这个功能可以做很多事情。例如，用户可以在后端应用中调整某台机器的权重，以达到真正在线引流和压力测试的目的。然而这些操作在Nginx原生的SWRR算法下可能会造成不可逆的谋杀。
Nginx的SWRR算法的处理时间复杂度为O(N)，在大规模后端场景下Nginx的处理能力会线性下降；原生 SWRR 算法分析SWRR算法的全称是Smooth Weighted Round-Robin Balancing。顾名思义，该算法相比其他加权轮询（WRR）算法多了一个平滑的特点。
下面我们用一个简单的例子来描述该算法：
假设有3 台机器A、B、C，权重分别为5、1、1。数组s表示机器列表，n表示机器数量，每台机器的cw初始化为0，ew初始化为机器权重，tw表示当前轮次。 ew 与选择中所有机器中最好的总和代表本轮选择的机器。简单的描述就是每次选择机器列表中cw值最大的机器。被选中的机器的cw会从tw中减去，从而减少下次被选中的机会。简单的伪代码描述如下：
最好=NULL;tw=0;for(i=random()%n;i!=i||falg;i=(i+1)%n){flag=0;s[i].cw+=s[ i].ew;tw+=s[i].ew;if(best==NULL||s[i].cwbest-cw){best=s[i];}}best-cw-=tw;returnbest;请求号在选择前的权重值。选择后所选服务器的权重值。
0 {5,1,1} A {-2,1,1}
1 {3,2,2} A {-4,2,2}
2 {1,3,3} B {1,-4,3}
3 {6,-3,4} A {-1,-3,4}
4 {4,-2,5} C {4,-2,-2}
5 {9,-1,-1} A {2,-1,-1}
6 {7,0,0} A {0,0,0}
SWRR算法选择的顺序为：{ A, A, B, A, C, A, A }
普通WRR算法的选择顺序可以是：{C,B,A,A,A,A,A}
与普通WRR算法相比，SWRR具有以下特点：平滑性和离散性。
调高权重引发的血案从上面的描述来看，SWRR算法看起来是比较完美的，但是在某些场景下它仍然存在一定的缺陷。我们通过一个真实的案例来看看它有哪些缺陷：
注：深蓝色曲线代表权重增加的机器QPS变化，浅绿色曲线代表集群中单台机器的平均QPS。
当我看到这张流量趋势变化图时，我一头雾水，幸好有图表和数据，所以我可以先分析一下这张图表的几个特征数字；由于部分数据较为敏感，这里不进行详细的数据分析。直接描述现象及原因：
大规模下性能骤降压力测试环境CPU型号：Intel(R) Xeon(R) CPU E5-2682 v4 @ 2.50GHz
压测工具：/wrk -t25 -d5m -c500 'http://ip/t2000'
Tengine核心配置：配置2个worker进程，压力源--长连接--Tengine/Nginx--短连接--后端
我们来做一个实验。控制变量为上游配置的服务器数量，观察不同场景下Nginx的QPS处理能力和响应时间RT的变化。从图中可以发现，当后端上游服务器数量增加500台时，Nginx的QPS处理能力下降了10%左右，响应RT增加了1ms左右。
从上面的分析，已经基本确认了SWRR算法存在上述两个缺陷，下面我们开始解决；
改进的 VNSWRR 算法经典的WRR算法（如随机数实现）虽然时间复杂度可以达到O(1)，但也可以避免SWRR算法增加权重的选择缺陷。但在某些场景下（比如流量较小），可能会导致后端流量不均匀，尤其是流量突然增加、不确定性太大的场景。于是我思考是否有一种算法能够同时具备SWRR算法的平滑性和去中心化特性以及O(1)的时间复杂度。于是就有了虚拟节点平滑加权循环（VNSWRR）算法。
下面举个例子来说明这个算法：三台机器A、B、C的权重分别为1、2、3，N代表后端机器的数量，TW代表后端总权重机器。
算法关键点根据SWRR算法严格选择虚拟节点初始化顺序，保证初始化列表中的机器能够分配足够的哈希值；虚拟节点在运行时批量初始化，避免计算集中。每一批虚拟节点用完后，初始化下一批虚拟节点列表，每次只初始化min(n, max)个虚拟节点；
算法描述当Tengine程序启动或运行时感知到后端机器信息变化时，会构建TW虚拟节点，并且只在第一次初始化N个节点（注：TW代表后端机器权重之和， N代表后端机器的数量）；每个进程设置一个随机的起始点轮询位置。如上图所示，Step 1对应的链表起始点指向B；当请求到达时，从设定的随机起点B开始轮询虚拟节点列表。如果轮询到初始化的虚拟节点，则在节点数组的末尾（如上面步骤2中红色箭头所指的位置） ，第二批虚拟节点将被初始化（如上图中步骤2对应的红色节点）。当所有虚拟节点都初始化完毕后，不会做任何初始化工作（如上图步骤3对应的状态）；该方案不仅将算法时间复杂度从O(N)优化为O(1)，而且避免了增加权重带来的问题。如下图所示，某台后端机器的权重从1调整为2后，其QPS平稳增长至预期比例。
算法效果比较在相同压力测试环境（wrk压力测试工具，500并发，长连接场景，上游配置2000台服务器）下，Nginx官方SWRR算法CPU消耗占比高达39%（ngx_http_upstream_get_peer函数）。同等条件下，VNSWRR算法的CPU消耗仅为0.27%左右（ngx_http_upstream_get_VNSWRR函数）。很明显SWRR的CPU消耗要高一个数量级。
在上述压力测试环境下，Nginx官方SWRR和改进的VNSWRR算法的QPS处理能力如下图所示： VNSWRR的QPS处理能力比SWRR算法高出60%左右。
我们来做一个实验。在上游配置的服务器数量发生变化的场景下，对比VNSWRR和SWRR算法，观察Nginx的QPS处理能力和响应时间RT的变化。
从图中可以发现，在SWRR算法下，当上游服务器数量增加500台时，Nginx的QPS处理能力下降约10%，响应RT增加约1ms，而在VNSWRR算法下， Tengine 的QPS 处理能力和RT 基本上没有太大变化。
总结正是在这种大流量的场景下，Nginx的一些问题暴露出来。所谓业务与技术相辅相成。商业可以促进新技术的诞生，并让新技术创造新的商业。 VNSWRR算法不仅具有SWRR算法的平滑性和离散性的特点，而且避免了其缺点。同时，新算法下的时间复杂度也从O(N)调整为O(1)。在大规模场景下，VNSWRR的QPS处理能力相比Nginx官方的SWRR算法提升了60%左右。
好了，本文到此结束，如果可以帮助到大家，还望关注本站哦！
本文采摘于网络，不代表本站立场，转载联系作者并注明出处：https://www.iotsj.com//kuaixun/7965.html
用户评论
感觉名字听起来就很酷啊，轻量级的服务器能更快吗？
有6位网友表示赞同！
一直都在用的nginx，不知道这款新服务器怎么样比较?
有16位网友表示赞同！
阿里出品的产品质量肯定过关，期待这个Tengine!
有8位网友表示赞同！
负载均衡算法很重要吧？这方面技术厉害的不多啊！
有14位网友表示赞同！
想尝试一下Tengine 看看性能怎么样，能不能比现在用的更流畅。
有16位网友表示赞同！
学习一下阿里家的开源Web服务器技术，对开发来说很有帮助.
有18位网友表示赞同！
开源的服务器能自由改造吗？这个很吸引我！
有14位网友表示赞同！
听说这个Tengine特别适合中小企业使用，是真的吗？
有12位网友表示赞同！
阿里在服务器领域做得真是越来越厉害了，佩服!
有16位网友表示赞同！
负载均衡算法太深奥了，能简单解释一下吗？
有15位网友表示赞同！
希望Tengine能够很好地解决我现有的业务问题！
有12位网友表示赞同！
想知道这个服务器的具体功能和优势，有没有详细介绍 ?
有14位网友表示赞同！
阿里家的开源项目都很有价值，期待Tengine能给我们带来更多便捷!
有14位网友表示赞同！
这款轻量级服务器占用资源会不会少？
有16位网友表示赞同！
如果学习使用Tengine需要哪些技能？
有17位网友表示赞同！
服务器这么复杂的系统我很难懂啊，不过还是想了解一下！
有13位网友表示赞同！
阿里开源的软件经常很实用，期待Tengine能得到广泛应用!
有11位网友表示赞同！
是不是 Tengine 可以和其他的程序兼容？
有18位网友表示赞同！
有没有案例介绍，看看其他企业使用Tengine的效果如何?
有5位网友表示赞同！
这个轻量级服务器适合做网站建设吗？
有9位网友表示赞同！