- 浏览: 262395 次
- 性别:
- 来自: 苏州
-
文章分类
- 全部博客 (289)
- java (72)
- oracle (3)
- mysql (5)
- spring (28)
- hibernate (2)
- osgi (0)
- linux (2)
- ExtJs (1)
- jvm (0)
- mybatis (7)
- 分布式 (11)
- MINA (6)
- apache+tomcat (13)
- js+htm (7)
- android (44)
- http (1)
- hbase+hdoop (0)
- memcache (13)
- search (27)
- 部署及性能 (12)
- mongoDB (2)
- 多线程 (12)
- 安全管理验证 (9)
- struts (1)
- webservice (0)
- easyUI (1)
- spring security (16)
- pattern (6)
- 算法 (2)
最新评论
-
lzh8189146:
CommonsHttpSolrServer这个类,现在是不是没 ...
CommonsHttpSolrServer -
xiaochanzi:
我按照你的方法试了下,tomcat6可以发布,但是访问任何网页 ...
基于内嵌Tomcat的应用开发 -
phoneeye:
麻烦你,如果是抄来的文章,请给出来源。谢谢
ant 两则技巧 -
neverforget:
转载不注明出处
Spring Security3.1登陆验证 替换 usernamepasswordfilter -
liang1022:
若不使用eclipse ,如何在命令行下 运行服务端程序 ?
WebService CXF学习(入门篇2):HelloWorld
原文地址:http://www.iteye.com/topic/684087
一致性哈希算法(Consistent Hashing Algorithm)是一种分布式算法,常用于负载均衡。Memcached client也选择这种算法,解决将key-value均匀分配到众多Memcached server上的问题。它可以取代传统的取模操作,解决了取模操作无法应对增删Memcached Server的问题(增删server会导致同一个key,在get操作时分配不到数据真正存储的server,命中率会急剧下降),详细的介绍在这篇帖 子中http://www.iteye.com/topic/611976(后文指代这篇文章的地方均称为引文)。
[下面以Memcached的分布式问题为讨论点,但将Memcached server抽象为节点(Node)]
引文中描述的一致性Hash算法有个潜在的问题是:
将节点hash后会不均匀地分布在环上,这样大量key在寻找节点时,会存在key命中各个节点的概率差别较大,无法实现有效的负载均衡。
如有三个节点Node1,Node2,Node3,分布在环上时三个节点挨的很近,落在环上的key寻找节点时,大量key顺时针总是分配给Node2,而其它两个节点被找到的概率都会很小。
这种问题的解决方案可以有:
改善Hash算法,均匀分配各节点到环上;[引文]使用虚拟节点的思想,为每个物理节点(服务器)在圆上分配100~200个点。这样就能抑制分布不均 匀,最大限度地减小服务器增减时的缓存重新分布。用户数据映射在虚拟节点上,就表示用户数据真正存储位置是在该虚拟节点代表的实际物理服务器上。
在查看Spy Memcached client时,发现它采用一种称为Ketama的Hash算法,以虚拟节点的思想,解决Memcached的分布式问题。
对Ketama的介绍
Here’s how it works:
* Take your list of servers (eg: 1.2.3.4:11211, 5.6.7.8:11211, 9.8.7.6:11211)
* Hash each server string to several (100-200) unsigned ints
* Conceptually, these numbers are placed on a circle called the continuum. (imagine a clock face that goes from 0 to 2^32)
* Each number links to the server it was hashed from, so servers appear at several points on the continuum, by each of the numbers they hashed to.
* To map a key->server, hash your key to a single unsigned int, and find the next biggest number on the continuum. The server linked to that number is the correct server for that key.
* If you hash your key to a value near 2^32 and there are no points on the continuum greater than your hash, return the first server in the continuum.
If you then add or remove a server from the list, only a small proportion of keys end up mapping to different servers.
下面以Spy Memcached中的代码为例来说明这种算法的使用
该client采用TreeMap存储所有节点,模拟一个环形的逻辑关系。在这个环中,节点之前是存在顺序关系的,所以TreeMap的key必须实现Comparator接口。
那节点是怎样放入这个环中的呢?
- //对所有节点,生成nCopies个虚拟结点
- for(Node node : nodes) {
- //每四个虚拟结点为一组,为什么这样?下面会说到
- for(int i=0; i<nCopies / 4; i++) {
- //getKeyForNode方法为这组虚拟结点得到惟一名称
- byte[] digest=HashAlgorithm.computeMd5(getKeyForNode(node, i));
- /** Md5是一个16字节长度的数组,将16字节的数组每四个字节一组,
- 分别对应一个虚拟结点,这就是为什么上面把虚拟结点四个划分一组的原因*/
- for(int h=0;h<4;h++) {
- //对于每四个字节,组成一个long值数值,做为这个虚拟节点的在环中的惟一key
- Long k = ((long)(digest[3+h*4]&0xFF) << 24)
- | ((long)(digest[2+h*4]&0xFF) << 16)
- | ((long)(digest[1+h*4]&0xFF) << 8)
- | (digest[h*4]&0xFF);
- allNodes.put(k, node);
- }
- }
- }
上面的流程大概可以这样归纳:四个虚拟结点为一组,以 getKeyForNode方法得到这组虚拟节点的name,Md5编码后,每个虚拟结点对应Md5码16个字节中的4个,组成一个long型数值,做为 这个虚拟结点在环中的惟一key。第12行k为什么是Long型的呢?呵呵,就是因为Long型实现了Comparator接口。
处理完正式结点在环上的分布后,可以开始key在环上寻找节点的游戏了。
对于每个key还是得完成上面的步骤:计算出Md5,根据Md5的字节数组,通过Kemata Hash算法得到key在这个环中的位置。
- final Node rv;
- byte[] digest = hashAlg.computeMd5(keyValue);
- Long key = hashAlg.hash(digest, 0);
- //如果找到这个节点,直接取节点,返回
- if(!ketamaNodes.containsKey(key)) {
- //得到大于当前key的那个子Map,然后从中取出第一个key,就是大于且离它最近的那个key
- SortedMap<Long, Node> tailMap=ketamaNodes.tailMap(key);
- if(tailMap.isEmpty()) {
- key=ketamaNodes.firstKey();
- } else {
- key=tailMap.firstKey();
- }
- //在JDK1.6中,ceilingKey方法可以返回大于且离它最近的那个key
- //For JDK1.6 version
- // key = ketamaNodes.ceilingKey(key);
- // if (key == null) {
- // key = ketamaNodes.firstKey();
- // }
- }
- rv=allNodes.get(key);
引文中已详细描述过这种取节点逻辑:在环上顺时针查找,如果找到某个节点,就返回那个节点;如果没有找到,则取整个环的第一个节点。
测试结果
测试代码是自己整理的,主体方法没有变
分布平均性测试:测试随机生成的众多key是否会平均分布到各个结点上
测试结果如下:
- Nodes count : 5, Keys count : 100000, Normal percent : 20.0%
- -------------------- boundary ----------------------
- Node name :node1 - Times : 20821 - Percent : 20.821001%
- Node name :node3 - Times : 19018 - Percent : 19.018%
- Node name :node5 - Times : 19726 - Percent : 19.726%
- Node name :node2 - Times : 19919 - Percent : 19.919%
- Node name :node4 - Times : 20516 - Percent : 20.516%
最上面一行是参数说明,节点数目,总共有多少key,每个节点应该分配key的比例是多少。下面是每个结点分配到key的数目和比例。
多次测试后发现,这个Hash算法的节点分布还是不错的,都在标准比例左右徘徊,是个合适的负载均衡算法。
节点增删测试:在环上插入N个结点,每个节点nCopies个虚拟结点。随机生成众多key,在增删节点时,测试同一个key选择相同节点的概率
测试如果如下:
- Normal case : nodes count : 50
- Added case : nodes count : 51
- Reduced case : nodes count : 49
- ------------ boundary -------------
- Same percent in added case : 93.765%
- Same percent in reduced case : 93.845%
上面三行分别是正常情况,节点增加,节点删除情况下的节点数目。下面两行表示在节点增加和删除情况下,同一个key分配在相同节点上的比例(命中率)。
多次测试后发现,命中率与结点数目和增减的节点数量有关。同样增删结点数目情况下,结点多时命中率高。同样节点数目,增删结点越少,命中率越高。这些都与实际情况相符。
发表评论
-
Java keytool 安全证书学习笔记
2012-08-02 14:16 803http://linliangyi2007.iteye.com ... -
java国际化
2012-07-16 14:08 424http://lavasoft.blog.51cto.com/ ... -
Java版远程控制V1.0
2012-06-17 21:37 770http://www.cnblogs.com/syxchina ... -
浅析Java中CountDownLatch用法
2012-05-16 20:57 805CountDownLatch如其所写,是一个 ... -
SMTP发送邮件
2012-04-18 09:41 778SMTP发送邮件 openkk 2011-06-0 ... -
smtp 返回代码 信息
2012-04-18 08:52 1456SMTP Server Response Cod ... -
JavaMail详解
2012-04-18 02:24 0JavaMail详解 博客分类: JAV ... -
安装Eclipse反编译插件
2012-04-17 09:34 807安装Eclipse反编译插件 博客分类: ... -
Java编程中“为了性能”尽量要做到的一些地方
2012-04-13 08:30 671最近的机器内存又爆满了,除了新增机器内存外,还应该好好r ... -
Dijkstra算法
2012-04-11 08:00 876Dijkstra算法 博客分类: 算 ... -
java 播放音乐
2012-04-11 08:00 1007java 播放音乐 博客分类: J2 ... -
Java中的native,transient,volatile和strictfp关键字
2012-04-06 08:49 736Java中的native,transient,v ... -
用ReentrantLock模拟宴会的热闹情景
2012-04-05 08:32 913用ReentrantLock模拟宴会的热闹情景 ... -
Hashmap 分析
2012-04-05 08:32 738Hashmap 博客分类: 算法 ... -
ExecutorService线程池
2012-04-05 08:32 769ExecutorService线程池 (2010 ... -
Java并发:juc Executor框架详解
2012-04-05 08:32 791Java并发:juc Executor ... -
java并发包,多线程,工具类,笔记
2012-04-11 08:00 913JDK 线程池 Executors.newCachedT ... -
利用 Spring 和 EHCache 做方法缓存处理〔转〕
2012-04-09 09:49 855利用 Spring 和 EHCache 做方法缓存处理〔 ... -
EhCache使用详细介绍
2012-04-09 09:49 1354EhCache使用详细介绍 Ehcache中不仅可 ... -
HashMap 分析
2012-04-01 08:21 1908http://www.blogjava.net ...
相关推荐
Ketama一致性哈希算法是基于一致性哈希的一种优化实现,主要解决了传统一致性哈希中节点分布不均匀的问题。在Ketama中,每个实际的物理服务器会被映射到多个虚拟节点,通常是100到200个,这些虚拟节点均匀分布在环上...
一致性哈希算法是一种分布式哈希(Distributed Hash Table, DHT)技术,旨在解决在分布式环境中数据分布不均匀的问题。Ketama算法是基于一致性哈希的一种优化实现,由Last.fm公司的Simon Willison提出,其目标是在...
基于sentinel的redis集群的客户端,支持自动主从切换,采用ketama一致性hash算法哨兵客户端介绍sentinel-client使用Redis做单节点的数据存储,Sentinel做高可用服务的K-V存储集群。 高爾夫方案高可用方案是基于Redis...
一致性哈希(Consistent Hashing)是一种分布式哈希(Distributed Hash Table,DHT)算法,主要用于解决在分布式系统中的数据存储和检索问题。在云计算、缓存系统(如Redis、Memcached)以及负载均衡等领域广泛应用...
1. **Ketama算法**: Ketama算法是一种在分布式环境中平衡负载的算法,特别适用于分布式缓存系统如Redis。它通过使用一致性哈希解决节点动态增减时的数据重新分布问题,以减少因节点变化导致的键映射更改。Ketama通过...
为了解决这个问题,可以采用跳数法(Jump Consistent Hash)或者更高级的一致性哈希变体,如Ketama或libketama。哈希冲突则可以通过开放寻址、链地址法等方法来解决。 此外,一致性哈希算法在分布式缓存如Memcached...
Ketama算法结合了4次MD5哈希结果的不同部分来确定节点的位置,从而避免了“热点”现象,即某些节点接收的数据远多于其他节点。 在负载平衡中,一致性哈希能够确保数据和处理这些数据的服务器之间的映射关系相对稳定...
在这个Java实现中,我们看到的是Ketama一致性哈希算法,这是一种在实践中广泛应用的一致性哈希变体。 Ketama一致性哈希算法由Last.fm的工程师开发,其设计目标是优化分布式哈希表的性能,特别是在处理大量小键值对...
一致性哈希算法是一种分布式哈希(Distributed Hash Table, DHT)技术,它解决了在分布式环境中数据分片和负载均衡的问题。在传统的哈希算法中,如果增加或减少服务器节点,会导致大量数据重新分配,而一致性哈希...
1. **写入端设计**:采用一级Twemproxy架构,一个Twemproxy实例管理多个Redis实例,写入数据通过一致性Hash算法(如fnv1a-64和ketama)分片到不同的Redis节点,确保数据的均匀分布。 2. **读取端设计**:为避免读取...
$memcached->setOption(Memcached::OPT_HASH, Memcached::HASH_KETAMA); ``` **6. 淘宝月光宝盒架构** 淘宝的月光宝盒(MoonBox)是一种优化Memcached集群的方案,它结合了多级缓存、热点数据预热、动态扩缩容和...
解决方案包括如Ketama、Voldemort等一致性Hash实现。 2. 集群时钟同步问题:在分布式系统中,保持所有节点的时钟同步至关重要,因为时间不一致可能导致数据冲突和错误决策。NTP(网络时间协议)是常见的时钟同步...
高铁 英文 |介绍GoSTL是go的数据结构和算法库,旨在提供类似于C++ STL的功能,但功能更强大。 结合go语言的特点,大部分数据结构都实现了goroutine-safe。 创建对象时,可以通过配置参数指定是否开启。功能列表数据...