好文阅读-01-后端学习路线

前言

• 说到后端开发，难免会遇到各种所谓高大上的「关键词 」，对于我们应届生小白，难免会觉得比较陌生，因为在学校确实比较少遇见这些所谓高大上的东西，那么今天就带着学习的态度和大家分享这些看似可以装逼可以飞的带逼格的关键词吧。

1. 分布式

在学校里的项目中，一个 Web 系统可能咋们一个人就搞定，因为几乎不考虑并发量，性能咋样，所谓「过得去 」足矣，但是为了面试考虑，我们又不得不找点类似秒杀系统作为我们简历的支撑项目(即使已经烂大街)。那么先问你第一个问题，为什么就采用了分布式的方案落地这个项目？

• 当一个人或者几十个使用你的系统，哎呀我去，请求秒回，效果倍棒，于是乎简历砰砰写上却多么牛X，当面试官就会问你你这项目做了啥，测试过没，并发量如何，性能如何？你就…..

• 当访问系统的用户越来越多，可是我们的系统资源有限，所以需要更多的 CPU 和内存去处理用户的计算请求，当然也就要求更大的网络带宽去处理数据的传输，也需要更多的磁盘空间存储数据。资源不够，消耗过度，服务器崩溃，系统也就不干活了，那么在这样的情况怎么处理？

1.1 垂直伸缩

纵向生长。通过提升单台服务器的计算处理能力来抵抗更大的请求访问量。比如使用更快频率的CPU，更快的网卡，塞更多的磁盘等。其实这样的处理方式在电信，银行等企业比较常见，让摩托车变为小汽车，更强大的计算机，处理能力也就越强，但是对于运维而言也就越来越复杂。那真的就这样花钱买设备就完事了？

• 当然不，单台服务器的计算处理能力是有限的，而且也会严重受到计算机硬件水平的制约。

1.2 水平伸缩

一台机器处理不过来，我就用多台廉价的机器合并同时处理，人多力量大嘛，通过多台服务器构成分布式集群从而提升系统的整体处理能力。这里说到了分布式，那我们看看分布式的成长过程

记住一句话：系统的技术架构是需求所驱动

• 最初的单体系统，只需要部分用户访问，

做系统的原因当然是有需求，有价值，可赚钱。

随着使用系统的用户越来越多，这时候关注的人越来越多，单台服务器扛不住了，关注的人觉得响应真慢，没啥意思，就开始吐槽，但是这一吐槽，导致用户更多，毕竟大家都爱吃瓜。

• 这样下去不得不进行系统的升级，将数据库和应用分离。

这样子，咋们将数据库和应用程序分离后，部署在不同的服务器中，从1台服务器变为多台服务器，处理响应更快，内容也够干，访问的用户呈指数增长，这多台服务器都有点扛不住了，怎么办？

加一个缓存吧，我们不每次从数据库中读取数据，而将应用程序需要的数据暂存在缓冲中。缓存呢，又分为本地缓存和分布式的缓存。分布式缓存，顾名思义，使用多台服务器构成集群，存储更多的数据并提供缓存服务，从而提升缓存的能力。

• 加了缓存哪些好处？

应用程序不再直接访问数据库，提升访问效率。因为缓存内容在内存中，不用每次连接存放磁盘中的数据库，

系统越来越火，于是考虑将应用服务器也作为集群。

2. 缓存架构

干啥啥不行，缓存第一名。不吹牛，缓存应用在计算机的各个角落。缓存可说是软件技术中的的杀手锏，无论是程序代码使用buffer，还是网络架构中使用缓存，虚拟机也会使用大量的缓存。其实最初在CPU中也就开始使用缓存。缓存分为两种，一种是通读缓存，一种是旁路缓存

2.1 通读缓存

• 假设当前应用程序获取数据，如果数据存在于通读缓存中就直接返回。如果不存在于通读缓存，那么就访问数据源，同时将数据存放于缓存中。下次访问就直接从缓存直接获取。比较常见的为CDN和反向代理

CDN

CDN称为内容分发网络。想象我们京东购物的时候，假设我们在成都，如果买的东西在成都仓库有就直接给我们寄送过来，可能半天就到了，用户体验也非常好，就不用从北京再寄过来。同样的道理，用户就可以近距离获得自己需要的数据，既提高了响应速度，又节约了网络带宽和服务器资源。

2.2 旁路缓存

• 应用程序需要自己从数据源读取数据，然后将这个数据写入到旁路缓存中。
• 这样，下次应用程序需要数据的时候，就可以通过旁路缓存直接获得数据了

缓存的好处

• 因为大部分缓存的数据存储在内存中，相比于硬盘或者从网络中获取效率更高，响应时间更快，性能更好
• 通过 CDN 等通读缓存可以降低服务器的负载能力。
• 因为缓存通常会记录计算结果。如果缓存命中直接返回，否则需要进行大量的运算。所以使用缓存也减少了CPU 的计算消耗，加快处理速度

缓存缺点

• 我们缓存的数据来自源数据，如果源数据被修改了，俺么缓存数据很肯能也是被修改过的，成为脏数据，所以怎么办？

• 过期失效

在每次写入缓存数据的时候标记失效时间，读取数据的时候检查数据是否失效，如果失效了就重新从数据源获取数据。、

• 失效通知

应用程序在更新数据源的时候，通知清除缓存中的数据。

是不是数据使用缓存都有意义呢？

• 非也，通常放入缓存中的数据都是带有热点的数据，比如当日热卖商品，或者热门吃瓜新闻，这样将数据存放在缓存中，会被多次读取，从而缓存的命中率也会比较高

3. 异步架构

在前面中，通过缓存实际上很多时候是解决了读的问题，加快了读取数据的能力。因为缓存通常很难保证数据的持久性和一致性，所以我们通常不会将数据直接写入缓存中，而是写入 RDBMAS 等数据中，那如何提升系统的写操作性能呢？

场景：

此时假设两个系统分别为A,B，其中A系统依赖B系统，两者通信采用远程调用的方式，此时如果B系统出故障，很可能引起A系统出故障。

从而不得不单独进行升级，怎么办？

• 使用消息队列的异步架构，也称为事件驱动模型。

异步相对于同步而言，同步通常是当应用程序调用服务的时候，不得不阻塞等待服务期完成，此时CPU空闲比较浪费，直到返回服务结果后才会继续执行。

同步举例子：

举个例子，小蓝今天想在系统中加一个发邮件的功能，通过SMTP和远程服务器通信，但是远程服务器有很多邮件需要等待发送呢，当前邮件就可能等待比较长时间才能发送成功，发送成功后反馈与应用程序。这个过程中，远程服务器发送邮件的时候，应用程序就阻塞，准确的说是执行应用程序的线程阻塞。

这样阻塞带来什么问题“？

• 不能释放占用的系统资源，导致系统资源不足，影响系统性能
• 无法快速给用户响应结果

但是在实际情况中，我们发送邮件，并不需要得到发送结果。比如用户注册，发送账号激活邮件，无论邮件是否发送成功都会收到”返回邮件已经发送，请查收邮件确认激活”，怎样才能让应用程序不阻塞？

此时就比较清晰了，调用者将消息发送给消息队列直接返回，应用程序收到返回以后继续执行，快读响应用户释放资源。有专门的消费队列程序从中消息队列取出数据并进行消费。如果远程服务出现故障，只会传递给消费者程序而不会影响到应用程序。

3.1 消息队列模型

• 消息队列模型中通常有三个角色，分别为生产者，消息队列和消费者。
• 生产者产生数据封装为消息发送给消息队列，专门的消费程序从消息队列中取出数据，消费数据。
• 在我看来，消息队列主要是缓冲消息，等待消费者消费。其中消费的方式分为两种

1. 点对点

对生产者多消费者的情况。一个消息被一个消费者消费

上述的发邮件例子就是典型的点对点模式。互不干扰，其中某个服务出现问题不会印象到全局

2. 订阅模式

开发人员在消息队列中设置主题，生产者往相应的主题发送数据，消费者从对应的主题中消费数据，每个消费者按照自己业务逻辑分别进行计算

这个比较好理解，比如在用户注册的时候，我们将注册信息放入主题用户中，消费者订阅了这个主题，可能有构造短信消息的消费者，也有推广产品的消费者，都可以根据自己业务逻辑进行数据处理。

使用异步模型的优点

• 快速响应

不在需要等待。生产者将数据发送消息队列后，可继续往下执行，不虚等待耗时的消费处理

• 削峰填谷(需要修改)

互联网产品会在不同的场景其并发请求量不同。互联网应用的访问压力随时都在变化，系统的访问高峰和低谷的并发压力可能也有非常大的差距。如果按照压力最大的情况部署服务器集群，那么服务器在绝大部分时间内都处于闲置状态。但利用消息队列，我们可以将需要处理的消息放入消息队列，而消费者可以控制消费速度，因此能够降低系统访问高峰时压力，而在访问低谷的时候还可以继续消费消息队列中
未处理的消息，保持系统的资源利用率

• 降低耦合

如果调用是同步，如果调用是同步的，那么意味着调用者和被调用者必然存在依赖，一方面是代码上的依赖，应用程序需要依赖发送邮件相关的代码，如果需要修改发送邮件的代码，就必须修改应用程序，而且如果要增加新的功能

那么目前主要的消息队列有哪些，其有缺点是什么？(好好记下这个高频题目啦)

4. 负载均衡

一台机器扛不住了，需要多台机器帮忙，既然使用多台机器，就希望不要把压力都给一台机器，所以需要一种或者多种策略分散高并发的计算压力，从而引入负载均衡，那么到底是如何分发到不同的服务器的呢？

1. 砸钱

最初实现负载均衡采取的方案很直接，直接上硬件，当然也就比较贵，互联网的普及，和各位科学家的无私奉献，各个企业开始部署自己的方案，从而出现负载均衡服务器

2. HTTP重定向负载均衡

• 也属于比较直接，当HTTP请求叨叨负载均衡服务器后，使用一套负载均衡算法计算到后端服务器的地址，然后将新的地址给用户浏览器，浏览器收到重定向响应后发送请求到新的应用服务器从而实现负载均衡，如下图所示

优点：

• 简单，如果是java开发工程师，只需要servlet中几句代码即可

缺点：

• 加大请求的工作量。第一次请求给负载均衡服务器，第二次请求给应用服务器
• 因为要先计算到应用服务器的 IP 地址，所以 IP 地址可能暴露在公网，既然暴露在了公网还有什么安全可言

3. DNS负载均衡

了解计算机网络的你应该很清楚如何获取 IP 地址，其中比较常见的就是 DNS 解析获取 IP 地址。用户通过浏览器发起HTTP请求的时候，DNS 通过对域名进行即系得到 IP 地址，用户委托协议栈的 IP 地址简历 HTTP 连接访问真正的服务器。这样不同的用户进行域名解析将会获取不同的IP地址从而实现负载均衡

乍一看，和HTTP重定向的方案不是很相似吗而且还有 DNS 解析这一步骤，也会解析出 IP 地址，不一样的暴露？每次都需要解析吗，当然不，通常本机就会有缓存，在实际的工程项目中通常是怎么样的呢

• 通过 DNS 解析获取负载均衡集群某台服务器的地址
• 负载均衡服务器再一次获取某台应用服务器，这样子就不会将应用服务器的 IP 地址暴露在官网了

4. 反向代理负载均衡

这里典型的就是Nginx提供的反向代理和负载均衡功能。用户的请求直接叨叨反向代理服务器，服务器先看本地是缓存过，有直接返回，没有则发送给后台的应用服务器处理。

5. IP负载均衡

• 注意，这种方案通常属于内核级别，如果数据比较小还好，但是大部分情况是图片等资源文件，这样负载均衡服务器会出现响应或者请求过大所带来的瓶颈

6. 数据链路负载均衡

它可以解决因为数据量太大而导致负载均衡服务器带宽不足这个问题。怎么实现的呢。它不修改数据包的IP地址，而是更改mac地址。应用服务器和负载均衡服务器使用相同的虚拟IP

以上介绍了几种负载均衡的方式，但是很重要的负载均衡算法却没有设计，其中包含了轮询，随机

5. 数据存储

• 公司存在的价值在于流量，流量需要数据，可想而知数据的存储，数据的高可用可说是公司的灵魂。那么改善数据的存储都有哪些手段或方法呢？

1. 数据主从复制

主从复制比较好理解，需要使用两个数据库存储一样的数据。

其原理为当应用程序A发送更新命令到主服务器的时候，数据库会将这条命令同步记录到Binlog中，然后其他线程会从Binlog中读取并通过远程通讯的方式复制到另外服务器。服务器收到这更新日志后加入到自己Relay Log中，

然后SQL执行线程从Relay Log中读取次日志并在本地数据库执行一遍，从而实现主从数据库同样的数据。

• 主从复制可以方便进行读写分离，可以使用一主多从的方式保证高可用，如果从数据库A挂了，可以将读操作迁移到从数据库完成高可用。
• 但是如果主数据库挂了咋搞，那就Mysql的主主复制。可是不管上面说的那种方式都不是提升它的存储能力，这就需要进行数据库的分片了

2. 数据库分片

将一张表分成若干片，其中每一片都包含一部分行记录，然后将每一片存储在不同的服务器中，这样就实现一张表存放在多台服务器中，哪都有哪些分片存储的方案？

• 最开始使用“硬编码”的方式，此方式从字面上可以理解为直接在代码中指定。假定表为用户表，通过ID的奇偶存放在不同的服务器上，如下图

这种方式的缺点很明显，当需要增加服务器的时候，就需要改动代码，这就不友好了。比较常见的数据库分片算法是通过余数Hash算法，根据主键ID和服务器的数量取模，根据余数确定服务器

参考博客 ： https://mp.weixin.qq.com/s/co6ZiALBCUHxc-8SpcKxPw