一致性hash分片
来源:互联网 发布:苏州方正软件 编辑:程序博客网 时间:2024/06/04 20:10
一致性hash分片:
执行PartitionByMurmurHash的main方法,按上述假设会得到以下结果
index bucket ratio
0 1001836 0.1001836
1 1038892 0.1038892
2 927886 0.0927886
3 972728 0.0972728
4 1086100 0.10861
5 908616 0.0908616
6 1024269 0.1024269
7 1018029 0.1018029
8 995581 0.0995581
9 1026063 0.1026063
第一列是分片节点的编号,第二列是hash到每个节点的数据量,第三列是每个hash到每个节点的数据量与总数据量的比值。第三列的和是1.0,第十五列的和是10000000。 如果数据量相当少,会发现一致性哈希的分布不够均匀,而只要数据量在10000以上一致性哈希的分布比率就能保持在0.1左右,数据越多分布越均匀,每个节点的数据量越接近。
现在假设增加二个新节点,对0号节点执行rehash,会出现以下结果
index bucket ratio
0 853804 0.8522392886660092
1 1038892 0.1038892
2 927886 0.0927886
3 972728 0.0972728
4 1086100 0.10861
5 908616 0.0908616
6 1024269 0.1024269
7 1018029 0.1018029
8 995581 0.0995581
9 1026063 0.1026063
10 70075 0.06994657808264028
11 77957 0.07781413325135052
第一第二列的意义与上一组列表一样,第三列是hash到当前节点上的数据量与原0号节点总数据量的比值。 从以上列表可以看到,原0号节点有1001836数据,rehash之后大部分数据仍然hash到0号上面,少量数据hash到了10、11号两个新节点,其它旧节点没有得到原来0号上的数据。其实不管增加多少节点,数据的rehash结果都会呈现这个规律:已有节点的数据发生rehash时只有两个可能的去处,要么是rehash之前的节点,要么是新增加的节点,这也是一致性哈希的意义所在。
采用这种该片方式,可以保证数据在rehash时尽可能的少迁移数据。
- 一致性hash分片
- Jedis分片策略-一致性Hash
- redis+twemproxy自动分片(一致性hash)
- MyCat生产实践--一致性hash分片&扩容
- mycat1.6.5分片(一致性hash)
- MyCat生产实践--一致性hash分片&扩容
- jedis分布式之 ShardedJedisPool (一致性Hash分片算法)
- 一致性hash
- 一致性hash
- 一致性hash
- 一致性hash
- 一致性hash
- 一致性hash
- 一致性hash
- 一致性hash
- 一致性hash
- 一致性hash
- 一致性 hash
- 【iOS知识学习】_视图控制对象生命周期-init、viewDidLoad、viewWillAppear、viewDidAppear、viewWillDisappear等的区别及用途
- rsync+inotify 进行数据同步
- 长按tableViewCell弹出复制、黏贴菜单
- android网络通信本质分析
- MongoDB:用户认证
- 一致性hash分片
- openfire asmack java.lang.IllegalStateException: Not connected to server.错误解决办法
- Android系统详解之获取图片和视频的缩略图
- ACM-背包问题Bone Collector&&饭卡
- TCP/IP相关知识复习与总结(https/网络程序性能分析)
- Installing PEAR on OSX
- c/c++ error:GetAdaptersInfo调用失败后重复调用,导致内存溢出
- Spring mvc GET请求中文乱码问题
- android sim卡 TelephonyManager类:Android手机及Sim卡状态的获取