消息队列的五种使用场景

场景一：异步处理
场景二：应用解耦
场景三：流量削峰
场景四：日志处理
场景五：消息通讯

消息队列中间件是分布式系统中重要的组件，主要解决应用耦合，异步消息，流量削锋等问题

实现高性能，高可用，可伸缩和最终一致性架构。

使用较多的消息队列有： RocketMQ，RabbitMQ，Kafka，ZeroMQ，MetaMQ

以下介绍消息队列在实际应用中常用的使用场景。

异步处理，应用解耦，流量削锋、日志处理和 消息通讯 五个场景。

场景一：异步处理

场景说明：用户注册后，需要发注册邮件和注册短信。传统的做法有两种

1.串行的方式；

2.并行方式

（1）串行方式：将注册信息写入数据库成功后，发送注册邮件，再发送注册短信。
以上三个任务全部完成后，返回给客户端

（2）并行方式：将注册信息写入数据库成功后，发送注册邮件的同时，发送注册短信（发送短信与发送邮件使用多线程）。
以上三个任务完成后，返回给客户端。
与串行的差别是，并行的方式可以提高处理的时间；

假设三个业务节点每个使用 50 毫秒钟，不考虑网络等其他开销，则串行方式的时间是 150 毫秒，并行的时间可能是 100 毫秒。

因为 CPU 在单位时间内处理的请求数是一定的，假设 CPU1 秒内吞吐量是 100 次。

则串行方式 1 秒内 CPU 可处理的请求量是 7 次（1000/150）。

并行方式处理的请求量是 10 次（1000/100）

引入消息队列，将不是必须的业务逻辑，异步处理。

改造后的架构如下：

按照以上约定，用户的响应时间相当于是注册信息写入数据库的时间，也就是 50 毫秒。

注册邮件，发送短信写入消息队列后，直接返回，因此写入消息队列的速度很快，基本可以忽略，

因此用户的响应时间可能是 50 毫秒。

因此架构改变后，系统的吞吐量提高到每秒 20 QPS。比串行提高了 3 倍，比并行提高了两倍

场景二：应用解耦

场景说明：用户下单后，订单系统需要通知库存系统。传统的做法是，订单系统调用库存系统的接口。

如下图

传统模式的缺点：

假如库存系统无法访问，则订单 减库存 将失败，从而导致订单失败

订单系统与库存系统耦合

订单系统：用户下单后，订单系统完成持久化处理，将消息写入消息队列，返回用户订单下单成功
库存系统：订阅下单的消息，采用拉/推的方式，获取下单信息，库存系统根据下单信息，进行库存操作

假如：在下单时库存系统不能正常使用。也不影响正常下单，因为下单后，订单系统写入消息队列就不再关心其他的后续操作了。
实现订单系统与库存系统的应用解耦

场景三：流量削峰

流量削锋也是消息队列中的常用场景，一般在秒杀或团抢活动中使用广泛

应用场景：秒杀活动，一般会因为流量过大，导致流量暴增，应用挂掉。为解决这个问题，一般需要在应用前端加入消息队列。

1）、可以控制活动的人数；

2）、可以缓解短时间内高流量压垮应用；

用户的请求，服务器接收后，首先写入消息队列。

假如消息队列长度超过最大数量，则直接抛弃用户请求或跳转到错误页面

秒杀业务根据消息队列中的请求信息，再做后续处理

场景四：日志处理

日志处理是指 将消息队列 用在日志处理中，比如 Kafka 的应用，解决大量日志传输的问题。

架构简化如下

日志采集客户端，负责日志数据采集，定时写入 Kafka 队列；
Kafka 消息队列，负责日志数据的接收，存储和转发；
日志处理应用：订阅并消费 kafka 队列中的日志数据；

以下是新浪 kafka 日志处理应用案例

(1)、Kafka：接收用户日志的消息队列

(2)、Logstash：做日志解析，统一成JSON输出给Elasticsearch。

(3)、Elasticsearch：实时日志分析服务的核心技术，一个 schemaless，实时的数据存储服务，通过 index 组织数据，

                          兼具强大的搜索和统计功能；

(4)、Kibana：基于Elasticsearch的数据可视化组件，超强的数据可视化能力是众多公司选择ELK stack的重要原因；

场景五：消息通讯

消息通讯是指，消息队列一般都内置了高效的通信机制，因此也可以用在纯的消息通讯。

比如实现点对点消息队列，或者聊天室等

点对点通讯：

客户端 A 和客户端 B 使用同一队列，进行消息通讯。

聊天室通讯：

客户端 A，客户端 B，客户端 N 订阅同一主题，进行消息发布和接收。

实现类似聊天室效果。

消息中间件使用场景
https://www.jianshu.com/p/3fed7e963a2d

一、消息中间件简介

维基百科给出的消息中间件的定义是 支持在分布式系统中发送和接受消息的硬件或软件基础设施。

消息中间件就是用来解决分布式系统之间消息传递的问题。

二、消息中间件的典型使用场景

1、系统解耦

 首先假设有一个核心系统A，其能产生核心数据供下游服务（系统B和系统C）使用。此时最易想到的办法就是A直接把数据发送给B和C，流程如下。

那么问题来了，此时假设又有D、E、F、G等多个系统也需要使用核心数据，此时流程图如下。

我们可以想象一下，假设有上百个系统都需要系统A的核心数据，此时负责系统A的工程师将是崩溃的，一旦有系统加入，

A系统就需要修改代码，将数据发送到新加入的系统。反之，如果有系统不再需要A发送数据，那么A系统又得修改代码不再向其发送数据。

这样的架构设计耦合度太高了，我们就可以引入消息中间件来实现系统之间的解耦。

即核心系统A生产核心数据，然后将核心数据发送到消息中间件，下游消费系统根据自身需求从中间件里获取消息进行消费，

当不再需要数据时就不取消息进即可，这样系统之间耦合度就大大降低了。

2、异步调用

 假设有一个系统调用链路为A调用B耗时20ms，B调用C耗时20ms，而C调用D需要2s，这样下来整个调用需要耗时2040ms。

  但实际上A调用B，B调用C只需要40ms，而D系统的引入直接导致系统性能下降约50倍。

  此时我们应该考虑将D系统的调用抽离出来，做一个异步调用。

  生活中有一个很形象的例子。

  我们点一杯奶茶，下单、付款、通知商家制作都很快，然而到匹配外卖小哥配送这个过程很慢。

  作为用户来说，匹配外卖小哥这个过程延迟一些时间是可以接受的，只要我能快速下单成功，并且在一定时间范围内安排快递小哥送货即可。

  按照上面的思路，系统A到系统B再到系统C就直接结束了，然后系统C再将消息发送到消息中间件中，系统D从消息中间件里取消息进行消费，

  这样我们系统的性能就提高了接近50倍。

3、削峰填谷

 假设有一个系统，正常时间也就每秒几百个请求，部署在一个8核16G的机器上，运行起来轻松加愉快。然而突然由于搞一个活动，

 高峰期请求数达到了几千，出现了瞬时流量高峰，此时最易想到的是加机器，部署个10台机器，也能扛住此时的高并发。

 那么问题来了，瞬时流量每天也就那么几十分钟，过后就是正常的每秒几百请求，我们如果部署10台机器，那么平均下来每台机器的请求数也就每秒几十次，

  这样是不是有点太浪费资源了呢？大部分时候，每秒几百请求，一台机器就能够扛住了，但是为了抗那每天瞬时的高峰，硬是部署了10台机器，每天就

   那几十分钟有用，别的时候都是浪费资源的。

  但是如果仅仅部署一台机器，瞬间高峰就会击垮系统，因为单台机器是不能扛住每秒几千次请求的。

  这时我们就可以考虑引入消息中间件，进行流量削峰。我们可以部署一层消息队列在机器前面，平时正常的每秒几百次请求，机器就正常的消费消息即可，

 一旦流量高峰到达时，大量消息会堆积在消息队列里面，机器只需要按照自己的最大负荷从消息队列里面消费，等流量高峰过了，  慢慢地队列里面的消息

  也消费完毕了。此时达到了一个削峰填谷的作用。