一致性hash应用到redis
理解分布式存储的本质
有一个经典的实践经验:
数(值)据大了, 什么都是问题!
- 如果要求128B或更大数值计算, 哪么四则运算会是个大问题!
- 如果要求128T或更大日志存储, 哪么文件存储会是个大问题!
- 如果要求128W或更大并发操作, 哪么内存管理会是个大问题!
等等....."墨菲定律", 凡有如果就会发生, Redis缓存数据就是一例! 单机128G内存都无法满足,咋办? 最简单的答案就是大学"数据结构与算法分析"的经常考点:"分而治之"策略. 何谓"分而治之", 就是用餐盒打包饭菜, 一个不够就二个, 二个不够就三个...很少人会去考虑其中蕴含的逻辑哲理.
实现分布式存储的关键
分布式存储的关键:
咋分?
一般都是在三个"方便"中权衡:
- 方便加速读的性能.
- 方便加速写的性能.
- 方便扩展维护,故障恢复.
结合日常需求, 很容易明白这些"方便"的意义.
为了满足上述需求, 很多"聪明人士"抽象了"虚拟结点", 再想出了"二层映射"思路(算法):
- 先将数据主键映射到虚拟(存储)结点.
- 再将虚拟结点映射到物理(存储)结点.
步骤1要求尽可能离散,尽可能均衡, 才能分摊读写的瓶颈. 这涉及"离散空间中的一般均衡理论". 说白了, 就是选择算法实现的优劣.
步骤2要求总够的灵活度, 才能实现扩展维护, 故障恢复. 说白了, 就是自由组合.
基于这种思路的生产算法:
- 一致性HASH算法:
- 数据主键映射到虚拟结点:
HASH(key): unsigned int
结果介于0~2^32-1 (JAVA是-2^16 ~ 2^16-1). 为什么是2^32? 因为32位OS最直接的支持就是unsigned int.
- 虚拟结点映射到物理结点:
switch(HASH(key)){
case (L0, H0]: Node0;
case (L1, H1]: Node1;
...
default: Node0;
}
(Li, Hi]->Nodei是由业务维护的一张映射关系表. 可变!
- ceph的CRUSH算法
- 数据主键映射到虚拟结点:
hash(oid) & mask -> pgid
- 虚拟结点映射到物理结点:
clustermap(pgid) -> osds
一般hash与一致性hash的优劣
一般hash与致性hash都可以实现将数据分布
- 一般hash实现及优劣:
HASH(key)%N
- 优点: 够简单, 我喜欢! 先hash, 再模N.
- 缺点: N变化波及整个离散空间.
- 一致性hash实现及优劣:
switch(HASH(key)){
case (L0, H0]: Node0;
case (L1, H1]: Node1;
...
default: Node0;
}
- 优点:
- 缺点: 计算复杂了点.
相关算法实现
-
数据主键映射到虚拟结点: MD5, MurmurHash.
- MD5是16Byte, 映射到4Byte的int.
- MurmurHash算法：高运算性能，低碰撞率，由Austin Appleby创建于2008年，现已应用到Hadoop、libstdc++、nginx、libmemcached等开源系统。2011年Appleby被Google雇佣，随后Google推出其变种的CityHash算法.
官方网站：https://sites.google.com/site/murmurhash/
-
虚拟结点映射到物理结点: 红黑树
参考资料:http://blog.csdn.net/yuhk231/article/details/51218244
