一、简介
消息队列中间件是分布式系统中重要的组件,主要解决应用耦合,异步消息,流量削锋等问题;
实现高性能,高可用,可伸缩和最终一致性架构;
使用较多的消息队列有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订阅同一主题,进行消息发布和接收。实现类似聊天室效果。