一、简介
MQ全称为Message Queue-消息队列,是一种应用程序对应用程序的消息通信,一端只管往队列不断发布信息,另一端只管往队列中读取消息,发布者不需要关心读取消息的谁,读取消息者不需要关心发布消息的是谁,各干各的互不干扰。
市场上现在常用的消息队列有:RabbitMQ、RocketMQ、Kafka,ActiveMQ。
先从开发语言来说,几款MQ对应的开发语言:
详细对比如下(ActiveMQ->RabbitMQ->RocketMQ->Kafka):
一般的业务系统要引入MQ,最早大家都用ActiveMQ,但是现在用的并不多了,没经过大规模吞吐量场景的验证,社区也不是很活跃; 后来大家开始用RabbitMQ,但是确实erlang语言阻止了大量的java工程师去深入研究和掌控他,对公司而言,几乎处于不可控的状态,但是确实人是开源的,比较稳定的支持,活跃度也高;
不过现在确实越来越多的公司,会去用RocketMQ,确实很不错,对自己公司技术实力有绝对自信的,我推荐用RocketMQ。
所以中小型公司,技术实力较为一般,技术挑战不是特别高,用RabbitMQ是不错的选择;大型公司,基础架构研发实力较强,用RocketMQ是很好的选择。
如果是大数据领域的实时计算、日志采集等场景,用Kafka是业内标准的,绝对没问题,社区活跃度很高,目前几乎是全世界这个领域的事实性规范了。
二、MQ的优势
使用消息MQ后,只需要保证消息格式不变,不需要关心发布者及消费者之间的关系,这两者不需要彼此联系
在一些不需要即时(同步)的返回结果操作,通过消息队列来实现异步。
在大量请求时(秒杀场景),使用消息队列做缓冲处理,削弱峰值流量,防止系统在短时间内被峰值流量冲垮。
场景:在大量流量涌入高峰,如数据库只能抗住2000的并发流量,可以使用MQ控制2000到数据库中
日志存储在消息队列中,用来处理日志,比如kafka。
三、MQ的劣势
在还未引进MQ之前,系统只需要关系生产端与消费端的接口一致性就可以了,现在引进后,系统需要关注生产端、MQ与消费端三者的稳定性,这增加系统的负担,系统运维成本增加。
引入了MQ,需要考虑的问题就增加了,如何保障消息的一致性,消费不被重复消费等问题,
A系统发送完消息直接返回成功,但是BCD系统之中若有系统写库失败,则会产生数据不一致的问题。
四、常见问题
幂等性:就是用户对于同一操作发起的一次请求或者多次请求的结果是一致的,不会因为多次点击而产生了副作用
问题出现原因
我们先来了解一下产生消息重复消费的原因,对于MQ的使用,有三个角色:生产者、MQ、消费者,那么消息的重复这三者会出现:
解决方案
在正常情况下,生产者是客户,我们很难避免出现用户重复点击的情况,而MQ是允许存在多条一样的消息,但消费者是不允许出现消费两条一样的数据,所以幂等性一般是在消费端实现的:
解决思路
在生产端发布消息时,每次法发布消息都把上一条消息的ID记录到消息体中,消费者接收到消息时,做如下操作
根据消息重要程度,可以分为两种情况处理
如果这篇文章对你有所帮助,或者有所启发的话,帮忙点赞、在看、转发、收藏,你的支持就是我坚持下去的最大动力!