消息队列的五个使用场景

一、简介

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

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

使用较多的消息队列有ActiveMQ，RabbitMQ，RocketMQ，Kafka。

二、消息队列使用场景

以下介绍消息队列在实际应用中常用的使用场景。应用解耦，异步处理，流量削锋、日志处理和消息通讯五个场景。

1、应用解耦

场景说明：像我们公司的统一的管理平台系统，与各种子系统打交道。传统的做法是，各个系统调用平台系统的接口。如下图

平台管理系统发送个数据到下面各个子系统，接口调用发送，那如果其他系统也要这个数据呢？那如果HOUP系统现在不需要了呢？现在平台管理系统又要发送第二种数据了呢？平台管理系统负责人估计会奔溃吧。再来点更加崩溃的事儿，平台管理系统要时时刻刻考虑那些子系统如果挂了咋办？我要不要重发？我要不要把消息存起来？负责人估计跑路的心都有了。。。

传统模式的缺点：

假如平台管理系统无法访问，则所有的子系统读取消息将失败。
平台管理系统与各个子系统耦合。

如何解决以上问题呢？引入应用消息队列后的方案，如下图：

引入消息队列的优点：

平台管理系统完成持久化处理，将消息写入消息队列。
各个子系统：采用拉/推的方式，进行消费消息。
假如子系统挂了不能正常使用了，也不影响用户在平台管理系统的正常业务的操作，因为操作完的数据写入消息队列不再关心后续的其他操作了。实现了平台管理系统与各个子系统的应用解耦。

2、异步处理

场景说明：用户对平台发起了一次请求，平台与各个子系统操作各自的数据库来完成用户的这一次请求。

假设用户的这次请求，平台需要HOUP、CMO和CMC三个子系统交互，从图中看出，不难算出用户的这次请求需要的总耗时是：720ms，可能网络波动的时候，可能达到1s。一般的互联网企业，对用户的直接操作，一般要求是200ms以内完成，对用户几乎是无法感知到的，对于很多产品来说，用户体验是至关重要的。

那如何解决这种性能的问题呢？

引入消息队列，将不是必须的业务逻辑，异步处理。改造后的架构如下：

引入消息队列后，用户把消息写入消息队列后，直接返回，因此用户的响应时间是：25ms，性能提高了好几倍。

3、流量削锋

应用场景：某个时间点高峰期，大量用户涌入系统进行相应的业务操作。

4、日志处理

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

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

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

(3)、Elasticsearch：实时日志分析服务的核心技术，一个schemaless，实时的数据存储服务，通过index组织数据，兼具强大的搜索和统计功能

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

5、消息通讯

消息通讯是指，消息队列一般都内置了高效的通信机制，因此也可以用在纯的消息通讯。比如实现点对点消息队列，或者聊天室等

点对点通讯：

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

聊天室通讯：

客户端A，客户端B，客户端N订阅同一主题，进行消息发布和接收。实现类似聊天室效果。