Hash一致性算法底层原理
大纲
Hash取余算法
判定哈希算法好坏的四个定义
一致性Hash算法的两大设计
Hash取余算法
hash(Object.key)%N,hash值随Object.key、N的变化而变化。
如果有节点(集群中节点增减太正常)发生变化,几乎重新分配,意味着所有已经分配好的数据都要迁移到新的节点上。
一致性Hash算法提出了在动态变化的Cache环境中,判定哈希算法好坏的四个定义:
1、平衡性(Balance):平衡性是指哈希的结果能够尽可能分布在所有的缓冲(Cache)中去,这样可以使得所有的缓冲空间得到利用。很多哈希算法都能够满足这一条件。
2、单调性(Monotonicity):单调性是指如果已经有一些内容通过哈希分派到了相应的缓冲中,又有新的缓冲加入到系统中。哈希的结果应该能够保证原有已分配的内容可以被映射到原有的或者新的缓冲中去,而不会映射到旧的缓冲集合中的其他缓冲区。
3、分散性(Spread):在分布式环境中,终端有可能看不到所有的缓冲,而只能看到其中的一部分。当终端希望通过哈希过程将内容映射到缓冲上去,由于不同终端所见的缓冲范围有可能不同,从而导致哈希的结果不一致,最终的结果是相同的内容被不同的终端映射到不同的缓冲区中。这种情况显然是应该避免的,因为它导致相同内容被存储到不同缓冲中去,降低了系统存储的效率。分散性的定义就是上述情况发生的严重程度。好的哈希算法应该能够尽量避免不一致的情况发生,也就是尽量降低分散性。
4、负载(Load):负载问题实际上是从另一个角度看待分散性问题。既然不同的终端可能将相同的内容映射到不同的缓冲区中,那么对于一个特定的缓冲区而言,也可能被不同的用户映射到不同的内容。与分散性一样,这种情况也是应当避免的,因此好的哈希算法应能够尽量降低缓冲的负荷。
总结如下:
平衡性——尽量分散
单调性——已经分配的不要换地方
分散性、负载——需要避免
一致性Hash算法的两大设计
1.Hash环(或hash桶)的设计——解决平衡性的问题
这个环的空间非常大,从0~2^32-1,按照相同的hash算法分别计算对象和服务器(一般情况下对机器的hash计算是采用机器的IP或者唯一的别名作为输入值)的hash值,然后以顺时针的方向计算,将所有对象存储到离自己最近的机器中。节点删除或新增也只需要迁移少量离自己距离比较近的数据。
2.虚拟节点的设计——解决单调性的问题
虚拟节点(Virtual node)是实际节点(机器)在hash空间的复制品(replica),一个实际节点对应了若干个“虚拟节点”,这个对应个数也称为“复制个数”,“虚拟节点”在hash空间中以hash值排列。
“虚拟节点”的hash计算可以采用对应节点的IP地址加数字后缀的方式。
https://blog.csdn.net/cb_lcl/article/details/81448570
最新文章
- 【转】在CentOS6.5安装 svn1.8 (亲测可用)
- js中遍历删除数组中的项(项目中遇到的问题解决)
- codeforces 484C Strange Sorting Codeforces Round #276 (Div. 1) C
- CSS3新特性学习
- c#事件机制
- HTML5和CSS3基础教程(第8版)-读书笔记
- GRIDVIEW传值的两种方法
- centos 64位编译安装 glibc-2.14
- TensorFlow Object Detection API(Windows下训练)
- Y2K问题
- Java数据库学习之分页查询
- dpdk之路-环境部署
- 通过一个小故事,理解 HTTPS 工作原理
- 【设计模式】抽象工厂模式(Abstract Factory Pattern)
- @ControllerAdvice详解
- 16.ajax_case02
- BZOJ1023:[SHOI2008]cactus仙人掌图(圆方树,DP,单调队列)
- 00012 - ps命令详解
- [HTML5]如何使用移动设备的方向定位器
- C/C++之全局、static对象/变量的初始化问题