最后
2020年在匆匆忙忙慌慌乱乱中就这么度过了,我们迎来了新一年,互联网的发展如此之快,技术日新月异,更新迭代成为了这个时代的代名词,坚持下来的技术体系会越来越健壮,JVM作为如今是跳槽大厂必备的技能,如果你还没掌握,更别提之后更新的新技术了。
更多JVM面试整理:
将上述3个Redis节点称之为分片,每一个节点存储部分数据,期间需要使用负载均衡算法,将数据尽量分摊到各个节点,充分发挥分布式的优势,提升系统缓存访问的性能。
在分布缓存领域,对数据存在新增与查询,即数据通过路由算法存储在某一个节点后,查询时需要尽量路由到同一个节点,否则会出现查询未命中缓存的情况,这也是与分布式服务调用领域的负载算法一个不同点。
分布式缓存存储类领域的负载均衡算法通常会使用某一个字段当分片键,在进行负载之前先求出分片字段对应的HashCode,然后与当前的节点数取模。即 hashcode(分片键) % 节点总数(分片总数)。
1.1 在分布式缓存领域上述算法的弊端
先哈希再驱魔实现起来简单高效,但在分布式缓存领域存在一个致命的痛点,对扩容、缩容不友好,会降低缓存的命中率。
因扩容引起的数据命中率问题示意图如下:
例如当前集群中由3个节点存储,例如现在向集群中写入6个数据,其分片键的hashcode为1-6,数据的分布情况如上述所示,但由于随着业务的急剧增长,3台redis已经无法满足业务的需求,项目组决定对其进行扩容,从原先的3台扩容到4台,这个时候项目组尝试去缓存中查找 k1,k2,k3,k4,k5,k6时会出现什么问题?
根据 hashcode 再取模的方式,由于数量从3台到4台,经路由算法路由后,k4 会尝试从3.169的机器去查找,但对应的数据却存储在3.166上,以上面6个key的命中来看,只有50%的命中率,扩容后带来缓存穿透,大量数据进入到后台数据库。
在数据存储领域的第一种解决方案:成倍扩容。将原来的3个节点数量扩充倍,新增加的第一台数据来源于第一台,以此类推,第6台的数据来源于第3台,这样k6经过新的负载均衡算法会落到第6台,数据原本存在于第3台,而第6台的数据来源于第3台,这样避免了缓存穿透。
成倍扩容能有效解决扩容后带来的缓存穿透问题,但这样做会造成资源的浪费,有没有其他更好的方法呢?
一致性哈希算法闪亮登场。
1.2 一致性哈希算法
一致性哈希算法
一致性哈希算法的设计理念如下图所示:
首先将哈希值映射到 0 ~ 2的32次方的一个圆中,然后将实际的物理节点的IP地址或取其hash值,放入到hash环中。
然后对需要插入的数据先求哈希,再顺时针沿着哈希环,找到第一个实际节点,数据将存储到该实际节点上。
扩容后的示例图:
从中可以看到受影响的范围能控制在两个节点的hashcode之间的部分数据,比起先哈希再取模,其未命中率将会得到极大的影响。
但一致性哈希算法要得到较好的效果,取决于各个实体节点在哈希环的分布情况,是否能分散,例如如下分布则会大打折扣:
这种情况会造成数据分布不均衡,为了解决数据很可能分布不均匀的情况,对一致性哈希算法,提出了改进,引入了虚拟节点的,可以设置一个哈希环中存在多少个虚拟节点,然后将虚拟节点映射到实体节点,从而解决数据分布吧均衡的问题。
这样通过为不同的的实际节点映射不同的虚拟节点,实现数据的均匀分布,并且扩容或缩容时并不会出现大面积的缓存穿透。
温馨提示:上述的映射只是一个理想状态,其核心思路是为每一个实体节点创建多个虚拟节点,并且核心虚拟节点的Hash值越分散越好。
大家可以思考一下,如何用JAVA来实现一致性哈希算法?
一致性哈希算法的两个关键:
- 顺时针选择节点
可以使用TreeMap,一来具备排序功能,天然提供了相应的方法获取顺时针的一个元素。
TreeMap 的 ceilingEntry()方法用于返回与大于或等于给定键元素(ele)的最小键元素链接的键值对。
一线互联网大厂Java核心面试题库
正逢面试跳槽季,给大家整理了大厂问到的一些面试真题,由于文章长度限制,只给大家展示了部分题目,更多Java基础、异常、集合、并发编程、JVM、Spring全家桶、MyBatis、Redis、数据库、中间件MQ、Dubbo、Linux、Tomcat、ZooKeeper、Netty等等已整理上传,感兴趣的朋友可以看看支持一波!
4f45ff00ff254613a03fab5e56a57acb)收录**