jmind.core.cache.xmemcached

类 MemcachedBuilder

java.lang.Object

jmind.core.cache.xmemcached.MemcachedBuilder

public class MemcachedBuilder
extends java.lang.Object

http://www.blogjava.net/killme2008/archive/2014/02/13/325564.html 构造一个MemcachedClient

作者:

wbxie https://code.google.com/p/xmemcached/wiki/User_Guide_zh http://www.blogjava.net/killme2008/archive/2012/09/11/325564.html http://www.blogjava.net/killme2008/archive/2009/03/10/258838.html 结果如下表格，命中率一行表示增加节点后的命中率情况（增加前为100%），后续的行表示各个节点存储的单词数,CRC32_HASH表示采用CRC32散列函数，KETAMA_HASH是基于md5的散列函数也是默认情况下一致性哈希的推荐算法，FNV1_32_HASH就是FNV 32位散列函数，NATIVE_HASH就是java.lang.String.hashCode()方法返回的long取32位的结果，MYSQL_HASH是xmemcached添加的传说来自于mysql源码中的哈希函数。 1、命中率最高看起来是NATIVE_HASH，然而NATIVE_HASH情况下数据集中存储在第一个节点，显然没有实际使用价值。为什么会集中存储在第一个节点呢？这是由于在查找存储的节点的过程中，会比较hash(key)和hash(节点IP地址)，而在采用了NATIVE_HASH的情况下，所有连接的hash值会呈现一个递增状况（因为String.hashCode是乘法散列函数），如： 192.168.0.100:12000 736402923 192.168.0.100:12001 736402924 192.168.0.100:12002 736402925 192.168.0.100:12003 736402926 如果这些值很大的会，那么单词的hashCode()会通常小于这些值的第一个，那么查找就经常只找到第一个节点并存储数据，当然，这里有测试的局限性，因为memcached都跑在一个台机器上只是端口不同造成了hash(节点IP地址)的连续递增，将分布不均匀的问题放大了。 2、从结果上看，KETAMA_HASH维持了一个最佳平衡，在增加两个节点后还能访问到83.3%的单词，并且数据分布在各个节点上的数目也相对平均，难怪作为默认散列算法。 3、最后，单纯比较下散列函数的计算效率： CRC32_HASH:3266 KETAMA_HASH:7500 FNV1_32_HASH:375 NATIVE_HASH:187 MYSQL_HASH:500 NATIVE_HASH > FNV1_32_HASH > MYSQL_HASH > CRC32_HASH > KETAMA_HASH

构造器概要

构造器

构造器和说明
MemcachedBuilder(jmind.base.lang.IProperties properties, java.lang.String name)

方法概要

限定符和类型	方法和说明
net.rubyeye.xmemcached.MemcachedClient	client()
void	destory() destory memcached clientDelegate

从类继承的方法 java.lang.Object

clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait

构造器详细资料

MemcachedBuilder

public MemcachedBuilder(jmind.base.lang.IProperties properties,
                        java.lang.String name)

方法详细资料

client

public final net.rubyeye.xmemcached.MemcachedClient client()

destory

public final void destory()

destory memcached clientDelegate