pymemcached和xmemcached都实现了一致性哈希算法(其实我是照抄的),这里要测试下在使用一致性哈希的情况下,增加节点,看不同散列函数下命中率和数据分布的变化情况,这个测试结果对于spymemcached和xmemcached是一样的,测试场景:
从一篇英文小说(《黄金罗盘》前三章)进行单词统计,并将最后的统计结果存储到memcached,以单词为key,以次数为value。单词个数为 3061,memcached原来节点数为10,运行在局域网内同一台服务器上的不同端口,在存储统计结果后,增加两个memcached节点(也就是从10个节点增加到12个节点),统计此时的缓存命中率并查看数据的分布情况。
结果如下表格,命中率一行表示增加节点后的命中率情况(增加前为100%),后续的行表示各个节点存储的单词数,CRC32_HASH表示采用CRC32 散列函数,KETAMA_HASH是基于md5的散列函数也是默认情况下一致性哈希的推荐算法,FNV1_32_HASH就是FNV 32位散列函数,NATIVE_HASH就是java.lang.String.hashCode()方法返回的long取32位的结 果,MYSQL_HASH是xmemcached添加的传说来自于mysql源码中的哈希函数。
CRC32_HASH | KETAMA_HASH | FNV1_32_HASH | NATIVE_HASH | MYSQL_HASH | |
---|---|---|---|---|---|
命中率 | 78.5% | 83.3% | 78.2% | 99.89% | 86.9% |
节点1 | 319 | 366 | 546 | 3596 | 271 |
节点2 | 399 | 350 | 191 | 1 | 233 |
节点3 | 413 | 362 | 491 | 0 | 665 |
节点4 | 393 | 364 | 214 | 1 | 42 |
节点5 | 464 | 403 | 427 | 1 | 421 |
节点6 | 472 | 306 | 299 | 0 | 285 |
节点7 | 283 | 347 | 123 | 0 | 635 |
节点8 | 382 | 387 | 257 | 2 | 408 |
节点9 | 238 | 341 | 297 | 0 | 55 |
节点10 | 239 | 375 | 756 | 0 | 586 |
范围 | 200~500 | 300~400 | 150~750 | 0~3600 | 50~650 |
单纯比较下散列函数的计算效率:
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