python面试之分布式

Posted 2023-04-23

参考技术A

主要用于分散压力，所以分布式的服务都是部署在不同的服务器上的，再将服务做集群

根据“分层”的思想进行拆分。
例如，可以将一个项目根据“三层架构” 拆分

然后再分开部署 ：

根据业务进行拆分。
例如，可以根据业务逻辑，将“电商项目”拆分成 “订单项目”、“用户项目”和“秒杀项目” 。显然这三个拆分后的项目，仍然可以作为独立的项目使用。像这种拆分的方法，就成为垂直拆分

主要用于分散能力，主要是将服务的颗粒度尽量细化，且自成一脉，压力这块并不是其关注的点，所以多个微服务是可以部署在同一台服务器上的

微服务可以理解为一种 非常细粒度的垂直拆分 。例如，以上“订单项目”本来就是垂直拆分后的子项目，但实际上“订单项目”还能进一步拆分为“购物项目”、“结算项目”和“售后项目”，如图

现在看图中的“订单项目”，它完全可以作为一个分布式项目的组成元素，但就不适合作为微服务的组成元素了（因为它还能再拆，而微服务应该是不能再拆的“微小”服务，类似于“原子性”）

分布式服务需要提供给别的分布式服务去调用，单独拆出来 未必外部可用
微服务自成一脉，可以系统内部调用，也可以单独提供服务

为什么需要用分布式锁，见下图

变量A存在三个服务器内存中（这个变量A主要体现是在一个类中的一个成员变量，是一个有状态的对象），如果不加任何控制的话，变量A同时都会在分配一块内存，三个请求发过来同时对这个变量操作，显然结果是不对的！即使不是同时发过来，三个请求分别操作三个不同内存区域的数据，变量A之间不存在共享，也不具有可见性，处理的结果也是不对的。

分布式锁应该具备哪些条件：

1、在分布式系统环境下，一个方法在同一时间只能被一个机器的一个线程执行；
2、高可用的获取锁与释放锁；
3、高性能的获取锁与释放锁；
4、具备可重入特性；
5、具备锁失效机制，防止死锁；
6、具备非阻塞锁特性，即没有获取到锁将直接返回获取锁失败

Redis性能高
命令简单，实现方便

使用setnx加锁，key为锁名，value随意不重复就行（一般用uuid）
给锁添加expire时间，超过该时间redis过期（即自动释放锁）
设置获取锁的超时时间，若超过时间，则放弃获取锁

通过锁名获取锁值
比较锁值和当前uuid是否一致，一致则释放锁（通过delete命令删除redis键值对）

2PC：two phase commit protocol，二阶段提交协议，是一种强一致性设计。
同步阻塞（导致长久的资源锁定） ，只有第一阶段全部正常完成（返回失败，回字返回超时都会返回 “准备失败” ），才会进入第二阶段

因为协调者可能会在任意一个时间点（发送准备命令之前，发送准备命令之后，发送回滚事务命令之前，发送回滚事务命令之后，发送提交事务命令之前，发送提交事务命令之后）故障，导致资源阻塞。

T：try，指的是预留，即资源的预留和锁定，注意是预留
C：confirm，指的是确认操作，这一步其实就是真正的执行了
C：cancel，指的是撤销操作，可以理解为把预留阶段的动作撤销了

从思想上看和 2PC 差不多，都是先试探性的执行，如果都可以那就真正的执行，如果不行就回滚。

适用于对实时性要求没那么高的业务场景，如：短信通知

经典面试题之一致性哈希算法

当服务器的数据量和访问量很大的时候，我们可能需要寻找一种解决方案去解决诸如分布式、缓存优化的问题，这也是面试高级或资深服务器开发经常会遇到的问题。

我们先以一个例子来说明为什么要使用一致性哈希算法，这里以著名的开源缓存库memcache来说明：

MemCache是什么

MemCache是一个自由、源码开放、高性能、分布式的分布式内存对象缓存系统，用于动态Web应用以减轻数据库的负载。它通过在内存中缓存数据和对象来减少读取数据库的次数，从而提高了网站访问的速度。MemCaChe是一个存储键值对的HashMap，在内存中对任意的数据（比如字符串、对象等）所使用的key-value存储，数据可以来自数据库调用、API调用，或者页面渲染的结果。MemCache设计理念就是小而强大，它简单的设计促进了快速部署、易于开发并解决面对大规模的数据缓存的许多难题，而所开放的API使得MemCache能用于Java、C/C++/C#、Perl、Python、PHP、Ruby等大部分流行的程序语言。

另外，说一下MemCache和MemCached的区别：

1、MemCache是项目的名称

2、MemCached是MemCache服务器端可以执行文件的名称

MemCache的官方网站为http://memcached.org/

MemCache访问模型

为了加深理解，我模仿着原阿里技术专家李智慧老师《大型网站技术架构 核心原理与案例分析》一书MemCache部分，自己画了一张图：

特别澄清一个问题，MemCache虽然被称为”分布式缓存”，但是MemCache本身完全不具备分布式的功能，MemCache集群之间不会相互通信（与之形成对比的，比如JBoss Cache，某台服务器有缓存数据更新时，会通知集群中其他机器更新缓存或清除缓存数据），所谓的”分布式”，完全依赖于客户端程序的实现，就像上面这张图的流程一样。

同时基于这张图，理一下MemCache一次写缓存的流程：

1、应用程序输入需要写缓存的数据

2、API将Key输入路由算法模块，路由算法根据Key和MemCache集群服务器列表得到一台服务器编号

4、API调用通信模块和指定编号的服务器通信，将数据写入该服务器，完成一次分布式缓存的写操作

读缓存和写缓存一样，只要使用相同的路由算法和服务器列表，只要应用程序查询的是相同的Key，MemCache客户端总是访问相同的客户端去读取数据，只要服务器中还缓存着该数据，就能保证缓存命中。

这种MemCache集群的方式也是从分区容错性的方面考虑的，假如Node2宕机了，那么Node2上面存储的数据都不可用了，此时由于集群中Node0和Node1还存在，下一次请求Node2中存储的Key值的时候，肯定是没有命中的，这时先从数据库中拿到要缓存的数据，然后路由算法模块根据Key值在Node0和Node1中选取一个节点，把对应的数据放进去，这样下一次就又可以走缓存了，这种集群的做法很好，但是缺点是成本比较大。

一致性Hash算法

从上面的图中，可以看出一个很重要的问题，就是对服务器集群的管理，路由算法至关重要，就和负载均衡算法一样，路由算法决定着究竟该访问集群中的哪台服务器，先看一个简单的路由算法。

1、余数Hash

比方说，字符串str对应的HashCode是50、服务器的数目是3，取余数得到1，str对应节点Node1，所以路由算法把str路由到Node1服务器上。由于HashCode随机性比较强，所以使用余数Hash路由算法就可以保证缓存数据在整个MemCache服务器集群中有比较均衡的分布。

如果不考虑服务器集群的伸缩性（什么是伸缩性，请参见大型网站架构学习笔记），那么余数Hash算法几乎可以满足绝大多数的缓存路由需求，但是当分布式缓存集群需要扩容的时候，就难办了。

就假设MemCache服务器集群由3台变为4台吧，更改服务器列表，仍然使用余数Hash，50对4的余数是2，对应Node2，但是str原来是存在Node1上的，这就导致了缓存没有命中。如果这么说不够明白，那么不妨举个例子，原来有HashCode为0~19的20个数据，那么：

HashCode	0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19
路由到的服务器	0	1	2	0	1	2	0	1	2	0	1	2	0	1	2	0	1	2	0	1

现在我扩容到4台，加粗标红的表示命中：

HashCode	0	1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19
路由到的服务器	0	1	2	3	0	1	2	3	0	1	2	3	0	1	2	3	0	1	2	3

如果我扩容到20+的台数，只有前三个HashCode对应的Key是命中的，也就是15%。当然这只是个简单例子，现实情况肯定比这个复杂得多，不过足以说明，使用余数Hash的路由算法，在扩容的时候会造成大量的数据无法正确命中（其实不仅仅是无法命中，那些大量的无法命中的数据还在原缓存中在被移除前占据着内存）。这个结果显然是无法接受的，在网站业务中，大部分的业务数据度操作请求上事实上是通过缓存获取的，只有少量读操作会访问数据库，因此数据库的负载能力是以有缓存为前提而设计的。当大部分被缓存了的数据因为服务器扩容而不能正确读取时，这些数据访问的压力就落在了数据库的身上，这将大大超过数据库的负载能力，严重的可能会导致数据库宕机。

这个问题有解决方案，解决步骤为：

（1）在网站访问量低谷，通常是深夜，技术团队加班，扩容、重启服务器

（2）通过模拟请求的方式逐渐预热缓存，使缓存服务器中的数据重新分布

2、一致性Hash算法

一致性Hash算法通过一个叫做一致性Hash环的数据结构实现Key到缓存服务器的Hash映射，看一下我自己画的一张图：

具体算法过程为：先构造一个长度为232的整数环（这个环被称为一致性Hash环），根据节点名称的Hash值（其分布为[0, 232-1]）将缓存服务器节点放置在这个Hash环上，然后根据需要缓存的数据的Key值计算得到其Hash值（其分布也为[0, 232-1]），然后在Hash环上顺时针查找距离这个Key值的Hash值最近的服务器节点，完成Key到服务器的映射查找。

就如同图上所示，三个Node点分别位于Hash环上的三个位置，然后Key值根据其HashCode，在Hash环上有一个固定位置，位置固定下之后，Key就会顺时针去寻找离它最近的一个Node，把数据存储在这个Node的MemCache服务器中。使用Hash环如果加了一个节点会怎么样，看一下：

一个节点会怎么样，看一下：

看到我加了一个Node4节点，只影响到了一个Key值的数据，本来这个Key值应该是在Node1服务器上的，现在要去Node4了。采用一致性Hash算法，的确也会影响到整个集群，但是影响的只是加粗的那一段而已，相比余数Hash算法影响了远超一半的影响率，这种影响要小得多。更重要的是，集群中缓存服务器节点越多，增加节点带来的影响越小，很好理解。换句话说，随着集群规模的增大，继续命中原有缓存数据的概率会越来越大，虽然仍然有小部分数据缓存在服务器中不能被读到，但是这个比例足够小，即使访问数据库，也不会对数据库造成致命的负载压力。

至于具体应用，这个长度为232的一致性Hash环通常使用二叉查找树实现，至于二叉查找树，就是算法的问题了，可以自己去查询相关资料。

下面我们来具体说说一致性哈希算法的实现原理：

算法的具体原理这里再次贴上：

先构造一个长度为232的整数环（这个环被称为一致性Hash环），根据节点名称的Hash值（其分布为[0, 232-1]）将服务器节点放置在这个Hash环上，然后根据数据的Key值计算得到其Hash值（其分布也为[0, 232-1]），接着在Hash环上顺时针查找距离这个Key值的Hash值最近的服务器节点，完成Key到服务器的映射查找。

这种算法解决了普通余数Hash算法伸缩性差的问题，可以保证在上线、下线服务器的情况下尽量有多的请求命中原来路由到的服务器。

当然，万事不可能十全十美，一致性Hash算法比普通的余数Hash算法更具有伸缩性，但是同时其算法实现也更为复杂，本文就来研究一下，如何利用Java代码实现一致性Hash算法。在开始之前，先对一致性Hash算法中的几个核心问题进行一些探究。

数据结构的选取

一致性Hash算法最先要考虑的一个问题是：构造出一个长度为232的整数环，根据节点名称的Hash值将服务器节点放置在这个Hash环上。

那么，整数环应该使用何种数据结构，才能使得运行时的时间复杂度最低？首先说明一点，关于时间复杂度，常见的时间复杂度与时间效率的关系有如下的经验规则：

O(1) < O(log2N) < O(n) < O(N * log2N) < O(N2) < O(N3) < 2N < 3N < N!

一般来说，前四个效率比较高，中间两个差强人意，后三个比较差（只要N比较大，这个算法就动不了了）。OK，继续前面的话题，应该如何选取数据结构，我认为有以下几种可行的解决方案。

1、解决方案一：排序+List

我想到的第一种思路是：算出所有待加入数据结构的节点名称的Hash值放入一个数组中，然后使用某种排序算法将其从小到大进行排序，最后将排序后的数据放入List中，采用List而不是数组是为了结点的扩展考虑。

之后，待路由的结点，只需要在List中找到第一个Hash值比它大的服务器节点就可以了，比如服务器节点的Hash值是[0,2,4,6,8,10]，带路由的结点是7，只需要找到第一个比7大的整数，也就是8，就是我们最终需要路由过去的服务器节点。

如果暂时不考虑前面的排序，那么这种解决方案的时间复杂度：

（1）最好的情况是第一次就找到，时间复杂度为O(1)

（2）最坏的情况是最后一次才找到，时间复杂度为O(N)

平均下来时间复杂度为O(0.5N+0.5)，忽略首项系数和常数，时间复杂度为O(N)。

但是如果考虑到之前的排序，我在网上找了张图，提供了各种排序算法的时间复杂度：

看得出来，排序算法要么稳定但是时间复杂度高、要么时间复杂度低但不稳定，看起来最好的归并排序法的时间复杂度仍然有O(N * logN)，稍微耗费性能了一些。

2、解决方案二：遍历+List

既然排序操作比较耗性能，那么能不能不排序？可以的，所以进一步的，有了第二种解决方案。

解决方案使用List不变，不过可以采用遍历的方式：

（1）服务器节点不排序，其Hash值全部直接放入一个List中

（2）带路由的节点，算出其Hash值，由于指明了”顺时针”，因此遍历List，比待路由的节点Hash值大的算出差值并记录，比待路由节点Hash值小的忽略

（3）算出所有的差值之后，最小的那个，就是最终需要路由过去的节点

在这个算法中，看一下时间复杂度：

1、最好情况是只有一个服务器节点的Hash值大于带路由结点的Hash值，其时间复杂度是O(N)+O(1)=O(N+1)，忽略常数项，即O(N)

2、最坏情况是所有服务器节点的Hash值都大于带路由结点的Hash值，其时间复杂度是O(N)+O(N)=O(2N)，忽略首项系数，即O(N)

所以，总的时间复杂度就是O(N)。其实算法还能更改进一些：给一个位置变量X，如果新的差值比原差值小，X替换为新的位置，否则X不变。这样遍历就减少了一轮，不过经过改进后的算法时间复杂度仍为O(N)。

总而言之，这个解决方案和解决方案一相比，总体来看，似乎更好了一些。

3、解决方案三：二叉查找树

抛开List这种数据结构，另一种数据结构则是使用二叉查找树。

当然我们不能简单地使用二叉查找树，因为可能出现不平衡的情况。平衡二叉查找树有AVL树、红黑树等，这里使用红黑树，选用红黑树的原因有两点：

1、红黑树主要的作用是用于存储有序的数据，这其实和第一种解决方案的思路又不谋而合了，但是它的效率非常高

2、JDK里面提供了红黑树的代码实现TreeMap和TreeSet

另外，以TreeMap为例，TreeMap本身提供了一个tailMap(K fromKey)方法，支持从红黑树中查找比fromKey大的值的集合，但并不需要遍历整个数据结构。

使用红黑树，可以使得查找的时间复杂度降低为O(logN)，比上面两种解决方案，效率大大提升。

为了验证这个说法，我做了一次测试，从大量数据中查找第一个大于其中间值的那个数据，比如10000数据就找第一个大于5000的数据（模拟平均的情况）。看一下O(N)时间复杂度和O(logN)时间复杂度运行效率的对比：

	50000	100000	500000	1000000	4000000
ArrayList	1ms	1ms	4ms	4ms	5ms
LinkedList	4ms	7ms	11ms	13ms	17ms
TreeMap	0ms	0ms	0ms	0ms	0ms

因为再大就内存溢出了，所以只测试到4000000数据。可以看到，数据查找的效率，TreeMap是完胜的，其实再增大数据测试也是一样的，红黑树的数据结构决定了任何一个大于N的最小数据，它都只需要几次至几十次查找就可以查到。

当然，明确一点，有利必有弊，根据我另外一次测试得到的结论是，为了维护红黑树，数据插入效率TreeMap在三种数据结构里面是最差的，且插入要慢上5~10倍。

Hash值重新计算

服务器节点我们肯定用字符串来表示，比如”192.168.1.1″、”192.168.1.2″，根据字符串得到其Hash值，那么另外一个重要的问题就是Hash值要重新计算，这个问题是我在测试String的hashCode()方法的时候发现的，不妨来看一下为什么要重新计算Hash值：

/**

* String的hashCode()方法运算结果查看

*/

 

public class StringHashCodeTest

{

    public static void main(String[] args)

    {

      System.out.println("192.168.0.0:111的哈希值：" + "192.168.0.0:1111".hashCode());

      System.out.println("192.168.0.1:111的哈希值：" + "192.168.0.1:1111".hashCode());

      System.out.println("192.168.0.2:111的哈希值：" + "192.168.0.2:1111".hashCode());

      System.out.println("192.168.0.3:111的哈希值：" + "192.168.0.3:1111".hashCode());

      System.out.println("192.168.0.4:111的哈希值：" + "192.168.0.4:1111".hashCode());

    }

}

我们在做集群的时候，集群点的IP以这种连续的形式存在是很正常的。看一下运行结果为：

192.168.0.0:111的哈希值：1845870087

192.168.0.1:111的哈希值：1874499238

192.168.0.2:111的哈希值：1903128389

192.168.0.3:111的哈希值：1931757540

192.168.0.4:111的哈希值：1960386691

这个就问题大了，[0,232-1]的区间之中，5个HashCode值却只分布在这么小小的一个区间，什么概念？[0,232-1]中有4294967296个数字，而我们的区间只有122516605，从概率学上讲这将导致97%待路由的服务器都被路由到”192.168.0.1″这个集群点上，简直是糟糕透了！

另外还有一个不好的地方：规定的区间是非负数，String的hashCode()方法却会产生负数（不信用”192.168.1.0:1111″试试看就知道了）。不过这个问题好解决，取绝对值就是一种解决的办法。

综上，String重写的hashCode()方法在一致性Hash算法中没有任何实用价值，得找个算法重新计算HashCode。这种重新计算Hash值的算法有很多，比如CRC32_HASH、FNV1_32_HASH、KETAMA_HASH等，其中KETAMA_HASH是默认的MemCache推荐的一致性Hash算法，用别的Hash算法也可以，比如FNV1_32_HASH算法的计算效率就会高一些。

一致性Hash算法实现版本1：不带虚拟节点

使用一致性Hash算法，尽管增强了系统的伸缩性，但是也有可能导致负载分布不均匀，解决办法就是使用虚拟节点代替真实节点，第一个代码版本，先来个简单的，不带虚拟节点。

下面来看一下不带虚拟节点的一致性Hash算法的Java代码实现：

/**

  * 不带虚拟节点的一致性Hash算法

  *

  */

  public class ConsistentHashingWithoutVirtualNode

  {

     /**

     * 待添加入Hash环的服务器列表

    */

    private static String[] servers = {"192.168.0.0:111", "192.168.0.1:111", "192.168.0.2:111",

            "192.168.0.3:111", "192.168.0.4:111"};

 

    /**

    * key表示服务器的hash值，value表示服务器的名称

    */

    private static SortedMap sortedMap =

            new TreeMap();

 

    /**

    * 程序初始化，将所有的服务器放入sortedMap中

    */

    static

    {

       for (int i = 0; i )

    {

       int hash = getHash(servers[i]);

       System.out.println("[" + servers[i] + "]加入集合中, 其Hash值为" + hash);

       sortedMap.put(hash, servers[i]);

    }

    System.out.println();

  }

 

    /**

    * 使用FNV1_32_HASH算法计算服务器的Hash值,这里不使用重写hashCode的方法，最终效果没区别

    */

    private static int getHash(String str)

    {

          final int p = 16777619;

          int hash = (int)2166136261L;

          for (int i = 0; i )

               hash = (hash ^ str.charAt(i)) * p;

          hash += hash ;

          hash ^= hash >> 7;

          hash += hash ;

          hash ^= hash >> 17;

          hash += hash ;

 

    // 如果算出来的值为负数则取其绝对值

    if (hash )

       hash = Math.abs(hash);

    return hash;

  }

 

    /**

    * 得到应当路由到的结点

    */

    private static String getServer(String node)

    {

     // 得到带路由的结点的Hash值

     int hash = getHash(node);

     // 得到大于该Hash值的所有Map

     SortedMap subMap =

           sortedMap.tailMap(hash);

     // 第一个Key就是顺时针过去离node最近的那个结点

     Integer i = subMap.firstKey();

     // 返回对应的服务器名称

     return subMap.get(i);

  }

 

    public static void main(String[] args)

    {

         String[] nodes = {"127.0.0.1:1111", "221.226.0.1:2222", "10.211.0.1:3333"};

         for (int i = 0; i )

            System.out.println("[" + nodes[i] + "]的hash值为" +

                  getHash(nodes[i]) + ", 被路由到结点[" + getServer(nodes[i]) + "]");

    }

  }

可以运行一下看一下结果：

[192.168.0.0:111]加入集合中,其Hash值为575774686

[192.168.0.1:111]加入集合中,其Hash值为8518713

[192.168.0.2:111]加入集合中,其Hash值为1361847097

[192.168.0.3:111]加入集合中,其Hash值为1171828661

[192.168.0.4:111]加入集合中,其Hash值为1764547046[127.0.0.1:1111]的hash值为380278925,被路由到结点[192.168.0.0:111]

[221.226.0.1:2222]的hash值为1493545632,被路由到结点[192.168.0.4:111]

[10.211.0.1:3333]的hash值为1393836017,被路由到结点[192.168.0.4:111]

看到经过FNV1_32_HASH算法重新计算过后的Hash值，就比原来String的hashCode()方法好多了。从运行结果来看，也没有问题，三个点路由到的都是顺时针离他们Hash值最近的那台服务器上。

使用虚拟节点来改善一致性Hash算法

上面的一致性Hash算法实现，可以在很大程度上解决很多分布式环境下不好的路由算法导致系统伸缩性差的问题，但是会带来另外一个问题：负载不均。

比如说有Hash环上有A、B、C三个服务器节点，分别有100个请求会被路由到相应服务器上。现在在A与B之间增加了一个节点D，这导致了原来会路由到B上的部分节点被路由到了D上，这样A、C上被路由到的请求明显多于B、D上的，原来三个服务器节点上均衡的负载被打破了。某种程度上来说，这失去了负载均衡的意义，因为负载均衡的目的本身就是为了使得目标服务器均分所有的请求。

解决这个问题的办法是引入虚拟节点，其工作原理是：将一个物理节点拆分为多个虚拟节点，并且同一个物理节点的虚拟节点尽量均匀分布在Hash环上。采取这样的方式，就可以有效地解决增加或减少节点时候的负载不均衡的问题。

至于一个物理节点应该拆分为多少虚拟节点，下面可以先看一张图：

横轴表示需要为每台福利服务器扩展的虚拟节点倍数，纵轴表示的是实际物理服务器数。可以看出，物理服务器很少，需要更大的虚拟节点；反之物理服务器比较多，虚拟节点就可以少一些。比如有10台物理服务器，那么差不多需要为每台服务器增加100~200个虚拟节点才可以达到真正的负载均衡。

一致性Hash算法实现版本2：带虚拟节点

在理解了使用虚拟节点来改善一致性Hash算法的理论基础之后，就可以尝试开发代码了。编程方面需要考虑的问题是：

1、一个真实结点如何对应成为多个虚拟节点？

2、虚拟节点找到后如何还原为真实结点？

这两个问题其实有很多解决办法，我这里使用了一种简单的办法，给每个真实结点后面根据虚拟节点加上后缀再取Hash值，比如”192.168.0.0:111″就把它变成”192.168.0.0:111&&VN0″到”192.168.0.0:111&&VN4″，VN就是Virtual Node的缩写，还原的时候只需要从头截取字符串到”&&”的位置就可以了。

下面来看一下带虚拟节点的一致性Hash算法的Java代码实现：

 /**

   * 带虚拟节点的一致性Hash算法

   */

  public class ConsistentHashingWithVirtualNode

  {

      /**

       * 待添加入Hash环的服务器列表

       */

     private static String[] servers = {"192.168.0.0:111", "192.168.0.1:111", "192.168.0.2:111",

             "192.168.0.3:111", "192.168.0.4:111"};

 

     /**

      * 真实结点列表,考虑到服务器上线、下线的场景，即添加、删除的场景会比较频繁，这里使用LinkedList会更好

      */

     private static List realNodes = new LinkedList();

    

     /**

      * 虚拟节点，key表示虚拟节点的hash值，value表示虚拟节点的名称

      */

     private static SortedMap virtualNodes =

             new TreeMap();

 

     /**

      * 虚拟节点的数目，这里写死，为了演示需要，一个真实结点对应5个虚拟节点

      */

     private static final int VIRTUAL_NODES = 5;

 

     static

     {

         // 先把原始的服务器添加到真实结点列表中

         for (int i = 0; i )

             realNodes.add(servers[i]);

 

         // 再添加虚拟节点，遍历LinkedList使用foreach循环效率会比较高

         for (String str : realNodes)

         {

             for (int i = 0; i )

             {

                 String virtualNodeName = str + "&VN" + String.valueOf(i);

                 int hash = getHash(virtualNodeName);

                 System.out.println("虚拟节点[" + virtualNodeName + "]被添加, hash值为" + hash);

                 virtualNodes.put(hash, virtualNodeName);

             }

         }

         System.out.println();

     }

 

     /**

      * 使用FNV1_32_HASH算法计算服务器的Hash值,这里不使用重写hashCode的方法，最终效果没区别

      */

     private static int getHash(String str)

     {

         final int p = 16777619;

         int hash = (int)2166136261L;

         for (int i = 0; i )

             hash = (hash ^ str.charAt(i)) * p;

         hash += hash ;

         hash ^= hash >> 7;

         hash += hash ;

         hash ^= hash >> 17;

         hash += hash ;

 

         // 如果算出来的值为负数则取其绝对值

         if (hash )

             hash = Math.abs(hash);

         return hash;

     }

 

     /**

      * 得到应当路由到的结点

      */

     private static String getServer(String node)

     {

         // 得到带路由的结点的Hash值

         int hash = getHash(node);

         // 得到大于该Hash值的所有Map

         SortedMap subMap =

                 virtualNodes.tailMap(hash);

         // 第一个Key就是顺时针过去离node最近的那个结点

         Integer i = subMap.firstKey();

         // 返回对应的虚拟节点名称，这里字符串稍微截取一下

         String virtualNode = subMap.get(i);

         return virtualNode.substring(0, virtualNode.indexOf("&"));

     }

 

     public static void main(String[] args)

     {

         String[] nodes = {"127.0.0.1:1111", "221.226.0.1:2222", "10.211.0.1:3333"};

         for (int i = 0; i )

             System.out.println("[" + nodes[i] + "]的hash值为" +

                     getHash(nodes[i]) + ", 被路由到结点[" + getServer(nodes[i]) + "]");

     }

}

关注一下运行结果：

虚拟节点[192.168.0.0:111&&VN0]被添加,hash值为1686427075

虚拟节点[192.168.0.0:111&&VN1]被添加,hash值为354859081

虚拟节点[192.168.0.0:111&&VN2]被添加,hash值为1306497370

虚拟节点[192.168.0.0:111&&VN3]被添加,hash值为817889914

虚拟节点[192.168.0.0:111&&VN4]被添加,hash值为396663629

虚拟节点[192.168.0.1:111&&VN0]被添加,hash值为1032739288

虚拟节点[192.168.0.1:111&&VN1]被添加,hash值为707592309

虚拟节点[192.168.0.1:111&&VN2]被添加,hash值为302114528

虚拟节点[192.168.0.1:111&&VN3]被添加,hash值为36526861

虚拟节点[192.168.0.1:111&&VN4]被添加,hash值为848442551

虚拟节点[192.168.0.2:111&&VN0]被添加,hash值为1452694222

虚拟节点[192.168.0.2:111&&VN1]被添加,hash值为2023612840

虚拟节点[192.168.0.2:111&&VN2]被添加,hash值为697907480

虚拟节点[192.168.0.2:111&&VN3]被添加,hash值为790847074

虚拟节点[192.168.0.2:111&&VN4]被添加,hash值为2010506136

虚拟节点[192.168.0.3:111&&VN0]被添加,hash值为891084251

虚拟节点[192.168.0.3:111&&VN1]被添加,hash值为1725031739

虚拟节点[192.168.0.3:111&&VN2]被添加,hash值为1127720370

虚拟节点[192.168.0.3:111&&VN3]被添加,hash值为676720500

虚拟节点[192.168.0.3:111&&VN4]被添加,hash值为2050578780

虚拟节点[192.168.0.4:111&&VN0]被添加,hash值为586921010

虚拟节点[192.168.0.4:111&&VN1]被添加,hash值为184078390

虚拟节点[192.168.0.4:111&&VN2]被添加,hash值为1331645117

虚拟节点[192.168.0.4:111&&VN3]被添加,hash值为918790803

虚拟节点[192.168.0.4:111&&VN4]被添加,hash值为1232193678

 

[127.0.0.1:1111]的hash值为380278925,被路由到结点[192.168.0.0:111]

[221.226.0.1:2222]的hash值为1493545632,被路由到结点[192.168.0.0:111]

[10.211.0.1:3333]的hash值为1393836017,被路由到结点[192.168.0.2:111]

从代码运行结果看，每个点路由到的服务器都是Hash值顺时针离它最近的那个服务器节点，没有任何问题。

通过采取虚拟节点的方法，一个真实结点不再固定在Hash换上的某个点，而是大量地分布在整个Hash环上，这样即使上线、下线服务器，也不会造成整体的负载不均衡。

后记

在写本文的时候，很多知识我也是边写边学，难免有很多写得不好、理解得不透彻的地方，而且代码整体也比较糙，未有考虑到可能的各种情况。抛砖引玉，一方面，写得不对的地方，还望朋友们指正；另一方面，后续我也将通过自己的工作、学习不断完善上面的代码。