架构第五周 - 学习总结

发布于: 2020 年 07 月 05 日
架构第五周 - 学习总结

架构第五周主要内容是分布式缓存、消息队列和异步架构。

总是有面试官问啥实分布式?啥实集群?

这里老师也给了说明。相同角色一组服务器构建的子系统就是集群,集群是分布式系统的子集。分布式系统就是由多个服务器构建的系统,其中的一组或多组服务器扮演的是不同的角色,比如Read、Write、Task、Gateway。

缓存

缓存是介于数据访问者和数据源之间的一种高速存储,当数据需要多次读取的时候,用于加快读取的速度

缓存无处不在,比如:

  • CPU中的缓存

  • OS中的缓存

  • DB中的缓存

  • JVM中的缓存

  • CDN缓存

  • 代理和反向代理缓存

  • 应用程序缓存

  • 分布式对象缓存

可见,缓存绝对不是一种简单的技术手段,而是一种宏观的架构思想。

各种访问介质的访问延迟

各个层次的缓存效率

为什么缓存能够提升性能?

主要降低了网络IO、磁盘IO(内存速度更快)、CPU(不参与中间计算)、DB(不走DB磁盘存取)。

缓存的关键指标

缓存命中率

缓存能否有效依赖于能多少次重用同一个缓存响应业务请求,这个度量指标称为“缓存命中率”。

比如:查询一个缓存,10次中9次能得到一个正确结果,那么缓存命中率就是90%。

影响缓存命中率的主要指标

缓存key集合大小

一定要想办法减少系统中缓存key的总数量,这意味着key数量越少,缓存的效率越高。比如通过ip地址作为key缓存天气数据,跟通过国家缓存天气数据相比。明显缓存国家为key的天气数据生成的总的key数量少。缓存的效率高。唯一key的数量越多,重用的机会越少。唯一key的数量越少,重名的机会就越大。

缓存可用内存空间大小

缓存一般存在于内存中,缓存对象的可用空间受到严格限制且价格昂贵。

物理上来说,能缓存的对象越多,缓存命中率就越高。但是明显不可能存储无限多的对象,当存储空间不够时总得清除老的对象,这样就会造成缓存无法命中,降低命中率。

缓存对象TTL

其实就是说缓存对象的时间越长,缓存对象被重用可能性就越高。缓存对象的生存时间叫做TTL(time to live)。

缓存类型

代理缓存

反向代理缓存

多层反向代理缓存

CDN缓存

对于动态页面请求example.com去直接访问原始服务器,原始服务器返回页面给浏览器,以后每次点击浏览器页面的静态资源时,最终会向CDN发送请求获取静态资源比如图片、音视频文件等。这样就减轻了对原始服务器的请求压力。

不过还有一种方式,就是让CDN不但可以接收静态资源请求,而且可以接收动态资源请求。这就是以下的CDN同时配置静态和动态内容。让CDN自己去分发。

CDN同时配置静态和动态内容

通读缓存(read-through)

通读缓存包括代理缓存、反向代理缓存、CDN缓存,客户端连接到通读缓存之后,有则返回,无则由通读缓存向原始服务器发起查找然后返回给客户端,这个过程客户端并不需要知道原始服务器。

旁路缓存(cache-aside)

客户端可以同时连接原始服务和旁路缓存,旁路缓存是一种对象缓存,通常存储k-v数据。客户端先访问缓存中对象是否存在,存在则返回,不存在则客户端从原始服务器查询到结果,然后set进旁路缓存中以便将来使用。

浏览器对象缓存

浏览器对象比如h5的sessionStorage和localStoreage。

本地对象缓存

比如我们自己在应用程序内部定义的缓存如HashMap等。

本地对象缓存构建的分布式集群

这种方式一般做集群的Session管理,但是这种方式已经被淘汰,因为在集群复制期间不但有延迟,而且增大了网络带宽的压力。

远程分布式对象缓存

一致性hash算法

一般一致性hash算法

带虚拟节点的一致性hash算法

异步架构

  • 基于MQ的异步调用架构好处

① 读性能提升可以使用Cache,比如redis;写性能提升可以使用MQ比如kafka

②更好的伸缩性

③ 故障隔离/解耦

  • 基于事件驱动EDA架构

把生产者消息放入MQ,Consumer订阅相应的主题,相当于消息事件驱动进行逻辑处理。

负载均衡架构

①http重定向负载均衡

http请求先经过负载均衡器拿到服务器地址,然后客户端再次请求服务器地址。

缺点:访问了两次请求,暴露了后端服务器地址,通常不使用。

②DNS负载均衡

客户端首先请求DNS就行域名解析,然后会把域名解析结果放到客户端本地,一般情况下,DNS解析出来的是负载均衡的IP地址,而且不同位置地点解析出的IP可能不一样,大型互联网产品会在各地部署多个负载均衡机器,对应的是各地机房。

缺点:浏览器在负载均衡器出现问题之后不会立马知道,所以请求还是会发给它会有一定时间内的故障持续。

③反向代理负载均衡(7层)

几十台的应用服务器尚可用这种方式,但是再多就不适用,因为在response返回的时候,大量响应经过代理负载均衡器返回,导致性能瓶颈。

④IP负载均衡器(3层,基于IP分发)

在IP层做负载均衡分发的是TCP/IP数据包,一定程度缓解了反向代理负载均衡器的性能瓶颈问题,但是这种负载均衡模式在response的时候依然会经过负载均衡器返回到客户端,压力依然存在。

⑤数据链路层负载均衡(2层,基于mac目标转发)

负载均衡器不再通过修改目标IP来找到应用服务器,二是通过修改数据包中目标mac实现,而IP地址不变。负载均衡器所有的应用服务器共享一个虚拟IP,当数据包通过负载均衡器发出之后,只有集群中目标mac匹配的机器可以收到request包,其他的服务器丢弃包。这种模式下response直接返回给了客户端,不再经过负载均衡器,解决了负载均衡器出口带宽的压力问题。这是主流的大型互联网项目所使用的负载均衡方式。

mark:小企业中由于成本问题不可能找一个专职的运维工程师做这些事情,所以架构师必须全部搞定。如果是大企业则可以考虑招聘专职运维解决此类复杂环境搭建问题。

负载均衡算法

常用的负载均衡算法有轮训、加权轮询、随机、加权随机、最少连接、原地址hash粘滞

分布式DB

以mysql复制为例。mysql复制有一主多从、主主复制。

复制只是为了增加读并发能力,但是并没有增加写并发能力和存储能力,主主复制两个库不能并发写入,Alter Table操作会导致比较大的同步延迟,所以复制要关闭DDL操作,可以通过线下手动逐个执行。主主复制失败转移期间会导致1-2s时间的不可用,这个问题目前没有太好的解决办法。

课堂提问:

在主主复制时IP会进行转换,可以通过IP漂移技术或者ZK选举机制,让客户端应用程序对故障转移无感知。

发布于: 2020 年 07 月 05 日 阅读数: 11
用户头像

Jeff.Smile

关注

努力支撑经历,经历支撑能力! 2018.12.03 加入

追不上BAT的人...

评论

发布
暂无评论
架构第五周 - 学习总结