MQ介绍
根据某科的介绍,MQ(message queue),叫消息队列,是基础数据结构中先进先出的一种数据机构。
一般用来解决应用解耦,异步消息,流量削锋等问题,实现高性能,高可用,可伸缩和最终一致性架构。
名词 | 解释 |
---|---|
解耦 | 简单说就是积木化,每个东西都相互独立,比如汉堡包,面包跟肉饼是相互独立,可以单独使用,也可以组合成一个食物 |
异步 | 去买汉堡包,下单之后就去玩手机,等服务员叫号通知领取,这就叫异步;而同步是下单后,什么都不能干,直到服务员叫号才能做其他事 |
限流 | 大家 9 点上班,地铁进不去,门口做限流 |
削峰 | 遵从最后落地到数据库的请求数要尽量少的原则,比如让 1/2 的人下午开始上班、局部停电,感兴趣可以查看削峰填谷 |
消息 | 要传输的内容,比如说话、写信,形式不重要,按照双方约定的格式即可 |
队列 | 是一种先进先出的数据结构,排队打疫苗,从队尾入队,从队头出队 |
MQ 主要产品包括:RabbitMQ、ActiveMQ、RocketMQ、ZeroMQ、Kafka
通过上述的内容,不难发现,MQ是一种跨进程的通信机制,用于上下游传递消息,而个人觉得MQ有点像中介, 房东发布出租信息,信息放在中介处,租客来通过中介来租房子。
使用 MQ 的好处
举个通俗点的例子:
面试官希望 HR 早点招聘到合适的人选,于是一开始是这样的:
HR 问面试官什么时候有空,把候选人资料送过去,并且亲自看到面试官看完并给出结论后才离开,时间一长,大家都觉得很麻烦,HR 觉得候选人不错,面试官觉得不合适,容易发生争执。
后面,HR 跟面试官说,我把资料放在桌子上,你有空记得看,然后每次面试官看到桌子有资料后,都会拿起来看。
在这个场景上,HR就是生产者,面试官就是消费者,桌子就是MQ。
使用MQ带来的好处是解决应用解耦,异步消息,流量削锋:
- HR想给资料时,无需知道面试官是否有空,只需要把资料放桌子上即可,这样大家都有时间做别的事,节省大家的时间。。应用解耦,每个成员都是独立的,不受其他成员影响。面试官不关心谁放的资料,HR 不关心谁哪个面试官看的资料
- 如果别的组也有招聘需求(且当是同一工种,比如 Java 后端开发),HR依然把资料放在桌子上,两个面试官只需要各自从桌子上取资料查阅即可。异步消息,HR 把资料放在桌子上即可,就可以去做别的事,比一开始亲自看着的效率高太多了
- HR无需关注面试官什么时候查看资料,也不关注看资料用多长的时间,减少矛盾。流量削峰,HR 给资料的频率不固定,面试官看资料的时长也不固定,面试官只需要在固定时间内看完给结论即可,不会有那么大的压力。
使用 MQ 的坏处
名词 | 解释 |
---|---|
引入复杂度 | 「桌子」这东西是使用 MQ 后多出来的,需要有地方放桌子,而且流程会变长,更复杂 |
不一致性 | HR会以为面试官应该看了资料,但实际面试官可能还没开始看,这就导致了不一致性的问题,但在约束好的时间内,面试官最终的查阅状态与HR的认知必须是要一致的,这就是所谓的最终不一致性 |
系统可用性降低 | 如果桌子坏了,后面的流程是不是就中断了 |
当然,使用MQ
还有很多问题要解决,比如资料无辜丢了、一样的资料,给了好多份、资料被抢、本来资料给面试官 A,结果给到面试官 B等场景都是需要处理的。
什么时候用 MQ
名词 | 解释 |
---|---|
生产者不需要从消费者处获得反馈 | 面试官到底看了没有,HR 根本不需关注,默认面试官是看了,否则就只能采取监督看完的方式 |
容许不一致性 | HR 可能会发现有时候面试官说看了资料,但实际没看的情况,只有 HR 愿意相信面试官最后看了即可 |
有效 | 解耦、提速等带来的收益大于放置书桌是有成本的,那说明是有效的。比如一个月甚至半年才有一份简历,那还不如直接当面给更高效 |
消息模型
什么是 JMS
Java 消息服务指的是两个应用程序之间进行异步通信的 API,它为标准消息协议和消息服务提供了一组通用接口,包括创建、发送、读取消息等,用于支持 JAVA 应用程序开发。
为什么需要 JMS
在JAVA
中,如果两个应用程序之间对各自都不了解,甚至这两个程序可能部署在不同地方上,那么它们之间如何发送消息呢?
举个例子,一个应用程序 A 部署在印度,另一个应用程序部署在美国,然后每当 A 触发某件事后,B 想从 A 获取一些更新信息。
当然,也有可能不止一个 B 对 A 的更新信息感兴趣,可能会有 N 个类似 B 的应用程序想从 A 中获取更新的信息。
在这种情况下,JAVA
提供了最佳的解决方案-JMS
,完美解决了上面讨论的问题。
点对点模型
在该模型中,有下列概念:
消息队列 (Queue)、发送者 (Sender)、接收者 (Receiver)
每个消息都被发送到一个特定的队列,接收者从队列中获取消息。队列保留着消息,直到它们被消费或超时。
- 支持存在多个消费者
- 每个消息只有一个消费者(一旦消息被消费,消息就不再在消息队列中)
- 发送者和接收者之间在时间上没有依赖性,也就是说当发送者发送了消息之后,不管接收者有没有正在运行,它不会影响到消息被发送到队列
- 接收者在成功接收消息之后需向队列应答成功
如果希望发送的每个消息都应该被成功处理的话,那么就需要点对点模型。
女神想找备胎 A 聊天,就单聊备 A,这就是点对点,只有一个人能收到消息
发布订阅模型
消息生产者(发布)将消息发布到topic
中,同时有多个消息消费者(订阅)消费该消息。和点对点方式不同,发布到 topic 的消息会被所有订阅者消费。。
在该模型中,有下列概念:
主题(Topic)、发布者(Publisher)、订阅者(Subscriber)
客户端将消息发送到主题。多个发布者将消息发送到 Topic,系统将这些消息传递给多个订阅者。
- 每个消息可以有多个消费者
- 发布者和订阅者有时间依赖性,只有当客户端创建订阅后才能接受消息,且订阅者需一直保持活动状态以接收消息
- 订阅者创建一个可持久化的订阅。这样,即使订阅者没有被激活(运行),它也能接收到发布者的消息。
如果希望发送的消息可以不被做任何处理、或者被一个消费者处理、或者可以被多个消费者处理的话,那么可以采用 Pub/Sub 模型。。
女神发了个朋友圈,她的备胎们都能看到,这就是发布/订阅。
两个模型之间的区别
点对点模型下,不可重复消费。
点对点下,一个队列可以有多个消费者,生产者发送一条消息到队列,消费者能用队列取出并且消费消息,一旦消息被消费后,队列不再有存储,所以其他消费者不能消费到已经被消费的消息,如果一直没有消费者处理,这条消息就会被保存,直到有可用的消费者为止。
发布订阅模型,可以重复消费。
发布订阅下,发布者发送到 topic 的消息,只有订阅了 topic 的订阅者才会收到消息,注意是所有订阅这个 topic 的服务都能收到,所以能达到消息拷贝的效果
MQ 的在工作上应用场景
虽然上面以一个招聘的例子来讲解 MQ 的应用场景,但可能还是会有疑问,不知道工作上是如何的,因此再讲讲工作上的场景。
异步
之前负责的一个需求叫老带新,大致流程如下:
1)用户下单后,会先判断下单者身份
2)如果是新用户,再判断是否有邀请人
3)如果有,再判断邀请人身份
4)如果是老用户,就给双方发积分
这样的话,用户的流程就会发生变化:
很明显,这样做的问题是:新增的逻辑存在堵塞下单主流程的风险。
既然同步处理会有问题,那就改异步吧,改完变成这样:
异步的好处是,即使老带新逻辑有问题,也不会堵塞下单流程。
这样的好日子没过几天,问题又来了:老带新业务频繁改动,导致下单系统频繁发版本,存在质量隐患。
使用 MQ
由于依赖订单系统的业务越来越多,为了保证下单系统的稳定性,业务层面必须解耦,只需要把支付成功的消息告诉别的业务,他们收到了通知后自行处理,我们只管自己的流程,后续还有其他业务系统,直接订阅我们发送的支付成功消息。
「MQ 带来的问题」
- 如何保证消息队列的高可用?
- 如何保证消息不被重复消费?
- 如何处理消息丢失的问题?
- 如何保证消息的顺序性?
- 如何处理消息队列大量消息积压?
上面这些问题,都是实际工作上会遇到的,往往也都是测试点,下面也会有提及到,简单了解下即可。
「MQ 产品的对比」
产品 | 单机吞吐量 | 时效性 | 可用性 | 消息可靠性 | 功能支持 |
---|---|---|---|---|---|
ActiveMQ | 万级 | 毫秒级 | 高 | 较低概率出现丢失数据 | 极其完备 |
RabbitMQ | 万级 | 微妙级 | 高 | 基本不丢 | erlang 开发 |
RocketMQ | 十万级 | 毫秒级 | 非常高 | 可配置 0 丢失 | 分布式 |
Kafka | 十万级 | 毫秒级 | 非常高高 | 可配置 0 丢失 | 分布式 |
而在选择上,一般公司都是用Kafka
跟RocketMQ
较多。
「MQ 的测试点」
生产者
- 生成的数据格式是否跟定义的一致
- 数据是否有成功推送到队列里
- 数据是否有成功推动到对应的 topic
- 推送失败时如何处理
- 重复推送同一条数据,如何处理
- 不同顺序推送消息,注意队列优先级
- 推消息耗时
- 队列容量达到上限,无法推送后如何处理
消费者
- 消费的消息是否来自订阅的 topic
- 消息被消费了,是否有清除
- 生产者推送过快,消费速度过慢(堵塞),会如何
- 无法消费没订阅的 topic 消息
- 生产者推送消息后,消费者接受到的消息内容跟生产者推的一致
- 如何处理重复消息,比如幂等
- 处理超时
- 消息处理失败
- 消费消息的优先级是否跟推的一致
- 消费消息耗时
- 消费者宕机,消息堆积,无人处理,会如何处理
- 是否能正常消费消息
队列
- 宕机恢复后,消息是否丢失
- 宕机预案,多久能恢复,如果无法恢复的预案
- 不同的消息格式,是否能正常识别及转发
小结
来来去去,花了一周的时间来整理这堆信息,之前有测过mq,但没有太了解这玩意,从介绍、选型、测试点,加深了对 mq 的印象,但由于没做过 mq 的性能测试跟自动化测试,所以这块暂时没有心得能输出,如果后续有类似的经历,也会分享下。
本文留下了一个悬念,针对消息不一致的问题,大家是怎么解决的,这边非常好奇,所以下篇计划会写分布式事务,想深入了解下细节~更多关于MQ工作场景消息模型的资料请关注编程网其它相关文章!