CSDN|42 张图带你揭秘后端技术都要学啥？( 三 )

本文插图
消息队列的异步模型此时就比较清晰了，调用者将消息发送给消息队列直接返回，应用程序收到返回以后继续执行，快读响应用户释放资源。有专门的消费队列程序从中消息队列取出数据并进行消费。如果远程服务出现故障，只会传递给消费者程序而不会影响到应用程序。
本文插图
消息队列消息队列模型中通常有三个角色，分别为生产者，消息队列和消费者。生产者产生数据封装为消息发送给消息队列，专门的消费程序从消息队列中取出数据，消费数据。在我看来，消息队列主要是缓冲消息，等待消费者消费。其中消费的方式分为两种：

点对点

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

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

订阅模式

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

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

本文插图
用户注册案例使用异步模型的优点

快速响应

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

削峰填谷(需要修改)

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

降低耦合

如果调用是同步，如果调用是同步的，那么意味着调用者和被调用者必然存在依赖，一方面是代码上的依赖，应用程序需要依赖发送邮件相关的代码，如果需要修改发送邮件的代码，就必须修改应用程序，而且如果要增加新的功能那么目前主要的消息队列有哪些，其有缺点是什么？(好好记下这个高频题目啦)
负载均衡一台机器扛不住了，需要多台机器帮忙，既然使用多台机器，就希望不要把压力都给一台机器，所以需要一种或者多种策略分散高并发的计算压力，从而引入负载均衡，那么到底是如何分发到不同的服务器的呢？砸钱最初实现负载均衡采取的方案很直接，直接上硬件，当然也就比较贵，互联网的普及，和各位科学家的无私奉献，各个企业开始部署自己的方案，从而出现负载均衡服务器。 HTTP重定向负载均衡也属于比较直接，当HTTP请求叨叨负载均衡服务器后，使用一套负载均衡算法计算到后端服务器的地址，然后将新的地址给用户浏览器，浏览器收到重定向响应后发送请求到新的应用服务器从而实现负载均衡，如下图所示：