三分钟带你快速入门消息队列!

开发 架构
Kafka 的特点其实很明显,就是仅仅提供较少的核心功能,但是提供超高的吞吐量,ms 级的延迟,极高的可用性以及可靠性,而且分布式可以任意扩展。

01、消息队列由来

可能在你没了解消息队列之前,已经听过很多概念了,例如 JMS,AMQP,ActiveMQ,RabbitMQ,RocketMQ,Kafka 等等。

一个消息中间件,咋搞出这么多概念?

别慌,我们先从历史角度来理清这些 MQ 和协议之间的关系!

消息中间件其实诞生的很早,在互联网应用还是一片荒芜的年代,有个在美国的印度小哥 Vivek Ranadive 就设想了一种通用软件总线,采用发布订阅的模式,类似于电脑主板上的总线,新的设备或者程序如果想和电脑上其他的设备软件通信,只需要按照协议对接总线就可以完成接入和通信!

图片图片

在 1983 年,26岁的印度小哥 Vivek Ranadive 创办了一家公司 Teknekron,实现了世界上第一个消息中间件The Information Bus(TIB)。

很快 TIB 软件受到了企业的欢迎,最初被高盛集团用于解决金融交易,Teknekron 的业务发展速度甚至引起了当时最牛逼的 IT 公司 IBM 的注意。

于是 IBM 也开始组建团队来研发自己的消息队列软件,这才有了后来的wesphere mq,不久微软也加入了战团。

由于商业壁垒,每个软件厂商都按照自己的标准来实现软件通信,导致企业客户不能随便更换 MQ 平台。

为了打破这个壁垒,同时为了能够让消息在各个消息队列平台间互融互通, JMS (Java Message Service) 应运而生 。

JMS 试图通过提供公共 Java API 的方式,隐藏单独 MQ 产品供应商提供的实现接口,从而跨越了壁垒,已解决互通问题。

从技术上讲, Java 应用程序只需针对 JMS API 进行编程,选择合适的 MQ 驱动即可, JMS 会打理好其他部分,就好比类似于 JDBC,对于开发者来说,只需要编写好 sql,具体是使用 oracle 还是 mysql 或者 sqlserver,由具体的厂商来提供驱动包文件即可,开发者无需关心具体的数据库厂商,从而大大的提升了开发效率、降低了开发难度。

ActiveMQ 就是 JMS 的 一种具体实现。

  • JMS - 点对点模型

图片图片

JMS - 点对点模型

  • JMS - 发布订阅模型

JMS - 发布订阅模型JMS - 发布订阅模型

尽管使用标准化接口能有效的融合众多不同的 MQ 产品,但是也暴露出很多问题,例如有些 MQ 产品提供了非常高级的功能,但由于标准化接口的限制,导致用户无法使用,所以急需一种新的消息通信标准化方案。

在 2006 年 6 月,由 Cisco 、 Redhat 、iMatix 等人联合制定了 AMQP 的公开标准,由此 AMQP 登上了历史的舞台。

AMQP 是应用层协议的一个开放标准,以解决众多消息中间件的需求和拓扑结构问题,它为面向消息的中间件设计,基于此协议的客户端与消息中间件可传递消息,同时并不受产品、开发语言等条件的限制。

  • JMS vs AMQP

图片图片

RabbitMQ 就是 AMQP 的一种具体实现。

AMQP - 模型AMQP - 模型

随着时间的推进,虽然 AMQP 规范能适用的业务场景很多,但是 LinkedIn(领英) 在实现消息队列的时候觉得 AMQP 规范并不适合自己,于是在设计 Kafka 的时候,并不支持 AMQP 所有的特性。

同时阿里巴巴的 RocketMQ 在实现上也借鉴了 Kakfa 的思想,也不支持 AMQP 协议,并且你会发现在 Kafka 和 RocketMQ 中都有类似 Topic 和 Consumer Group 的概念,而这些概念在 AMQP 协议中并不存在。

02、为什么要使用消息队列

消息中间件虽然发展了很多年,但是不是每个项目都有机会能接触到消息队列,对于初次接触 MQ 的同学,难免会发出一些疑问!

什么是消息队列?为什么要使用消息队列?使用消息队列有哪些弊端?

对于传统的应用程序,如果需要向另一个应用程序发送信息,只需要向其发出请求即可!

图片图片

这种方式虽然简单直接,但是如果应用程序2突然挂了,应用程序1可能会因为服务异常,而无法继续提供服务!

设想一下,在应用程序1和应用程序2之间,插入一个消息服务,主要用于接受消息和发送消息,这样应用程序1和应用程序2之间的依赖关系就解耦了,同时也不会因为任何一方当服务不可用时,无法继续提供服务!

图片图片

其中插入的消息服务被称为消息队列!

由此可见,引入消息队列带来的优势很明显:

  • 程序解耦:应用程序1和应用程序2在进行交互时,不会因为一方服务中断而导致服务停止;
  • 异步处理:程序解耦之后,带来的最大的好处就是可以异步处理,应用程序1只管把消息发送到消息中间件,应用程序2只需要从消息中间件中接受消息然后进行处理即可;

同时,基于异步处理特性,在某些业务场景下,例如商品秒杀活动,引入消息队列之后,当客户端请求量很大的时候,可以有效的进行流量削峰!

图片图片

如果没有中间层做缓冲,当进行商品秒杀时,一下突然大量请求涌入,很可能造成系统直接瘫痪,甚至宕机!

在大型网站系统中,如何通过日志快速实时定位系统异常的代码,可以说至关重要!

LinkedIn 开发的消息队列 Kafka,可以说是日志采集方面的王者,在中、大型系统开发中,将消息队列 Kafka 用在日志处理中,可以有效的解决大量日志传输的问题。

当然,引入消息队列也会带来很明显的弊端:

  • 系统可用性降低:在引入消息队列之前,你不用考虑消息丢失或者消息队列服务挂掉等等的情况,但是引入消息队列之后你就需要去考虑这些问题!
  • 系统复杂性提高:加入消息队列之后,你需要保证消息没有被重复消费、处理消息没有被正确处理的情况等等问题!

引入消息队列虽然会带来一些问题,俗话说,兵来将挡、水来土掩,这句话同样适用于 IT 开发者,有坑填坑!

对于系统可用性降低方面,通常常用的解决方案就是搭建消息服务集群,具体技术实现上可以是主从架构或者分布式架构,即时一台消息队列服务机器挂了,也不会影响消息队列无法提供服务!

对于系统复杂性提高方面,常用的解决方案也很多,例如接受者接受到消息之后,可以先将消息写入数据库,即时没有被正确处理,还可以走人工处理,或者消息消费失败,将消息重新入队等待下一次消费等等。

03、常见的消息队列对比

目前比较主流的 MQ 产品,有 ActiveMQ,RabbitMQ,RocketMQ,Kafka,并且他们都是开源的,他们各自也有各自的特点。

图片图片

总结内容如下

  • 1.ActiveMQ 的社区算是比较成熟,但是较目前来说,ActiveMQ 的性能比较差,而且版本迭代很慢,不推荐使用。
  • 2.RabbitMQ 在吞吐量方面虽然稍逊于 Kafka 和 RocketMQ ,但是由于它基于 erlang 开发,所以并发能力很强,性能极其好,延时很低,达到微秒级。但是也因为 RabbitMQ 基于 erlang 开发,所以国内很少有公司有实力做erlang源码级别的研究和定制。如果业务场景对并发量要求不是太高(十万级、百万级),那这四种消息队列中,首选 RabbitMQ。如果是大数据领域的实时计算、日志采集等场景,用 Kafka 是业内标准的,绝对没问题,社区活跃度很高,绝对不会黄,何况几乎是全世界这个领域的事实性规范。
  • 3.RocketMQ 阿里出品,Java 系开源项目,源代码我们可以直接阅读,然后可以定制自己公司的MQ,并且 RocketMQ 有阿里巴巴的实际业务场景的实战考验。RocketMQ 社区活跃度相对较为一般,不过也还可以,文档相对来说简单一些。还有就是阿里出台的技术,你得应对这个技术万一被抛弃,社区黄掉的风险,如果你们公司有技术实力我觉得用RocketMQ 挺好的。
  • 4.Kafka 的特点其实很明显,就是仅仅提供较少的核心功能,但是提供超高的吞吐量,ms 级的延迟,极高的可用性以及可靠性,而且分布式可以任意扩展。同时 Kafka 最好是支撑较少的 topic 数量即可,保证其超高吞吐量。Kafka 唯一的一点劣势是有可能消息重复消费,那么对数据准确性会造成极其轻微的影响,在大数据领域中以及日志采集中,这点轻微影响可以忽略。Kafka天然适合大数据实时计算以及日志收集。

四、参考

1、https://cloud.tencent.com/developer/article/1558994

2、https://snailclimb.gitee.io/javaguide

责任编辑:武晓燕 来源: 潘志的研发笔记
相关推荐

2022-02-17 09:24:11

TypeScript编程语言javaScrip

2021-02-03 14:31:53

人工智能人脸识别

2024-04-01 09:59:08

消息队列通信微服务

2024-10-15 09:18:30

2024-05-16 11:13:16

Helm工具release

2024-08-30 08:50:00

2021-04-20 13:59:37

云计算

2024-01-16 07:46:14

FutureTask接口用法

2020-06-30 10:45:28

Web开发工具

2024-07-05 09:31:37

2024-01-12 07:38:38

AQS原理JUC

2020-03-08 16:45:58

数据挖掘学习数据量

2017-01-18 15:38:20

语言

2019-12-05 10:00:03

架构Redis服务器

2021-09-16 10:29:05

开发技能代码

2024-02-22 07:37:37

对象JVM内存

2024-06-06 08:50:43

2023-08-01 09:01:51

Broker• 事务消息selector

2023-08-14 09:16:26

消息存储磁盘

2023-08-24 09:01:25

消息拉取RocketMQ
点赞
收藏

51CTO技术栈公众号