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

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

这里老师也给了说明。相同角色一组服务器构建的子系统就是集群，集群是分布式系统的子集。分布式系统就是由多个服务器构建的系统，其中的一组或多组服务器扮演的是不同的角色，比如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选举机制，让客户端应用程序对故障转移无感知。