2万字长文带你细细盘点五种负载均衡策略(11) _负载均衡

可以看到第二次调用的时候并没有进行哈希环的映射操作，而是直接取到了值，进行调用。
加入节点，画图分析最后，我再分析一种情况。在A、B、C三个服务器(20881、20882、20883端口)都在正常运行，哈希映射已经完成的情况下，我们再启动一个D节点（20884端口），这时的日志输出和对应的哈希环变化情况如下:

文章插图

根据日志作图如下：

文章插图

根据输出日志和上图再加上源码，你再细细回味一下。我个人觉得还是讲的非常详细了。
一致性哈希的应用场景当大家谈到一致性哈希算法的时候，首先的第一印象应该是在缓存场景下的使用，因为在一个优秀的哈希算法加持下，其上下线节点对整体数据的影响(迁移)都是比较友好的。
但是想一下为什么 Dubbo 在负载均衡策略里面提供了基于一致性哈希的负载均衡策略？它的实际使用场景是什么？
我最开始也想不明白。我想的是在 Dubbo 的场景下，假设需求是想要一个用户的请求一直让一台服务器处理，那我们可以采用一致性哈希负载均衡策略，把用户号进行哈希计算，可以实现这样的需求。但是这样的需求未免有点太牵强了，适用场景略小。
直到有天晚上，我睡觉之前，电光火石之间突然想到了一个稍微适用的场景了。
如果需求是需要保证某一类请求必须顺序处理呢？
如果你用其他负载均衡策略，请求分发到了不同的机器上去，就很难保证请求的顺序处理了。比如A，B请求要求顺序处理，现在A请求先发送，被负载到了A服务器上，B请求后发送，被负载到了B服务器上。而B服务器由于性能好或者当前没有其他请求或者其他原因极有可能在A服务器还在处理A请求之前就把B请求处理完成了。这样不符合我们的要求。
这时，一致性哈希负载均衡策略就上场了，它帮我们保证了某一类请求都发送到固定的机器上去执行。比如把同一个用户的请求发送到同一台机器上去执行，就意味着把某一类请求发送到同一台机器上去执行。所以我们只需要在该机器上运行的程序中保证顺序执行就行了，比如你加一个队列。
一致性哈希算法+队列，可以实现顺序处理的需求。
好了，一致性哈希负载均衡算法就写到这里。