|
|
51CTO旗下网站
|
|
移动端

一文读懂MQ消息队列

MQ(消息队列)在软件架构中是经常被使用的,特别是在分布式系统中也是使用频率很高的组件。

作者:佚名来源:今日头条|2019-08-23 12:12

【大咖·来了 第7期】10月24日晚8点观看《智能导购对话机器人实践》

MQ(消息队列)在软件架构中是经常被使用的,特别是在分布式系统中也是使用频率很高的组件。

以下从消息队列的使用场景、概念、常见问题及解决方案来详细讲解。

一、消息队列使用场景

1.1 常见的使用场景

系统解耦

在分布式环境下,系统间的相互依赖,最终会会导致整个依赖关系混乱,特别在微服务环境下,会出现相互依赖,甚至是循环依赖的情况,对后期系统的拆分和优化都带来极大负担。那么我们就可以用MQ来进行处理。上游系统将数据投递到MQ,下游系统取MQ的数据进行消费,投递和消费可以用同步的方式处理,因为MQ接收数据的性能是非常高的,不会影响上游系统的性能。

异步处理

如果采用同步的方式,系统的性能(并发量,吞吐量,响应时间)会有瓶颈。如何解决这个问题呢?引入消息队列,将不必要的业务逻辑异步处理。

异步处理也可以引来 并行处理的使用姿势。在工作中,我们基于消息开发了一个简单的分布式任务处理组件。该组件简单分为三块分别是 切分、加载、执行三个阶段

每个阶段都是以作为消费者,然后处理完毕后再作为生产者发送消息。消息消费无状态,可以按需无限拓容。

流量削峰

由于使用消息,我们的链路变成了生产者发送消息,消息中间件存储消息,最后消费者从消息中间件拉取消息的一个过程。而消息中间件的存储能力能够有效的帮助消费者进行缓冲。试想下,正常流量下消费者能够愉快的进行消费,瞬时高峰流量来的时候,消费者消费能力跟不上,刚好阻塞在消息中间件,等峰值过后,消费者又能很快的将阻塞的消息进行消费。

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

数据分发

大部分开源的MQ中间件基本都支持一对多或者广播的模式,而且都可以根据规则选择分发的对象。这样上游的一份数据,众多下游系统中,可以根据规则选择是否接收这些数据,这样扩展性就很强了。

1.2 消息使用的先决条件

以上四种是MQ中间件最常见的场景,但是我们细想,MQ中间件的引入会带来什么问题呢?那就是实时性。所以MQ中间件使用的先决条件是:能容忍延迟,只要求最终一致性较为合适。

二、消息相关的概念

MQ特点

  • 先进先出
  • 不能先进先出,都不能说是队列了。消息队列的顺序在入队的时候就基本已经确定了,一般是不需人工干预的。而且,最重要的是,数据是只有一条数据在使用中。 这也是MQ在诸多场景被使用的原因。
  • 发布订阅
  • 发布订阅是一种很高效的处理方式,如果不发生阻塞,基本可以当做是同步操作。这种处理方式能非常有效的提升服务器利用率,这样的应用场景非常广泛。
  • 持久化
  • 持久化确保MQ的使用不只是一个部分场景的辅助工具,而是让MQ能像数据库一样存储核心的数据。
  • 分布式
  • 在现在大流量、大数据的使用场景下,只支持单体应用的服务器软件基本是无法使用的,支持分布式的部署,才能被广泛使用。而且,MQ的定位就是一个高性能的中间件。

在JMS标准中,有两种消息模型P2P(Point toPoint)和Publish/Sub(Pub/Sub)。

P2P

一文读懂MQ消息队列

点对点,一个发,一个消费。涉及到的角色 发布者(Publisher)、消费者(Consumer)、消息队列(Queue)

特点

一个消息只能被一个消费者消费,消费后会从队列里移除

发布者和消费者无关系,发布者发送消息的行为不会随消费者而改变

消费者消费完成消息,需要向队列Ack,消息队列发现消息消费成功即做消息移除

Pub/Sub

一文读懂MQ消息队列

发布订阅模式,一个发布,多方订阅。涉及到的角色有 发布者(Publisher)、主题(Topic)、订阅者(Subscriber)。

特点

  1. 每个消息可以有多个消费者
  2. 针对某个主题(Topic)的订阅者,必须创建一个订阅者之后,才能消费发布者的消息
  3. 为了消费消息,订阅者必须保持运行的状态

三、常见问题及解决方案

消息阻塞

1、消息阻塞一般都是流量激增,超过消费者消费能力;

2、或者消费者出现逻辑问题,导致不断的重试或长时间等待。

第一种可以通过扩容解决

第二种只能紧急修复问题,发布上线,在阻塞的过程中会造成大量的消息积压,这种情况也可以考虑临时扩容

重复消费

重复消费一般发生下消费端,比如消费者处理完毕,在准备进行ack的时候出现了问题,应用重启后,消息中间件以为该消息还未处理又推给了消费者,或者消费者拉取的时候重复。

一般的做法是消费端做幂等。

消息丢失

消息丢失一般分为生产者发送失败、消息中间件丢失、消费丢失。

生产者丢失:可能以为网络问题或者消息中间处理失败导致,消息遗漏。

消息中间的丢失:一般中间件可以设置丢弃策略,大部分MQ中间件产品可以保证数据不丢失,这种情况基本不用考虑。

消费丢失:有的消息中间件支持自动ack,当消费者消费到消息,消息中间件也不管是否消费成功自动ack。这时候一般选择消费者主动ack比较合适。

消息顺序性

消息顺序性一般通过MQ中间件保证,大部分MQ中间件只能做到局部有序,比如Kafka,只能保证单个partition队列有序。有些也会做到全局有序,但是成本比较高。笔者目前服务的公司现在是支持全局有序的。

MQ组件有activeMQ、rabbitMQ、rocketMQ、zeroMQ、Kafka;有兴趣的同学可以深入去了解。

【编辑推荐】

  1. 消息队列、消息代理和消息中间件的区别和联系
  2. 用消息服务来提高微服务的可靠性
  3. 消息中间件:RabbitMQ原理、集群、基本运维操作、常见故障处理
  4. 高速飞机上换引擎,MQ如何实现平滑迁移?
  5. 一个天天用消息队列的人,不知道为啥用 MQ,这就有点尴尬
【责任编辑:武晓燕 TEL:(010)68476606】

点赞 0
分享:
大家都在看
猜你喜欢

订阅专栏+更多

这就是5G

这就是5G

5G那些事儿
共15章 | armmay

115人订阅学习

16招轻松掌握PPT技巧

16招轻松掌握PPT技巧

GET职场加薪技能
共16章 | 晒书包

371人订阅学习

20个局域网建设改造案例

20个局域网建设改造案例

网络搭建技巧
共20章 | 捷哥CCIE

758人订阅学习

读 书 +更多

计算机网络技术

本书是为北大燕工教育研究院编写的计算机网络技术的学习教材。它以实际教学大纲为依据,全面系统的介绍了计算机网络技术知识,对于一个...

订阅51CTO邮刊

点击这里查看样刊

订阅51CTO邮刊

51CTO服务号

51CTO官微