写点什么

Week5 总结

用户头像
王志祥
关注
发布于: 2020 年 07 月 09 日
Week5总结

一、一致性hash算法总结

互联网架构演化的过程中,为了满足系统的高并发、高性能目标,大量使用各种类型的缓存。老师说的缓存无处不在,细心一想还真是的。现在想想以前只是埋头认真码代码,还是要留出时间多总结归纳,掌握这些技术背后的本质(老师的总结:精辟)。常用的缓存有CDN,反向代理负载均衡,负载均衡,面向对象缓存等等,缓存的最本质的作用是高性能多次读操作。要实现该目标,就要提高缓存的命中率。影响命中率关键参数:缓存键集合大小,缓存可使用内存空间大小,缓存对象生命周期。

缓存存储数据结构基本是KV(键值对),代码中的数据结构是hash表数,实现思路是数组存放值,键hash后取模换算出数组下标,利用数据随机访问的特点可直接取出键对应的值。利用这个可以高效的访问数据了。但是它有一个致命问题就是在水平伸缩时会导致命中率很低。而命中率高才能保证高性能。

因此有了一致性hash算法的出现。它的目标就是大大的降低缓存水平伸缩时缓存数据失效数量,越小越好。一致性hash算法的基本原理,一个圆上从12点钟方向,存放1~2^32-1的hash值,将服务器节点的hash值均匀分布在圆上,缓存的数据key的hash也散落在圆上一个点,从这个点开始顺时针找到的第一个服务器即是缓存数据保存的服务器。如果新增一个服务器节点影响的数据范围也就是新服务器只至逆时针第一个节点的数据。影响的范围定下来后,再想办法降低影响数据量。就又了服务器虚拟节点的点子。本周的作业是实现一致性hash算法,且要测试算法均衡性。目前来说我实现的算法均衡性不性,主要问题就是1~2^32-1 hashcode的问题,会存在负hashcode,就导致负载分布均衡性标准差比较高,希望老师能讲一讲。

如果hashcode能够满控制在1~2^32-1范围内,我认为从理论上来说虚拟节点的一致性hash方案在分布式缓存的均衡性会很好。



二、负载均衡架构方案总结

负载均衡两个目标:

  1. 选择合适的应用服务处理请求,

  2. 2如何高效的转发请求。

按照已有的认知的话只能想到应用层http转发,根据老师的剖析在这一层http转发对负载均衡服务器压力会很大,性能也会比较低。往更底层的IP层和链路层的请求路由来实现负载均衡。

当时听到老师讲解时有醍醐灌顶的感觉,想不到还可以这样玩,厉害啊。感觉还是能够领悟事物的本质,触类旁通,不要限制自己的思维。IP负载均衡已经很好了,老师分析到http请求payload基本都是比较小的,对于相应来说都会比较大,对于负载均衡服务器的带宽压力会比较大,举个例子1mb的图片千兆网卡每秒也就125张。链路层负载均衡就很好的解决了这个问题,请求经过负载均衡服务器由链路层路由给应用服务器,响应直接有应用服务器直接发送给用户,原来负载均衡服务器承载的响应带宽都分摊到应用服务器了,跟集群的作用也就更一致了(负载分摊)。



三、总结

本周的内容收获还是很大的,这是在之前的工作中和学习中都没有去思考过的。过去的工作都是沉浸在代码和业务的细节中,没有去思考这些技术背后的本质,以及它们出现的背景以及解决的什么问题带来了什么问题。真如老师说的我们需要一双能够洞察问题本质的眼睛。



用户头像

王志祥

关注

还未添加个人签名 2017.10.19 加入

还未添加个人简介

评论

发布
暂无评论
Week5总结