架构师训练营 - 总结 5

1. 缓存相关知识



1.1 缓存的本质　　

缓存的本质就是一个内存Hash表，数据以一对KeyValue键值对存储在内存Hash表中。主要用户存放读写比很高、很少变化的数据，网站数据通常遵循“二八定律”，即80%的访问落在20%的数据上，因此，将这20%的数据缓存起来，可以很好的改善系统性能。 



1.2 合理的使用缓存  

合理的使用缓存对提高系统性能有很多好处，但是不合理的使用缓存反而会成为系统的累赘甚至风险。滥用缓存的三种情况如下：

<1>频繁修改的数据  

数据的读写比至少应该是2:1以上，即写入一次缓存，在数据更新前至少读写两次，缓存才有意义。真正实践中这个比例可能会更高。

<2>没有热点的访问  

如果应用系统访问数据没有热点，不遵循二八定律，即大部分数据访问并没有集中在小部分数据中，那么缓存也没有意义，因为大部分数据还没有被再次访问就已经被挤出缓存了。

<3>数据的不一致与脏读  

写入缓存的数据最好能容忍一定时间的数据不一致，一般情况下最好对缓存的数据设置失效时间(固定值+一定范围的随机值)。如果不能容忍数据的不一致，必须在数据更新时，删除对应的缓存，但是这种情况只针对读写比非常高的情况。 



1.3 缓存的常见问题优化手段

<1>缓存雪崩  

缓存雪崩我们可以简单的理解为：由于原有缓存失效，新缓存未到期间(例如：我们设置缓存时采用了相同的过期时间，在同一时刻出现大面积的缓存过期)，所有原本应该访问缓存的请求都去查询数据库了，而对数据库CPU和内存造成巨大压力，严重的会造成数据库宕机。从而形成一系列连锁反应，造成整个系统崩溃。该类问题的解决方式主要有三种:①加锁排队。大概原理是在去数据库取数据的时候加锁排队，该方法仅仅适用于并发量不高的情况。②在原有失效时间基础上加一个合理的随机值(0-5分钟)。③给缓存加标记，在缓存失效之后更新缓存数据。

<2>缓存穿透  

缓存穿透是指用户查询数据，在数据库没有，自然在缓存中也不会有。这样就导致用户查询的时候，在缓存中找不到，每次都要去数据库再查询一遍，然后返回空（相当于进行了两次无用的查询)。该类问题的主要解决方式。①使用布隆过滤器做过滤。该方法仅仅用于查询一个不可能存在的数据。②把不存在的数据也缓存起来。

<3>缓存预热  

缓存中存放的是热点数据，热点数据又是缓存系统利用某种算法对不断访问的数据筛选淘汰出来的，在重建缓存数据的过程中，系统的性能和数据库负载都不太好，那么最好的方式就是在缓存系统启动的时候就把热点数据加载好，这个缓存预加载的手段叫做缓存预热。对于一些元数据如类目信息，就可以在启动的加载数据库中的全部数据。 



1.4 分布式缓存架构　　

分布式缓存是指缓存部署在多个服务器组成的集群中，以集群方式提供缓存服务，其架构方式有两种：　　①以JBosss Cache为代表的需要更新同步的分布式缓存(在所有服务器中保存相同的缓存数据)。　　

②以Memcache为代表的互不通信的分布式缓存(应用程序通过一致性Hash等路由算法选择缓存服务器远程访问远程数据，可以会容易的扩容，具有良好的可伸缩性)。



2. 消息队列相关知识



2.1 什么是消息队列

消息中间件顾名思义，消息传递的中间技术，用作端对端，点对点，进行通信的技术，目前消息中间件有同步方式和异步方式，异步的方式相对同步方式更加具有容错性，目前主流的消息中间件技术有activeMQ，rabbitMQ，rocketMQ，kafka等。



2.2 什么时候需要消息队列

当系统中出现“生产“和“消费“的速度或稳定性等因素不一致的时候，就需要消息队列，作为抽象层，弥合双方的差异。“ 消息 ”是在两台计算机间传送的数据单位。消息可以非常简单，例如只包含文本字符串；也可以更复杂，可能包含嵌入对象。消息被发送到队列中，“ 消息队列 ”是在消息的传输过程中保存消息的容器 。业务系统触发短信发送申请，但短信发送模块速度跟不上，需要将来不及处理的消息暂存一下，缓冲压力。就可以把短信发送申请丢到消息队列，直接返回用户成功，短信发送模块再可以慢慢去消息队列中取消息进行处理。调远程系统下订单成本较高，且因为网络等因素，不稳定，攒一批一起发送。任务处理类的系统，先把用户发起的任务请求接收过来存到消息队列中，然后后端开启多个应用程序从队列中取任务进行处理。 



2.3 消息队列作用

异步：假设你有一个系统调用链路，是系统A调用系统B，一般耗时20ms；系统B调用系统C，一般耗时200ms；系统C调用系统D，一般耗时2s。用户一个请求过来巨慢无比，因为走完一个链路，需要耗费：2220ms，如果业务流程支持异步化的话，是不是就可以考虑把系统C对系统D的调用抽离出去做成异步化的，不要放在链路中同步依次调用。这样，实现思路就是系统A -> 系统B -> 系统C，直接就耗费220ms后直接成功了。然后系统C就是发送个消息到MQ中间件里，由系统D消费到消息之后慢慢的异步来执行这个耗时2s的业务处理。通过这种方式直接将核心链路的执行性能提升了10倍。



解耦：假设你有个系统A，这个系统A会产出一个核心数据，现在下游有系统B和系统C需要这个数据。那简单，系统A就是直接调用系统B和系统C的接口发送数据给他们就好了。但是现在要是来了系统D、系统E、系统F、系统G，等等，十来个其他系统慢慢的都需要这份核心数据呢？那么负责系统A的就要被烦死了，然后如果要是某个下游系统突然宕机了呢？系统A的调用代码里是不是会抛异常？那系统A的同学会收到报警说异常了，结果他还要去care是下游哪个系统宕机了。所以在实际的系统架构设计中，如果全部采取这种系统耦合的方式，在某些场景下绝对是不合适的，系统耦合度太严重。并且互相耦合起来并不是核心链路的调用，而是一些非核心的场景（比如上述的数据消费）导致了系统耦合，这样会严重的影响上下游系统的开发和维护效率。因此在上述系统架构中，就可以采用MQ中间件来实现系统解耦，系统A就把自己的一份核心数据发到MQ里，下游哪个系统感兴趣自己去消费即可，不需要了就取消数据的消费。



消峰：假设有一个系统，平时正常的时候每秒可能就几百个请求，正常处理都是OK的，在高峰期一下子来了每秒钟几千请求，弹指一挥间出现了流量高峰，此时我们就可以用MQ中间件来进行流量削峰。所有机器前面部署一层MQ，平时每秒几百请求大家都可以轻松接收消息。一旦到了瞬时高峰期，一下涌入每秒几千的请求，就可以积压在MQ里面，然后那一台机器慢慢的处理和消费。等高峰期过了，再消费一段时间，MQ里积压的数据就消费完毕了。这个就是很典型的一个MQ的用法，用有限的机器资源承载高并发请求，如果业务场景允许异步削峰，高峰期积压一些请求在MQ里，然后高峰期过了，后台系统在一定时间内消费完毕不再积压的话，那就很适合用这种技术方案。



2.4 两种模式

<1>点对点：A——消息队列——B/C/D  发送者唯一，B，C，D需主动取，消息一旦被B取出后，消息删除，C，D无法取

<2>发布订阅：A——消息主题——B/C/D  B，C，D监听，A的消息到达topic时，B，C，D同时收到消息



3. 负载均衡相关知识



3.1 什么是负载均衡

服务器负载均衡主要是讲负载请求分散到后端的每个服务器上，克服一台服务器引发的问题，从而达到可伸缩性和容错性。



3.2 负载均衡的算法

<1>. 随机算法

按权重设置随机概率。在一个截面上碰撞的概率高，但调用量越大分布越均匀，而且按概率使用权重后也比较均匀，有利于动态调整提供者权重。



<2>. 轮询及加权轮询

轮询当服务器群中各服务器的处理能力相同时，且每笔业务处理量差异不大时，最适合使用这种算法。 轮循，按公约后的权重设置轮循比率。存在慢的提供者累积请求问题，比如：第二台机器很慢，但没挂，当请求调到第二台时就卡在那，久而久之，所有请求都卡在调到第二台上。加权轮询为轮询中的每台服务器附加一定权重的算法。比如服务器1权重1，服务器2权重2，服务器3权重3，则顺序为1-2-2-3-3-3-1-2-2-3-3-3- ......



<3>. 最小连接及加权最小连接

最少连接在多个服务器中，与处理连接数最少的服务器进行通信的算法。即使在每台服务器处理能力各不相同，每笔业务处理量也不相同的情况下，也能够在一定程度上降低服务器的负载。加权最少连接为最少连接算法中的每台服务器附加权重的算法，该算法事先为每台服务器分配处理连接的数量，并将客户端请求转至连接数最少的服务器上。



<4>. 哈希算法一致性哈希

一致性Hash，相同参数的请求总是发到同一提供者。当某一台提供者挂时，原本发往该提供者的请求，基于虚拟节点，平摊到其它提供者，不会引起剧烈变动。



<5>. IP地址散列

通过管理发送方IP和目的地IP地址的散列，将来自同一发送方的分组(或发送至同一目的地的分组)统一转发到相同服务器的算法。当客户端有一系列业务需要处理而必须和一个服务器反复通信时，该算法能够以流(会话)为单位，保证来自相同客户端的通信能够一直在同一服务器中进行处理。



<6>. URL散列

通过管理客户端请求URL信息的散列，将发送至相同URL的请求转发至同一服务器的算法。



3.3 负载均衡的实现

<1> - DNS域名解析负载

均衡利用DNS处理域名解析请求的同时进行负载均衡是另一种常用的方案。在DNS服务器中配置多个A记录，如：www.mysite.com IN A 114.100.80.1、www.mysite.com IN A 114.100.80.2、www.mysite.com IN A 114.100.80.3.每次域名解析请求都会根据负载均衡算法计算一个不同的IP地址返回，这样A记录中配置的多个服务器就构成一个集群，并可以实现负载均衡。DNS域名解析负载均衡的优点是将负载均衡工作交给DNS，省略掉了网络管理的麻烦，缺点就是DNS可能缓存A记录，不受网站控制。事实上，大型网站总是部分使用DNS域名解析，作为第一级负载均衡手段，然后再在内部做第二级负载均衡。



<2> - 数据链路层负载均衡

数据链路层负载均衡是指在通信协议的数据链路层修改mac地址进行负载均衡。这种数据传输方式又称作三角传输模式，负载均衡数据分发过程中不修改IP地址，只修改目的的mac地址，通过配置真实物理服务器集群所有机器虚拟IP和负载均衡服务器IP地址一样，从而达到负载均衡，这种负载均衡方式又称为直接路由方式, 用户请求到达负载均衡服务器后，负载均衡服务器将请求数据的目的mac地址修改为真是WEB服务器的mac地址，并不修改数据包目标IP地址，因此数据可以正常到达目标WEB服务器，该服务器在处理完数据后可以经过网管服务器而不是负载均衡服务器直接到达用户浏览器。使用三角传输模式的链路层负载均衡是目前大型网站所使用的最广的一种负载均衡手段。在linux平台上最好的链路层负载均衡开源产品是LVS(linux virtual server)。



<3> - IP负载均衡IP负载均衡：

即在网络层通过修改请求目标地址进行负载均衡。用户请求数据包到达负载均衡服务器后，负载均衡服务器在操作系统内核进行获取网络数据包，根据负载均衡算法计算得到一台真实的WEB服务器地址，然后将数据包的IP地址修改为真实的WEB服务器地址，不需要通过用户进程处理。真实的WEB服务器处理完毕后，相应数据包回到负载均衡服务器，负载均衡服务器再将数据包源地址修改为自身的IP地址发送给用户浏览器。这里的关键在于真实WEB服务器相应数据包如何返回给负载均衡服务器，一种是负载均衡服务器在修改目的IP地址的同时修改源地址，将数据包源地址改为自身的IP，即源地址转换（SNAT），另一种方案是将负载均衡服务器同时作为真实物理服务器的网关服务器，这样所有的数据都会到达负载均衡服务器。IP负载均衡在内核进程完成数据分发，较反向代理均衡有更好的处理性能。但由于所有请求响应的数据包都需要经过负载均衡服务器，因此负载均衡的网卡带宽成为系统的瓶颈。



<4> - HTTP重定向负载均衡

HTTP重定向服务器是一台普通的应用服务器，其唯一的功能就是根据用户的HTTP请求计算一台真实的服务器地址，并将真实的服务器地址写入HTTP重定向响应中（响应状态吗302）返回给浏览器，然后浏览器再自动请求真实的服务器。　这种负载均衡方案的优点是比较简单，缺点是浏览器需要每次请求两次服务器才能拿完成一次访问，性能较差；使用HTTP302响应码重定向，可能是搜索引擎判断为SEO作弊，降低搜索排名。重定向服务器自身的处理能力有可能成为瓶颈。因此这种方案在实际使用中并不见多。



<5> - 反向代理负载均衡(nginx)

传统代理服务器位于浏览器一端，代理浏览器将HTTP请求发送到互联网上。而反向代理服务器则位于网站机房一侧，代理网站web服务器接收http请求。　反向代理的作用是保护网站安全，所有互联网的请求都必须经过代理服务器，相当于在web服务器和可能的网络攻击之间建立了一个屏障。　除此之外，代理服务器也可以配置缓存加速web请求。当用户第一次访问静态内容的时候，静态内存就被缓存在反向代理服务器上，这样当其他用户访问该静态内容时，就可以直接从反向代理服务器返回，加速web请求响应速度，减轻web服务器负载压力。　另外，反向代理服务器也可以实现负载均衡的功能。由于反向代理服务器转发请求在HTTP协议层面，因此也叫应用层负载均衡。优点是部署简单，缺点是可能成为系统的瓶颈。