java一致性hash

⑴ java中值相同，hashcode一定相同吗

两者之间唯一的必然关系被你说反了，equls返回为true,则两者的hashcode一定相等，意即相等的对象必须具有相等的哈希码。每当equals方法被覆写，通常需要重写hashCode方法从而
保持对象行为的一致性。而具有相等的hashcode的两个对象equals不一定成立。你可以这样认为也行，hashcode是作为一个对象存储的参考，hash表本身是一种散列表，在数据存储这块，功效比较大，而equals是相当于两对象之间的属性（成员变量）“相等”，意即具有相同的行为（方法）。或许这样讲起来理解比较的费劲。举个例子，比如你定义class A有两个属性，int aA,aB,在定义一个class B也有两个属性，int bA,bB,然后覆写hashcode方法，A类为return aA*aB;B类为return bA*bB.现在情况已经很显然了，各自实例化一个对象:a,b,假如:a.aA=b.bA,a.aB=b.bB,相等，或者a.aA=b.bB,a.aB=b.bA两个对象a,b的hashcode一定相等，当时你能说两个对象相等吗？显然不能吧，a与b都是不同类的实例。连equals最基本的obj instance of A或是obj instance of B都不成立。如果是同一个类的不同对象，当两者拥有相同hashcode的时候，则一定相等，或者equals成立的时候则hashcode一定为真，这也就是所谓的相等的对象具有行为一致性。

⑵ 一致性哈希 java实现 怎么映射到圆环上

一致性哈希提出了在动态变化的Cache环境中，哈希算法应该满足的4个适应条件：单调性是指如果已经有一些内容通过哈希分派到了相应的缓冲中，又有新的缓冲区加入到系统中，那么哈希的结果应能够保证原有已分配的内容可以被映射到新的缓冲区中去，而不会被映射到旧的缓冲集合中的其他缓冲区。（这段翻译信息有负面价值的，当缓冲区大小变化时一致性哈希(Consistenthashing)尽量保护已分配的内容不会被重新映射到新缓冲区。）简单的哈希算法往往不能满足单调性的要求，如最简单的线性哈希：x→ax+bmod(P)在上式中，P表示全部缓冲的大小。不难看出，当缓冲大小发生变化时(从P1到P2)，原来所有的哈希结果均会发生变化，从而不满足单调性的要求。哈希结果的变化意味着当缓冲空间发生变化时，所有的映射关系需要在系统内全部更新。而在P2P系统内，缓冲的变化等价于Peer加入或退出系统，这一情况在P2P系统中会频繁发生，因此会带来极大计算和传输负荷。单调性就是要求哈希算法能够应对这种情况。负载问题实际上是从另一个角度看待分散性问题。既然不同的终端可能将相同的内容映射到不同的缓冲区中，那么对于一个特定的缓冲区而言，也可能被不同的用户映射为不同的内容。与分散性一样，这种情况也是应当避免的，因此好的哈希算法应能够尽量降低缓冲的负荷。从表面上看，一致性哈希针对的是分布式缓冲的问题，但是如果将缓冲看作P2P系统中的Peer，将映射的内容看作各种共享的资源(数据，文件，媒体流等)，就会发现两者实际上是在描述同一问题。路由算法在一致性哈希算法中，每个节点(对应P2P系统中的Peer)都有随机分配的ID。在将内容映射到节点时，使用内容的关键字和节点的ID进行一致性哈希运算并获得键值。一致性哈希要求键值和节点ID处于同一值域。最简单的键值和ID可以是一维的，比如从0000到9999的整数集合。根据键值存储内容时，内容将被存储到具有与其键值最接近的ID的节点上。例如键值为1001的内容，系统中有ID为1000，1010，1100的节点，该内容将被映射到1000节点。为了构建查询所需的路由，一致性哈希要求每个节点存储其上行节点(ID值大于自身的节点中最小的)和下行节点(ID值小于自身的节点中最大的)的位置信息(IP地址)。当节点需要查找内容时，就可以根据内容的键值决定向上行或下行节点发起查询请求。收到查询请求的节点如果发现自己拥有被请求的目标，可以直接向发起查询请求的节点返回确认；如果发现不属于自身的范围，可以转发请求到自己的上行/下行节点。为了维护上述路由信息，在节点加入/退出系统时，相邻的节点必须及时更新路由信息。这就要求节点不仅存储直接相连的下行节点位置信息，还要知道一定深度(n跳)的间接下行节点信息，并且动态地维护节点列表。当节点退出系统时，它的上行节点将尝试直接连接到最近的下行节点，连接成功后，从新的下行节点获得下行节点列表并更新自身的节点列表。同样的，当新的节点加入到系统中时，首先根据自身的ID找到下行节点并获得下行节点列表，然后要求上行节点修改其下行节点列表，这样就恢复了路由关系。

⑶ java去公司工作用到的是哪方面的知识

小公司做小项目一般都用SSH+jsp大公司做项目都是根据不同的项目 采取不同的框架技术,比如银行大部分都用 EJB等

第一：先学习Java的核心库（JavaSE）

JavaSE的内容包括：环境搭建、基础语法、面向对象、数组、集合、常用类、IO流、反射机制、网络编程……..

第二：MySQL数据库

搞定一门数据库相关的课程，例如：MySQL、Oracle，搞定一个就可以了，目前互联网公司，例如：京东、阿里等，他们都在使用MySQL，所以建议大家学习MySQL数据库，小巧轻盈，免费，由于互联网公司的项目访问量比较大，所以一般会搭建数据库的集群，可以一个数据库不够，所以需要搭建数据库集群，为了应付高并发。（搭建的比较多的时候，免费就很重要了。）

第三：WEB前端

以后从事Java开发，从事JavaEE开发，主要开发的系统结构是B/S结构的，B指的是Browser，S指的是Server。要开发这种系统，B端要会，S端也要精通。WEB前端的学习就是学习B端技术。包括：HTML 、CSS、JavaScript（JS）、jQuery框架（底层对JS进行了封装）…

第四：WEB后端（JavaWEB）

WEB后端其实可以是很多种不同的编程语言，例如：PHP、C、C++、Java，他们都可以进行WEB后端的开发，我们既然选择了比较火爆的Java，那么我们学习的后端一定是基于Java语言实现的，包括：Servlet、Filter、Jsp、EL、JSTL、MVC架构模式、数据库连接池（阿里巴巴的Druid连接池）、代理模式（动态代理）。另外后端学习了之后，还要学习一个异步编程技术AJAX。（完成网页的局部刷新，AJAX其实不属于后端，是前端浏览器上的程序。）

学习到这里为止，表示Java基本/基础的技术已经学完了。但是这些最基层的技术在实际的开发中不会使用的，一般为了开发效率，都会使用大量的提前封装好的框架。

第五：最好能够停留下来，做一个项目。

这个项目最好能将之前所学全部串起来。（对以前的知识点进行巩固。）

这个项目最好是基于：Servlet + Jsp+AJAX+jQuery+MySQL….

在这个项目的开发过程中：大家一定要记住，目前比较好的项目自动构建工具：Maven是一定要精通的。还有一个就是团队协作开发：Git/SVN是一定要会用的。（目前使用Git比较多一些。）

第六：学习高级框架

Spring、SpringMVC、MyBatis（持久层框架，这个框架互联网公司使用比较多，因为互联网项目需要进行SQL优化，MyBatis的SQL优化很方便，所以大部分都是使用MyBatis）

Struts2（很少使用了，使用这个的肯定是很老的项目）、Hibernate（传统企业，还有政府等可能会使用Hibernate。）

SpringBoot（新项目大部分使用的都是boot了。所以在项目中遇到还在使用SSM的一般都是遗留项目。）

当你走到这里之后，基本上你可以出山了。（去找工作，8K的薪资应该问题不大，但前提是你学的好。学习的深度够了，广度够了。）

第七：最好能有一个大型项目是使用框架来完成的。

SpringBoot做一个项目。

Spring SpringMVC MyBatis做一个项目。

这个项目最好是找几个人搭伙做一下。体验一下团队协作。（尤其是使用一些协作的工具。怎么沟通，怎么写日报，怎么开会，怎么使用Git，等等….）

第八：如果你的薪资想达到15K的话，你可能需要还要学习一些分布式相关的一些技术。

能够应付高并发的一些技术，例如：分布式框架Dubbo、SpringCloud、MQ、Nginx、Redis…..

java的知识体系构架

....祝 工作顺心 哈哈

⑷ 一致性hash算法是什么

一致性哈希算法是在1997年由麻省理工学院提出的一种分布式哈希（DHT）算法。其设计目标是为了解决因特网中的热点（Hot spot)问题，初衷和CARP十分类似。

一致性Hash是一种特殊的Hash算法，由于其均衡性、持久性的映射特点，被广泛的应用于负载均衡领域，如nginx和memcached都采用了一致性Hash来作为集群负载均衡的方案。

一致性哈希算法的目标是，当K个请求key发起请求时。后台增减节点，只会引起K/N的key发生重新映射。即一致性哈希算法，在后台节点稳定时，同一key的每次请求映射到的节点是一样的。而当后台节点增减时，该算法尽量将K个key映射到与之前相同的节点上。

优点

可扩展性。一致性哈希算法保证了增加或减少服务器时，数据存储的改变最少，相比传统哈希算法大大节省了数据移动的开销。

更好地适应数据的快速增长。采用一致性哈希算法分布数据，当数据不断增长时，部分虚拟节点中可能包含很多数据、造成数据在虚拟节点上分布不均衡，此时可以将包含数据多的虚拟节点分裂，这种分裂仅仅是将原有的虚拟节点一分为二、不需要对全部的数据进行重新哈希和划分。

虚拟节点分裂后，如果物理服务器的负载仍然不均衡，只需在服务器之间调整部分虚拟节点的存储分布。这样可以随数据的增长而动态的扩展物理服务器的数量，且代价远比传统哈希算法重新分布所有数据要小很多。

以上内容参考：网络-一致性哈希

⑸ java hashcode相同，equals一定为真equals为真，hashcode不一定为真

hashcode()和equals(object
o)方法是java所有类的基类object类中的方法，所有类都继承了object类以及其中的方法。equals与hashcode的定义必须一致，即：如果x.equals(y)返回true，那么x.hashcode()就必须与y.hashcode()具有相同的值。当然，对于两个不同的对象，x.hashcode()与y.hashcode()基本不会相同（不排除极少数情况会相同）。
在基类object类中，默认的equals方法是判断两个对象是否具有相同的引用，如果具有相同的引用，那它们必然是相等的。不过这种判断方法并不是一直都通用，比如：有的时候，两辆汽车，只要型号配置相同，就可以认为是相等的，出厂日期可以忽略不计。这种时候就需要在你的类中重写equals方法，对于这个类用你自己的方法来判断两个对象是否相等（重写equals方法就必须重新定义hashcode()方法）。
注：如果对两个对象进行==操作，那么就会自动调用object类默认的equals方法来进行比较。希望能帮到你~

⑹ java中哪些地方实现了一致性hash算法

关于一致性Hash算法，在我之前的博文中已经有多次提到了，MemCache超详细解读一文中"一致性Hash算法"部分，对于为什么要使用一致性Hash算法、一致性Hash算法的算法原理做了详细的解读。

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

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

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

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

⑺ 一致性hash虚拟节点怎么理解

环割法（一致性 hash）环割法的原理如下：

1. 初始化的时候生成分片数量 X × 环割数量 N 的固定方式编号的字符串，例如 SHARD-1-NODE-1，并计算所有 X×N 个字符串的所有 hash 值。

2. 将所有计算出来的 hash 值放到一个排序的 Map 中，并将其中的所有元素进行排序。

3. 输入字符串的时候计算输入字符串的 hash 值，查看 hash 值介于哪两个元素之间，取小于 hash 值的那个元素对应的分片为数据的分片。

数据比较

下面将通过测试对环割法和跳跃法的性能及均衡性进行对比，说明 DBLE 为何使用跳跃法代替了环割法。

• 数据源：现场数据 350595 条

• 测试经过：

  1. 通过各自的测试方法执行对于测试数据的分片任务。

  2. 测试方法：记录分片结果的方差；记录从开始分片至分片结束的时间；记录分片结果与平均数的最大差值。

  3. 由于在求模法 PartitionByString 的方法中要求分片的数量是 1024 的因数，所以测试过程只能使用 2 的指数形式进行测试，并在 PartitionByString 方法进行测试的时候不对于 MAC 地址进行截断，取全量长度进行测试。

⑻ 一致性hash算法，采用哪种算法实现比较好，比如MD5，CRC32，或者其它

环割法（一致性 hash）环割法的原理如下：

1. 初始化的时候生成分片数量 X × 环割数量 N 的固定方式编号的字符串，例如 SHARD-1-NODE-1，并计算所有 X×N 个字符串的所有 hash 值。

2. 将所有计算出来的 hash 值放到一个排序的 Map 中，并将其中的所有元素进行排序。

3. 输入字符串的时候计算输入字符串的 hash 值，查看 hash 值介于哪两个元素之间，取小于 hash 值的那个元素对应的分片为数据的分片。

数据比较

下面将通过测试对环割法和跳跃法的性能及均衡性进行对比，说明 DBLE 为何使用跳跃法代替了环割法。

• 数据源：现场数据 350595 条

• 测试经过：

  1. 通过各自的测试方法执行对于测试数据的分片任务。

  2. 测试方法：记录分片结果的方差；记录从开始分片至分片结束的时间；记录分片结果与平均数的最大差值。

  3. 由于在求模法 PartitionByString 的方法中要求分片的数量是 1024 的因数，所以测试过程只能使用 2 的指数形式进行测试，并在 PartitionByString 方法进行测试的时候不对于 MAC 地址进行截断，取全量长度进行测试。

⑼ java分布式架构有哪些技术

既然是分布式系统，系统间通信的技术就不可避免的要掌握。

首先，我们必须掌握一些基本知识，例如网络通信协议（例如TCP / UDP等），网络IO（Blocking-IO，NonBlocking-IO，Asyn-IO），网卡（多队列等）。 了解有关连接重用，序列化/反序列化，RPC，负载平衡等的信息。

在学习了这些基本知识之后，您基本上可以在分布式系统中编写一个简单的通信模块，但这实际上还远远不够。 现在，您已经进入了分布式字段，您已经对规模有很多要求。 这意味着需要一种通信程序，该程序可以支持大量连接，高并发性和低资源消耗。

大量的连接通常会有两种方式：

大量client连一个server

当前在NonBlocking-IO非常成熟的情况下，支持大量客户端的服务器并不难编写，但是在大规模且通常是长连接的情况下，有一点需要特别注意 ，即服务器挂起时不可能所有客户端都在某个时间点启动重新连接。 那基本上是一场灾难。 我见过一些没有经验的类似案例。 客户端规模扩大后，服务器基本上会在重新启动后立即刷新。 大量传入连接中断（当然，服务器的积压队列首先应设置为稍大一些）。 可以使用的通常方法是在客户端重新连接之前睡眠一段随机的时间。 另外，重连间隔采用避让算法。

一个client连大量的server

有些场景也会出现需要连大量server的现象，在这种情况下，同样要注意的也是不要并发同时去建所有的连接，而是在能力范围内分批去建。

除了建连接外，另外还要注意的地方是并发发送请求也同样，一定要做好限流，否则很容易会因为一些点慢导致内存爆掉。

这些问题在技术风险上得考虑进去，并在设计和代码实现上体现，否则一旦随着规模上去了，问题一时半会还真不太好解。

高并发这个点需要掌握CAS、常见的lock-free算法、读写锁、线程相关知识（例如线程交互、线程池）等，通信层面的高并发在NonBlocking-IO的情况下，最重要的是要注意在整体设计和代码实现上尽量减少对io线程池的时间占用。

低资源消耗这点的话NonBlocking-IO本身基本已经做到。

伸缩性

分布式系统基本上意味着规模不小。 对于此类系统，在设计时必须考虑可伸缩性。 在体系结构图上绘制的任何点，如果请求量或数据量继续增加，该怎么办？ 通过添加机器来解决。 当然，此过程不需要考虑无限的情况。 如果您有经验的建筑师，从相对较小的规模到非常大型的范围，那么优势显然并不小，而且它们也将越来越稀缺。 。

横向可扩展性（Scale Out）是指通过增加服务器数量来提高群集的整体性能。 垂直可伸缩性（Scale Up）是指提高每台服务器的性能以提高集群的整体性能。 纵向可扩展性的上限非常明显，而分布式系统则强调水平可伸缩性。

分布式系统应用服务最好做成无状态的

应用服务的状态是指运行时程序因为处理服务请求而存在内存的数据。分布式应用服务最好是设计成无状态。因为如果应用程序是有状态的，那么一旦服务器宕机就会使得应用服务程序受影响而挂掉，那存在内存的数据也就丢失了，这显然不是高可靠的服务。把应用服务设计成无状态的，让程序把需要保存的数据都保存在专门的存储上(eg. 数据库)，这样应用服务程序可以任意重启而不丢失数据，方便分布式系统在服务器宕机后恢复应用服务。

伸缩性的问题围绕着以下两种场景在解决：

无状态场景

对于无状态场景，要实现随量增长而加机器支撑会比较简单，这种情况下只用解决节点发现的问题，通常只要基于负载均衡就可以搞定，硬件或软件方式都有；

无状态场景通常会把很多状态放在db，当量到一定阶段后会需要引入服务化，去缓解对db连接数太多的情况。

有状态场景

所谓状态其实就是数据，通常采用Sharding来实现伸缩性，Sharding有多种的实现方式，常见的有这么一些：

2.1 规则Sharding

基于一定规则把状态数据进行Sharding，例如分库分表很多时候采用的就是这样的，这种方式支持了伸缩性，但通常也带来了很复杂的管理、状态数据搬迁，甚至业务功能很难实现的问题，例如全局join，跨表事务等。

2.2 一致性Hash

一致性Hash方案会使得加机器代价更低一些，另外就是压力可以更为均衡，例如分布式cache经常采用，和规则Sharding带来的问题基本一样。

2.3 Auto Sharding

Auto Sharding的好处是基本上不用管数据搬迁，而且随着量上涨加机器就OK，但通常Auto Sharding的情况下对如何使用会有比较高的要求，而这个通常也就会造成一些限制，这种方案例如HBase。

2.4 Copy

Copy这种常见于读远多于写的情况，实现起来又会有最终一致的方案和全局一致的方案，最终一致的多数可通过消息机制等，全局一致的例如zookeeper/etcd之类的，既要全局一致又要做到很高的写支撑能力就很难实现了。

即使发展到今天，Sharding方式下的伸缩性问题仍然是很大的挑战，非常不好做。

上面所写的基本都还只是解决的方向，到细节点基本就很容易判断是一个解决过多大规模场景问题的架构师，:)

稳定性

作为分布式系统，必须要考虑清楚整个系统中任何一个点挂掉应该怎么处理（到了一定机器规模，每天挂掉一些机器很正常），同样主要还是分成了无状态和有状态：

无状态场景

对于无状态场景，通常好办，只用节点发现的机制上具备心跳等检测机制就OK，经验上来说无非就是纯粹靠4层的检测对业务不太够，通常得做成7层的，当然，做成7层的就得处理好规模大了后的问题。

有状态场景

对于有状态场景，就比较麻烦了，对数据一致性要求不高的还OK，主备类型的方案基本也可以用，当然，主备方案要做的很好也非常不容易，有各种各样的方案，对于主备方案又觉得不太爽的情况下，例如HBase这样的，就意味着挂掉一台，另外一台接管的话是需要一定时间的，这个对可用性还是有一定影响的；

全局一致类型的场景中，如果一台挂了，就通常意味着得有选举机制来决定其他机器哪台成为主，常见的例如基于paxos的实现。

可维护性

维护性是很容易被遗漏的部分，但对分布式系统来说其实是很重要的部分，例如整个系统环境应该怎么搭建，部署，配套的维护工具、监控点、报警点、问题定位、问题处理策略等等。