标签：负载 请求 发起 处理 Server1 Server2 Server3 均衡 图解
目录
一.基于权重的随机负载均衡策略
有3台机器，每台机器都有各自的权重，如下如所示：
现在假设用户发起1次调用，请求被Server1处理，下一次请求，请求可能仍然被Server1处理，也可能是Server2或者Server3处理。
只是在大量调用后，总体的规律是，1/6的请求会走到Server1上，2/6的请求会走到Server2上，3/6的请求会走到Server3上。
二.基于轮询的负载均衡策略
这种策略，与每台机器的权重就没有关系了，如下图所示：
在这种策略中，第1次请求被Server1处理，第2次请求被Server2处理，第3次请求被Server3处理，第4次请求被Server1处理，第5次请求被Server2处理，第6次请求被Server3处理....每个节点都会依次接收处理请求。
三.基于权重的轮询负载均衡策略
这种策略，是在轮询策略上增加了权重这个因素，如下图所示：
使用这种策略，会将请求“分组”，以上面这个图为例，因为总权重为600，和各节点约分后，分别占权重1/6，2/6，3/6，那么这个“分组”就是6，也就是说6个请求为一组，Server1会处理其中的1个请求（因为其权重占比为1/6），同理，Server2会处理2个请求，Server3会处理3个请求。
现在假设有2组（也就是12个请求），那么处理过程如下：
1.发起第1次请求，请求被Server1处理；
2.发起第2次请求，请求被Server2处理；
3.发起第3次请求，请求被Server3处理；
4.发起第4次请求，请求被Server2处理，注意，此时不是Server1处理，因为Server1已经处理了1/6的请求；
5.发起第5个请求，请求被Server3处理；
6.发起第6个请求，请求被Server3处理，注意，此时不是Server2处理，因为Server2已经处理2/6的请求；
此时，一组请求已经完成处理（共6个），接着进行第2组的处理。
7.发起第7个请求，请求被Server1处理；
8.发起第8次请求，请求被Server2处理；
9.发起第9次请求，请求被Server3处理；
10.发起第10次请求，请求被Server2处理，注意，此时不是Server1处理，因为Server1已经处理了1/6的请求（1个请求）；
11.发起第11个请求，请求被Server3处理；
12.发起第12个请求，请求被Server3处理，注意，此时不是Server2处理，因为Server2已经处理2/6的请求（2个请求）；
四.基于最少活跃数的轮询负载均衡策略
这里说的“最少活跃数”，是指每个Server正在处理的请求数量。
每个Server维护一个counter计数器，当一个请求被Server处理时，counter加1，当请求被处理完毕，counter减1。
新发起的请求总是被counter最小的Server处理，因为counter最小，从侧面可以推断出请求到达该Server后，会更快的拿到响应结果。
五.基于一致性hash的负载均衡策略
轮询和随机，这两种策略都存在这样一个问题，假设是同一个用户发起的多次请求，按照轮询和随机的规则，这多次请求会被不同Server机器处理。
但有些时候为了让同一用户的请求都被同一个Server处理，一般会根据某个条件进行路由，比如用userId取mod，确定服务器的编号，这样的话，一个用户发起多次请求，请求都将会被同一个机器处理。
上面说的这种方式，是一种简单的取模确定机器，但是存在雪崩的风险，为了避免出现这个风险，所以才有了一致性hash的算法，关于一致性hash算法，这里就不阐述了。
标签：负载,请求,发起,处理,Server1,Server2,Server3,均衡,图解 来源： https://www.cnblogs.com/-beyond/p/13205842.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。