架构师训练营第五周学习总结

本周的学习进入到技术选型阶段，重点围绕着在分布式系统架构中，如何应对大量的读写的需求，如何做分布式的负载均衡。本周针对读和写分别给出了缓存和队列这两种架构方法，在负载均衡上则提出了一系列的手段。

1.缓存

缓存，本身作为一个通用的概念就是用更高效的存储介质或设备来平滑我们的计算和低速存储（这里的低速是个相对概念）设备，例如我们的CPU缓存。放到我们分布式系统架构中，就是为了让缓存分担数据库的读取数据的压力，因为缓存一般是指在内存中的数据，相比数据库的数据存储在磁盘上，读取效率要高。

放到存储本身上，缓存又分为本地缓存和远程缓存

本地缓存

本地缓存是指我们当前的线程可以通过本地访问在当前主机上的内存缓存数据或客户端程序访问本机缓存的数据。前者通常说的是在我们的代码中把数据库中预先读取出来的数据在内存中缓存可以反复使用，用于一些变化较少或不变的配置项数据；后者通常是一些文件或图片资源，通过从服务器上下载后，在本地缓存期间可以重复使用，用于浏览器加载的js、css和图片等场景，节省从远端服务器下载源文件节省流量和带宽。本地缓存用于小型的单机应用系统中，其缺点是不好做伸缩扩展。

远程缓存

远程缓存是我们当前的线程和需要访问的缓存数据不在一台主机上，需要通过网络请求获取到缓存数据。这是在分布式系统中常用的一种手段，在互联网大型应用中，采用集中式的分布式缓存更利于实现高性能和高可用，我们可以根据缓存的数量做合理的扩容，在集群中也方便做主备高可用。

但是在分布式缓存中会引入一些新的问题，例如如何均衡集群中的负载，如何解决缓存未命中导致雪崩的问题。

于是我们学习了一致性哈希，来应对在集群中调整服务器时，使得原有负载均衡的路由不会出现大规模的数据缓存失效的问题。可以使用缓存预热和对查询的空值做缓存处理，应对缓存低命中导致缓存击穿数据库被拖死的问题。缓存的值设置合理的生命周期，让有限的缓存空间服务更多的请求。这里可以使用LRU算法来处理热点数据缓存。

目前常用的缓存技术一般是Redis和MemCache，相对来说Redis使用的会更多一些，Redis能应对更多的数据类型，在分布式实现上也有一些区别，MemCache是做客户端负载均衡，每个客户端负责计算数据在集群中的哪个服务器，而Redis的集群方法更偏向服务端路由，更利于扩展。

2.队列

队列是在数据写入场景使用的一项技术，把一个长流程的业务，利用流程异步化拆分成多个阶段，每个阶段可以使用消息队列来承接前后，前部分系统只需要负责作为生产者发布消息到消息队列，后部分系统从消息队列中读取消息进行处理。这样的架构设计解决了在多个模块或系统中做同步调用时，线程资源会被占用无法释放，导致在海量并发下，一些耗时的业务会占用大量资源，此外使用消息队列也可以缓解下游系统的负载，消费者按照自己的能力进行消费，而不是全部调用到下游的服务，造成系统拥塞甚至是崩溃。同时消息队列使用订阅-消费模型，当一处发布多处消费时，我们只要增加新的消费者就可以提升消息的处理能力，非常方便进行扩展。

3.负载均衡

这周讨论了非常多关于分布式的技术，其中的一个关键就是如何做到负载均衡。一般分为几类

3.1DNS负载均衡

作为大型互联网应用，用于在地域上分布很广，我们可以设置在多个网络运营商接入的服务中部署我们的服务器，在接入的第一层，我们就可以利用域名解析服务（DNS）把一个域名按照规则解析到不同的IP上，实现第一层的负载均衡，这也是大厂的一般做法。

3.2应用服务负载均衡

在经过了第一层负载均衡之后，请求进入到我们的负载均衡服务器，负载均衡服务器会根据负载均衡策略（轮询、随机或IP哈希等）把消息再次转发到后续的提供真正服务的服务器上。这里也有两种方式，一种是重定向，一种是链路层负载均衡。前者需要发送重定向消息给客户端，让客户端重新请求真正的服务器，而第二种利用虚拟IP，修改目标的mac地址，使得消息可以直接转发到后续的服务器，后续的服务器根据请求报文，直接回复消息给客户端，所以也称三角传输模式。第一种方式会增加请求的延迟，因为使用了两次请求，第二种方式则是一种比较好的选择。



经过本周对于缓存、队列和负载均衡的学习，把对互联网架构中应对高并发时如何解决性能问题，如何做好集群化有了比较清晰的认识，也把过去一些学习的盲点做了很好的补充。