什么是消息队列

消息队列(MQ Message Queue)中间件

消息队列中间件是分布式系统中重要的组件,主要解决应用耦合,异步消息,流量削锋等问题,以及实现高性能,高可用,可伸缩和最终一致性架构,是大型分布式系统不可缺少的中间件。

消息队列在实际应用中常用的四个使用场景:异步处理,应用解耦,流量削锋和消息通讯。

目前在生产环境,使用较多的消息队列有ActiveMQ,RabbitMQ,ZeroMQ,Kafka,MetaMQ,RocketMQ等。

队列:一种先进先出的数据结构

为什么要使用?java里面有很多队列的实现啊??

就像Redis一样,是一个key-value形式存储的数据库,同样 有类似HashMap的数据结构。

消息队列简单的理解:把要传输的数据放在队列里面

  • 把数据放到消息队列叫做生产者
  • 从消息队列里边取数据叫做消费者

为什么要用消息队列?

1.解耦

系统A将userId写到消息队列中,系统C和系统D从消息队列中拿数据。这样有什么好处

  • 系统A只负责把数据写到队列中,谁想要或不想要这个数据(消息),系统A一点都不关心
  • 即便现在系统D不想要userId这个数据了,系统B又突然想要userId这个数据了,都跟系统A无关,系统A一点代码都不用改。
  • 系统D拿userId不再经过系统A,而是从消息队列里边拿。系统D即便挂了或者请求超时,都跟系统A无关,只跟消息队列有关

这样一来,系统A与系统B、C、D都解耦了。

再举个例子,就是有一个订单系统和一个库存系统,由于库存系统挂了,而导致订单系统接收到的订单无法完成,订单接收失败。
有了消息队列之后,订单系统直接就将消息丢给消息队列了,不用再管了。订单成功。

2.异步

把串行的方式转换成并行,比如注册的时候,注册信息写入数据库成功之后,同时发送注册邮件和注册短信,而不像传统的,发完一个再发另一个。而且,这个过程,只需要将信息放入消息队列之后就直接返回,大大减少了时间。

系统A执行完了以后,将userId写到消息队列中,然后就直接返回了(至于其他的操作,则异步处理)。

  • 本来整个请求需要用950ms(同步)
  • 现在将调用其他系统接口异步化,从请求到返回只需要100ms(异步)

3.削峰、限流

系统B和系统C根据自己的能够处理的请求数去消息队列中拿数据,这样即便有每秒有8000个请求,那只是把请求放在消息队列中,去拿消息队列的消息由系统自己去控制,这样就不会把整个系统给搞崩。

流量削峰是消息队列中的常用用户场景,一般在秒杀或团抢活动中使用广泛。
应用场景:秒杀活动,一般会因为流量过大,导致流量暴增,应用挂掉。为解决这个问题,一般需要在应用前端加入消息队列。

  1. 可以控制活动的人数
  2. 可以缓解短时间内高流量压垮应用

用户的请求,服务器接收后,首先写入消息队列。假如消息队列长度超过最大数量,则直接抛弃用户请求或跳转到错误页面。
秒杀业务根据消息队列中的请求信息,再做后续处理。

4.日志处理

日志处理是指将消息队列用在日志处理中,比如Kafka的应用,解决大量日志传输的问题。架构简化如下:
日志采集客户端--写入-->kafka消息队列<--订阅消费--日志处理应用

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

新浪kafka日志处理应用:

Kafka:接收用户日志的消息队列。
Logstash:做日志解析,统一成JSON输出给Elasticsearch。
Elasticsearch:实时日志分析服务的核心技术,一个schemaless,实时的数据存储服务,通过index组织数据,兼具强大的搜索和统计功能。
Kibana:基于Elasticsearch的数据可视化组件,超强的数据可视化能力是众多公司选择ELK stack的重要原因。

5.消息通讯

消息通讯是指,消息队列一般都内置了高效的通信机制,因此也可以用在纯的消息通讯。比如实现点对点消息队列,或者聊天室等。
点对点通讯:
客户端A:--发送消息-->消息队列<--客户端B
聊天室通讯:
客户端<---发送/接收消息---->消息队列<----发送/接收消息---->

JDK实现的队列种类虽然有很多种,但是都是简单的内存队列。为什么我说JDK是简单的内存队列呢?下面我们来看看要实现消息队列(中间件)可能要考虑什么问题

1.高可用

当我们项目中使用消息队列,都是得集群/分布式的。要做集群/分布式就必然希望该消息队列能够提供现成的支持,而不是自己写代码手动去实现。

2.数据丢失问题

我们将数据写到消息队列上,系统B和C还没来得及取消息队列的数据,就挂掉了。如果没有做任何的措施,我们的数据就丢了

学过Redis的都知道,Redis可以将数据持久化磁盘上,万一Redis挂了,还能从磁盘从将数据恢复过来。同样地,消息队列中的数据也需要存在别的地方,这样才尽可能减少数据的丢失。

那存在哪呢?

  • 磁盘?
  • 数据库?
  • Redis?
  • 分布式文件系统?

同步存储还是异步存储?

3.消费者怎么得到消息队列的数据

消费者怎么从消息队列里边得到数据?有两种办法:

  • 生产者将数据放到消息队列中,消息队列有数据了,主动叫消费者去拿(俗称push)
  • 消费者不断去轮训消息队列,看看有没有新的数据,如果有就消费(俗称pull)

4.其他

除了这些,我们在使用的时候还得考虑各种的问题:

  • 消息重复消费了怎么办啊?
  • 我想保证消息是绝对有顺序的怎么做?
  • ……..

虽然消息队列给我们带来了那么多的好处,但同时我们发现引入消息队列也会提高系统的复杂性。市面上现在已经有不少消息队列轮子了,每种消息队列都有自己的特点,选取哪种MQ还得好好斟酌

消息中间件示例

1.电商系统

消息队列采用高可用,可持久化的消息中间件。比如ActiveMQ,RabbitMQ,RocketMQ。
(1)应用将主干逻辑处理完成后,写入消息队列。消息发送是否成功可以开启消息的确认模式。(消息队列返回消息接收成功状态后,应用再返回,这样保障消息的完整性)
(2)扩展流程(发短信,配送处理)订阅队列消息。采用推或拉的方式获取消息并处理。
(3)消息将应用解耦的同时,带来了数据一致性问题,可以采用最终一致性方式解决。比如主数据写入数据库,扩展应用根据消息队列,并结合数据库方式实现基于消息队列的后续处理。

2.日志收集系统
分为Zookeeper注册中心,日志收集客户端,Kafka集群和Storm集群(OtherApp)四部分组成。

Zookeeper注册中心,提出负载均衡和地址查找服务;
日志收集客户端,用于采集应用系统的日志,并将数据推送到kafka队列;
Kafka集群:接收,路由,存储,转发等消息处理;
Storm集群:与OtherApp处于同一级别,采用拉的方式消费队列中的数据;

本文链接:

https://heyzen.club/index.php/Coder/264.html
1 + 7 =
快来做第一个评论的人吧~