精华内容
下载资源
问答
  • 消息队列-简单介绍Java消息队列,什么是消息队列,作用以及常见消息队列
    千次阅读
    2019-07-08 23:23:42

    天天说队列, 项目请求数据不能及时处理时,就一言不合通过队列啊, 心中那个是妈卖批,那么到底什么队列呢,队列有到底运用于哪些运用场景呢;

    先说说应用场景吧, 不知道有啥作用,看多了含义,原理什么的还是头疼;

    消息队列应用场景

    1.比如你的服务器一秒能处理100个订单,但秒杀活动1秒进来1000个订单,持续10秒,在后端能力无法增加的情况下,你可以用消息队列将总共10000个请求压在队列里,后台consumer按原有能力处理,100秒后处理完所有请求(而不是直接宕机丢失订单数据)

    使用消息队列能够使关键组件顶住增长的访问压力,而不是因为超出负荷的请求而完全崩溃 , 就是防止雪崩。某一时刻数据量突然增大,起到一个缓冲。


    2.一般都是异步的,不要求立即响应。打个比喻,你同时只能做一件事,但是你有一个ToDoList,每做完一个,在ToDoList中划掉一个,有新的分给你的任务,就放到ToDoList后面,这个ToDoList差不多就是一个队列了,队列就是一种数据结构,减轻的不止是数据库的压力。


    3.可用于一些不及时的操作,耗时的操作,比如发送邮件、图片处理等等。

    就是将比较耗时而且不需要即时(同步)返回结果的操作作为消息放入消息队列。同时由于使用了消息队列,只要保证消息格式不变,消息的发送方和接收方并不需要彼此联系,也不需要受对方的影响,即解耦和。

    4.项目功能软件的正常使用中,并不需要去刻意的使用消息队列处理,而是当出现性能瓶颈时采用,否则盲目的使用消息队列 , 增加维护和开发的成本,反而影响开发进度而得不偿失。

    消息队列种类及特点:
        rabbitMQ稳定,可靠,数据一致,支持多协议,有消息确认,性能一般,基于erlang语言,二次开发困难.
        kafka高吞吐,高性能,快速持久化,无消息确认,无消息遗漏,可能会有有重复消息,依赖于zookeeper,成本高.
        ZeroMQ灵活快速,不支持持久化,需要大量编码来实现稳定可靠.
        ActiveMQ不够灵活轻巧,对队列较多情况支持不好.
        rocketMQ性能好,高吞吐,高可用性,支持大规模分布式.

        ZeroMQ小而美,RabbitMQ大而稳,Kakfa和RocketMQ快而强劲。
     

    更多相关内容
  • 什么是消息队列你了解过么?

    你知道的越多,你不知道的越多

    点赞再看,养成习惯

    GitHub上已经开源 https://github.com/JavaFamily 有一线大厂面试点脑图、个人联系方式,欢迎Star和完善

    面试开始

    一个风度翩翩,穿着格子衬衣的中年男子,拿着一个满是划痕的mac向你走来,看着铮亮的头,心想着肯定是尼玛顶级架构师吧!但是我们看过暖男敖丙的系列,腹有诗书气自华,虚都不虚。

    小伙子之前问了你这么多Redis的知识,你不仅对答如流,你还能把各自场景的解决方案,优缺点说得这么流畅,说你是不是看过敖丙写的《吊打面试官》系列呀?

    惊!!!老师你怎么知道的,我看了他的系列根本停不下来啊。

    呵呵,Redis没难住你,但是我问个新的技术栈我还怕难不住你?我问问你你项目中用过消息队列么?你为啥用消息队列?

    噗此,这也叫问题?别人用了我能不用么?别人用了我就用了呗,我就是为了用而用。

    你心里嘀咕就好了,千万别说出来哈,说出来了没拿到Offer别到时候就在那说,敖丙那个渣男教我说的!

    面试官你好:我们公司本身的业务体量很小,所以直接单机一把梭啥都能搞定了,但是后面业务体量不断扩大,采用微服务的设计思想分布式的部署方式,所以拆分了很多的服务,随着体量的增加以及业务场景越来越复杂了,很多场景单机的技术栈和中间件以及不够用了,而且对系统的友好性也下降了,最后做了很多技术选型的工作,我们决定引入消息队列中间件

    哦?你说到业务场景越来越复杂,你那说一下你都在什么场景用到了消息队列?

    嗯,我从三个方面去说一下我使用的场景吧。

    Tip:这三个场景也是消息队列的经典场景,大家基本上要烂熟于心那种,就是一说到消息队列你脑子就要想到异步、削峰、解耦,条件反射那种。

    异步:

    我们之前的场景里面有很多步骤都是在一个流程里面需要做完的,就比如说我的下单系统吧,本来我们业务简单,下单了付了钱就好了,流程就走完了。

    但是后面来了个产品经理,搞了个优惠券系统,OK问题不大,流程里面多100ms去扣减优惠券。

    后来产品经理灵光一闪说我们可以搞个积分系统啊,也行吧,流程里面多了200ms去增减积分。

    再后来后来隔壁的产品老王说:下单成功后我们要给用户发短信,也将就吧,100ms去发个短信。

    再后来。。。(敖丙你有完没完!!!)

    反正就流程有点像这样 ↓

    你们可以看到这才加了三个,我可以斩钉截铁的告诉你真正的下单流程涉及的系统绝对在10个以上(主流电商),越大的越多。

    这个链路这样下去,时间长得一批,用户发现我买个东西你特么要花几十秒,垃圾电商我不在你这里买了,不过要是都像并夕夕这么便宜,真香

    但是我们公司没有夕夕的那个经济实力啊,那只能优化系统了。

    Tip:我之前在的电商老东家要求所有接口的RtResponseTime响应时间)在200ms内,超出的全部优化,我现在所负责的系统QPS也是9W+就是抖动一下网络集群都可能炸锅那种,RT基本上都要求在50ms以内。

    大家感受一下这个QPS。

    嗯不错,链路长了就慢了,那你怎么解决的?

    那链路长了就慢了,但是我们发现上面的流程其实可以同时做的呀,你支付成功后,我去校验优惠券的同时我可以去增减积分啊,还可以同时发个短信啊。

    那正常的流程我们是没办法实现的呀,怎么办,异步

    你对比一下是不是发现,这样子最多只用100毫秒用户知道下单成功了,至于短信你迟几秒发给他他根本不在意是吧。

    小伙子我打断你一下,你说了异步,那我用线程,线程池去做不是一样的么?

    诶呀,面试官你不要急嘛,我后面还会说到的,骚等。

    解耦:

    既然面试官这么问了,我就说一下为啥我们不能用线程去做,因为用线程去做,你是不是要写代码?

    你一个订单流程,你扣积分,扣优惠券,发短信,扣库存。。。等等这么多业务要调用这么多的接口,每次加一个你要调用一个接口然后还要重新发布系统,写一次两次还好,写多了你就说:老子不干了!

    而且真的全部都写在一起的话,不单单是耦合这一个问题,你出问题排查也麻烦,流程里面随便一个地方出问题搞不好会影响到其他的点,小伙伴说我每个流程都try catch不就行了,相信我别这么做,这样的代码就像个定时炸弹💣,你不知道什么时候爆炸,平时不炸偏偏在你做活动的时候炸,你就领个P0故障收拾书包提前回家过年吧。

    Tip:P0—PN 是互联网大厂经常用来判定事故等级的机制,P0是最高等级了。

    但是你用了消息队列,耦合这个问题就迎刃而解了呀。

    哦,帅丙怎么说?

    且听我娓娓道来:

    你下单了,你就把你支付成功的消息告诉别的系统,他们收到了去处理就好了,你只用走完自己的流程,把自己的消息发出去,那后面要接入什么系统简单,直接订阅你发送的支付成功消息,你支付成功了我监听就好了

    那你的流程走完了,你不用管别人是否成功么?比如你下单了积分没加,优惠券没扣怎么办?

    问题是个好问题,但是没必要考虑,业务系统本身就是自己的开发人员维护的,你积分扣失败关我下单的什么事情?你管好自己下单系统的就好了。

    Tip:话是这么说,但是这其实是用了消息队列的一个缺点,涉及到分布式事务的知识点,我下面会提到。

    削峰:

    就拿我上一期写的秒杀来说(暗示新同学看我上一期),你平时流量很低,但是你要做秒杀活动00 :00的时候流量疯狂怼进来,你的服务器,RedisMySQL各自的承受能力都不一样,你直接全部流量照单全收肯定有问题啊,直接就打挂了。

    那怎么办?

    简单,把请求放到队列里面,然后至于每秒消费多少请求,就看自己的服务器处理能力,你能处理5000QPS你就消费这么多,可能会比正常的慢一点,但是不至于打挂服务器,等流量高峰下去了,你的服务也就没压力了。

    你看阿里双十一12:00的时候这么多流量瞬间涌进去,他有时候是不是会慢一点,但是人家没挂啊,或者降级给你个友好的提示页面,等高峰过去了又是一条好汉了。

    为了这个图特意打高一台服务的流量
    为了这个图特意打高一台服务的流量

    听你说了辣么多,怎么都是好处,那我问你使用了消息队列有啥问题么?

    诶,看过前面我写的文章的人才都知道,我经常说的就是,技术是把双刃剑

    没错面试官,我使用他是因为他带给我们很多好处,但是使用之后问题也是接踵而至

    同样的暖男我呀,也从三个点介绍他主要的缺点:

    系统复杂性

    本来蛮简单的一个系统,我代码随便写都没事,现在你凭空接入一个中间件在那,我是不是要考虑去维护他,而且使用的过程中是不是要考虑各种问题,比如消息重复消费消息丢失消息的顺序消费等等,反正用了之后就是贼烦。

    我插一句嘴,上面的问题(重复消费、消息丢失、顺序消费)你能分别介绍一下,并且说一下分别是怎么解决的么?

    不要!我都说了敖丙下一章写啥?

    其实不是暖男我不想在这里写,这三个问题我想了下,统统都是MQ重点问题,单独拿一个出来就是一篇文章了,篇幅实在太长了,我会在下一章挨个介绍一遍的。

    数据一致性

    这个其实是分布式服务本身就存在的一个问题,不仅仅是消息队列的问题,但是放在这里说是因为用了消息队列这个问题会暴露得比较严重一点。

    就像我开头说的,你下单的服务自己保证自己的逻辑成功处理了,你成功发了消息,但是优惠券系统,积分系统等等这么多系统,他们成功还是失败你就不管了?

    我说了保证自己的业务数据对的就好了,其实还是比较不负责任的一种说法,这样就像个渣男,没有格局这样呀你的路会越走越窄的

    所有的服务都成功才能算这一次下单是成功的,那怎么才能保证数据一致性呢?

    分布式事务:把下单,优惠券,积分。。。都放在一个事务里面一样,要成功一起成功,要失败一起失败。

    Tip:分布式事务在互联网公司里面实在常见,我也不在这里大篇幅介绍了,后面都会专门说的。

    可用性

    你搞个系统本身没啥问题,你现在突然接入一个中间件在那放着,万一挂了怎么办?我下个单MQ挂了,优惠券不扣了,积分不减了,这不是杀一个程序员能搞定的吧,感觉得杀一片。

    至于怎么保证高可用,还是那句话也不在这里展开讨论了,我后面一样会写,像写Redis那样写出来的。

    放心敖丙我不是渣男来的,我肯定会对你们负责的。点赞!

    看不出来啊,你有点东西呀,那我问一下你,你们是怎么做技术选型的?

    目前在市面上比较主流的消息队列中间件主要有,Kafka、ActiveMQ、RabbitMQ、RocketMQ 等这几种。

    不过敖丙我想说的是,ActiveMQRabbitMQ这两着因为吞吐量还有GitHub的社区活跃度的原因,在各大互联网公司都已经基本上绝迹了,业务体量一般的公司会是有在用的,但是越来越多的公司更青睐RocketMQ这样的消息中间件了。

    KafkaRocketMQ一直在各自擅长的领域发光发亮,不过写这篇文章的时候我问了蚂蚁金服,字节跳动和美团的朋友,好像大家用的都有点不一样,应该都是各自的中间件,可能做过修改,也可能是自研的,大多没有开源

    就像我们公司就是是基于KafkaRocketMQ两者的优点自研的消息队列中间件,吞吐量、可靠性、时效性等都很可观。

    我们回归正题,我这里用网上找的对比图让大家看看差距到底在哪里:

    大家其实一下子就能看到差距了,就拿吞吐量来说,早期比较活跃的ActiveMQRabbitMQ基本上不是后两者的对手了,在现在这样大数据的年代吞吐量是真的很重要

    比如现在突然爆发了一个超级热点新闻,你的APP注册用户高达亿数,你要想办法第一时间把突发全部推送到每个人手上,你没有大吞吐量的消息队列中间件用啥去推?

    再说这些用户大量涌进来看了你的新闻产生了一系列的附带流量,你怎么应对这些数据,很多场景离开消息队列基本上难以为继

    部署方式而言前两者也是大不如后面两个天然分布式架构的哥哥,都是高可用的分布式架构,而且数据多个副本的数据也能做到0丢失。

    我们再聊一下RabbitMQ这个中间件其实还行,但是这玩意开发语言居然是erlang,我敢说绝大部分工程师肯定不会为了一个中间件去刻意学习一门语言的,开发维护成本你想都想不到,出个问题查都查半天。

    至于RocketMQ(阿里开源的),git活跃度还可以。基本上你push了自己的bug确认了有问题都有阿里大佬跟你试试解答并修复的,我个人推荐的也是这个,他的架构设计部分跟同样是阿里开源的一个RPC框架是真的很像(Dubbo)可能是因为师出同门的原因吧。

    Tip:Dubbo等我写到RPC我会详细介绍的。

    Kafka我放到最后说,你们也应该知道了,压轴的这是个大哥,大数据领域,公司的日志采集,实时计算等场景,都离不开他的身影,他基本上算得上是世界范围级别的消息队列标杆了。

    以上这些都只是一些我自己的个人意见,真正的选型还是要去深入研究的,不然那你公司一天UV就1000你告诉我你要去用Kafka我只能说你吃饱撑的。

    记住,没有最好的技术,只有最适合的技术,不要为了用而用

    面试结束

    嗯,小伙子不错不错,分析得很到位,那你记得下期来说一下消息队列的高可用,重复消费、消息丢失、消息顺序、分布式事务等问题?

    嗯嗯好的面试官,不过不确定能不能一口气说完,毕竟敖丙还没开始写,而且读者还有可能白嫖,动力不一定够。

    嗯嗯这倒是个问题,不过啊在看的都是人才肯定会给你点赞👍的!

    我也这么认为。

    总结

    消息队列的基础知识我就先介绍这么多,消息队列在面试里面基本上也是跟我前面写的Redis一样必问的。

    面试的思路还是一样,要知其然,也要知其所以然,就是要知道为啥用,用了有啥好处,有啥坑。

    面试官不喜欢只知道用的,你只会用那哪天线上出问题怎么办?你难道在旁边拜佛?

    Tip:本来有很多我准备的资料的,但是都是外链,或者不合适的分享方式,博客的运营小姐姐提醒了我,所以大家去公众号回复【资料】好了。

    鸣谢

    之前的文章写了很多人加我,然后有个人才说是他蚂蚁金服的Leader推荐的我,我突然意识到我文章的受众好像慢慢变广了,之后不严谨的点要杜绝掉。

    所以之后我的文章经常会有大厂的小伙伴Review,也希望帮助我更好的监督自己的文章吧。

    这次是 某阿里系电商跟我一起做过活动小组的 佩恩 帮我Review的文章,感谢!

    絮叨

    另外,敖丙把自己的面试文章整理成了一本电子书,共 1630页!目录如下

    现在免费送给大家,在我的公众号三太子敖丙回复 【888】 即可获取。

    我是敖丙,一个在互联网苟且偷生的程序员。

    你知道的越多,你不知道的越多人才们的 【三连】 就是丙丙创作的最大动力,我们下期见!

    注:如果本篇博客有任何错误和建议,欢迎人才们留言!


    文章持续更新,可以微信搜索「 三太子敖丙 」第一时间阅读,回复【资料】有我准备的一线大厂面试资料和简历模板,本文 GitHub https://github.com/JavaFamily 已经收录,有大厂面试完整考点,欢迎Star。

    展开全文
  • 什么是消息队列

    千次阅读 2021-08-17 20:13:42
    一、消息队列概述 消息队列中间件是分布式系统中重要的组件,主要解决应用解耦,异步消息,流量削锋等问题,实现高性能,高可用,可伸缩和最终一致性架构。目前使用较多的消息队列有ActiveMQ,RabbitMQ,ZeroMQ,...

    C/C++Linux服务器开发/后台架构师知识体系

    一、消息队列概述

    消息队列中间件是分布式系统中重要的组件,主要解决应用解耦,异步消息,流量削锋等问题,实现高性能,高可用,可伸缩和最终一致性架构。目前使用较多的消息队列有ActiveMQ,RabbitMQ,ZeroMQ,Kafka,MetaMQ,RocketMQ

    二、消息队列应用场景

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

    2.1异步处理

    场景说明:用户注册后,需要发注册邮件和注册短信。传统的做法有两种 1.串行的方式;2.并行方式

    a、串行方式:将注册信息写入数据库成功后,发送注册邮件,再发送注册短信。以上三个任务全部完成后,返回给客户端。
    在这里插入图片描述
    b、并行方式:将注册信息写入数据库成功后,发送注册邮件的同时,发送注册短信。以上三个任务完成后,返回给客户端。与串行的差别是,并行的方式可以提高处理的时间
    在这里插入图片描述
    假设三个业务节点每个使用50毫秒钟,不考虑网络等其他开销,则串行方式的时间是150毫秒,并行的时间可能是100毫秒。

    因为CPU在单位时间内处理的请求数是一定的,假设CPU1秒内吞吐量是100次。则串行方式1秒内CPU可处理的请求量是7次(1000/150)。并行方式处理的请求量是10次(1000/100)小结:如以上案例描述,传统的方式系统的性能(并发量,吞吐量,响应时间)会有瓶颈。如何解决这个问题呢?

    引入消息队列,将不是必须的业务逻辑,异步处理。改造后的架构如下:
    在这里插入图片描述
    按照以上约定,用户的响应时间相当于是注册信息写入数据库的时间,也就是50毫秒。注册邮件,发送短信写入消息队列后,直接返回,因此写入消息队列的速度很快,基本可以忽略,因此用户的响应时间可能是50毫秒。因此架构改变后,系统的吞吐量提高到每秒20 QPS。比串行提高了3倍,比并行提高了两倍。

    2.2应用解耦

    场景说明:用户下单后,订单系统需要通知库存系统。传统的做法是,订单系统调用库存系统的接口。如下图:
    在这里插入图片描述
    传统模式的缺点:假如库存系统无法访问,则订单减库存将失败,从而导致订单失败,订单系统与库存系统耦合

    如何解决以上问题呢?引入应用消息队列后的方案,如下图:
    在这里插入图片描述
    订单系统:用户下单后,订单系统完成持久化处理,将消息写入消息队列,返回用户订单下单成功

    库存系统:订阅下单的消息,采用拉/推的方式,获取下单信息,库存系统根据下单信息,进行库存操作

    假如:在下单时库存系统不能正常使用。也不影响正常下单,因为下单后,订单系统写入消息队列就不再关心其他的后续操作了。实现订单系统与库存系统的应用解耦

    2.3流量削锋

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

    应用场景:秒杀活动,一般会因为流量过大,导致流量暴增,应用挂掉。为解决这个问题,一般需要在应用前端加入消息队列。

    a、可以控制活动的人数

    b、可以缓解短时间内高流量压垮应用

    在这里插入图片描述
    用户的请求,服务器接收后,首先写入消息队列。假如消息队列长度超过最大数量,则直接抛弃用户请求或跳转到错误页面。

    秒杀业务根据消息队列中的请求信息,再做后续处理

    2.4日志处理

    日志处理是指将消息队列用在日志处理中,比如Kafka的应用,解决大量日志传输的问题。架构简化如下
    在这里插入图片描述
    日志采集客户端,负责日志数据采集,定时写受写入Kafka队列

    Kafka消息队列,负责日志数据的接收,存储和转发

    日志处理应用:订阅并消费kafka队列中的日志数据

    2.5消息通讯

    消息通讯是指,消息队列一般都内置了高效的通信机制,因此也可以用在纯的消息通讯。比如实现点对点消息队列,或者聊天室等

    点对点通讯:
    在这里插入图片描述
    客户端A和客户端B使用同一队列,进行消息通讯。

    聊天室通讯:
    在这里插入图片描述
    客户端A,客户端B,客户端N订阅同一主题,进行消息发布和接收。实现类似聊天室效果。

    以上实际是消息队列的两种消息模式,点对点或发布订阅模式。模型为示意图,供参考。

    三、消息中间件示例

    3.1电商系统

    在这里插入图片描述
    消息队列采用高可用,可持久化的消息中间件。比如Active MQ,Rabbit MQ,Rocket Mq。

    (1)应用将主干逻辑处理完成后,写入消息队列。消息发送是否成功可以开启消息的确认模式。(消息队列返回消息接收成功状态后,应用再返回,这样保障消息的完整性)

    (2)扩展流程(发短信,配送处理)订阅队列消息。采用推或拉的方式获取消息并处理。

    (3)消息将应用解耦的同时,带来了数据一致性问题,可以采用最终一致性方式解决。比如主数据写入数据库,扩展应用根据消息队列,并结合数据库方式实现基于消息队列的后续处理。

    3.2日志收集系统

    在这里插入图片描述
    分为Zookeeper注册中心,日志收集客户端,Kafka集群和Storm集群(OtherApp)四部分组成。

    Zookeeper注册中心,提出负载均衡和地址查×××

    日志收集客户端,用于采集应用系统的日志,并将数据推送到kafka队列

    Kafka集群:接收,路由,存储,转发等消息处理

    Storm集群:与OtherApp处于同一级别,采用拉的方式消费队列中的数据

    MQ选型对比文档

    在这里插入图片描述
    综合选择RabbitMq

    Kafka是linkedin开源的MQ系统,主要特点是基于Pull的模式来处理消息消费,追求高吞吐量,一开始的目的就是用于日志收集和传输,0.8开始支持复制,不支持事务,适合产生大量数据的互联网服务的数据收集业务。

    RabbitMQ是使用Erlang语言开发的开源消息队列系统,基于AMQP协议来实现。AMQP的主要特征是面向消息、队列、路由(包括点对点和发布/订阅)、可靠性、安全。AMQP协议更多用在企业系统内,对数据一致性、稳定性和可靠性要求很高的场景,对性能和吞吐量的要求还在其次。

    RocketMQ是阿里开源的消息中间件,它是纯Java开发,具有高吞吐量、高可用性、适合大规模分布式系统应用的特点。RocketMQ思路起源于Kafka,但并不是Kafka的一个Copy,它对消息的可靠传输及事务性做了优化,目前在阿里集团被广泛应用于交易、充值、流计算、消息推送、日志流式处理、binglog分发等场景。

    ZeroMQ只是一个网络编程的Pattern库,将常见的网络请求形式(分组管理,链接管理,发布订阅等)模式化、组件化,简而言之socket之上、MQ之下。对于MQ来说,网络传输只是它的一部分,更多需要处理的是消息存储、路由、Broker服务发现和查找、事务、消费模式(ack、重投等)、集群服务等。

    RabbitMQ/Kafka/ZeroMQ 都能提供消息队列服务,但有很大的区别。

    在面向服务架构中通过消息代理(比如 RabbitMQ / Kafka等),使用生产者-消费者模式在服务间进行异步通信是一种比较好的思想。

    因为服务间依赖由强耦合变成了松耦合。消息代理都会提供持久化机制,在消费者负载高或者掉线的情况下会把消息保存起来,不会丢失。就是说生产者和消费者不需要同时在线,这是传统的请求-应答模式比较难做到的,需要一个中间件来专门做这件事。其次消息代理可以根据消息本身做简单的路由策略,消费者可以根据这个来做负载均衡,业务分离等。

    缺点也有,就是需要额外搭建消息代理集群(但优点是大于缺点的 ) 。

    ZeroMQ 和 RabbitMQ/Kafka 不同,它只是一个异步消息库,在套接字的基础上提供了类似于消息代理的机制。使用 ZeroMQ 的话,需要对自己的业务代码进行改造,不利于服务解耦。RabbitMQ 支持 AMQP(二进制),STOMP(文本),MQTT(二进制),HTTP(里面包装其他协议)等协议。Kafka 使用自己的协议。

    Kafka 自身服务和消费者都需要依赖 Zookeeper。

    RabbitMQ 在有大量消息堆积的情况下性能会下降,Kafka不会。毕竟AMQP设计的初衷不是用来持久化海量消息的,而Kafka一开始是用来处理海量日志的。

    总的来说,RabbitMQ 和 Kafka 都是十分优秀的分布式的消息代理服务,只要合理部署,不作,基本上可以满足生产条件下的任何需求。

    关于这两种MQ的比较,网上的资料并不多,最权威的的是kafka的提交者写一篇文章。www.quora.com/What-are-th…

    里面提到的要点:

    1、 RabbitMq比kafka成熟,在可用性上,稳定性上,可靠性上,RabbitMq超过kafka

    2、 Kafka设计的初衷就是处理日志的,可以看做是一个日志系统,针对性很强,所以它并没有具备一个成熟MQ应该具备的特性

    3、 Kafka的性能(吞吐量、tps)比RabbitMq要强,这篇文章的作者认为,两者在这方面没有可比性。

    欢迎朋友们加入C/C++Linux服务器开发/高级架构师群:960994558
    群内提供免费的C/C++Linux服务器开发/高级架构师学习资料资料包括C/C++,Linux,golang技术,Nginx,ZeroMQ,MySQL,Redis,fastdfs,MongoDB,ZK,流媒体,CDN,P2P,K8S,Docker,TCP/IP,协程,DPDK,ffmpeg等)合理利用自己每一分每一秒的时间来学习提升自己,不要再用"没有时间“来掩饰自己思想上的懒惰!趁年轻,使劲拼,给未来的自己一个交代!

    展开全文
  • 什么是消息队列

    万次阅读 多人点赞 2018-03-01 13:58:00
    一、什么是消息队列 消息(Message)是指在应用之间传送的数据,消息可以非常简单,比如只包含文本字符串,也可以更复杂,可能包含嵌入对象。 消息队列(Message Queue)是一种应用间的通信方式,消息发送后可以...

    最近公司重构订单中心,用到消息中间件,闲暇时间对此进行学习了解,下面是学习内容的总结。
    一、什么是消息队列
    消息(Message)是指在应用之间传送的数据,消息可以非常简单,比如只包含文本字符串,也可以更复杂,可能包含嵌入对象。
    消息队列(Message Queue)是一种应用间的通信方式,消息发送后可以立即返回,有消息系统来确保信息的可靠专递,消息发布者只管把消息发布到MQ中而不管谁来取,消息使用者只管从MQ中取消息而不管谁发布的,这样发布者和使用者都不用知道对方的存在。
    二、为何使用消息队列
    从上面描述中可以看出消息队列是一种应用间的异步协作机制,那什么时候需要使用MQ呢?
    以常见的订单系统为例子,用户点击【下单】按钮后的业务逻辑包括:扣减库存、生成相应的单据、发红包、发短信通知‘在业务发展初期这些逻辑可能放在一起同步执行,随着业务订单量增长,需要提升系统服务的性能,这时候可以将一些不需要立即生效的操作拆分出来异步执行,,比如发红包、发短信通知等。这种场景就可以用MQ,在下单的主流程(比如扣减库存、生成相应的单据)完成之后发送一条消息到MQ让主流程快速完结,而由另外的单独线程拉取MQ的消息(或者由MQ推送消息),当发现MQ中有发红包或者发短信之类的消息,执行相应的业务逻辑。
    以上是用于业务解耦的情况,其他常见场景包括最终一致性、广播、错峰流控等等。
    三、RabbitMQ特点
    RabbitMQ是一个由Erlang语言开发的AMQP的开源实现。
    AMQP:Advanced Meassage Queue,高级消息队列协议。它是应用层协议的一个开放标准,为面向消息的中间设计,基于此协议的客户端与消息中间件可传递消息,并不受产品、开发语言等条件限制。

    RabbitMQ最初起源于金融系统,用于分布式系统中存储转发消息,在易用性、扩展性、高可用性等方面表现不俗,具体特点:
    1、可靠性(Reliablitity)
    RabbitMQ 使用一些机制来保证可靠性,如持久化、传输确认、发布确认。
    2、灵活的路由(Flexible Routing)
    在消息进入队列之前,通过 Exchange 来路由消息的。对于典型的路由功能,RabbitMQ 已经提供了一些内置的 Exchange 来实现。针对更复杂的路由功能,可以将多个 Exchange 绑定在一起,也通过插件机制实现自己的 Exchange 。
    3、消息集群(Clustering)
    多个 RabbitMQ 服务器可以组成一个集群,形成一个逻辑 Broker 。
    4、高可用(Highly Available Queues)
    队列可以在集群中的机器上进行镜像,使得在部分节点出问题的情况下队列仍然可用。
    5、多种协议(Multi-protocol)
    RabbitMQ 支持多种消息队列协议,比如 STOMP、MQTT 等等。
    6、多语言客户端(Many Clients)
    RabbitMQ 几乎支持所有常用语言,比如 Java、.NET、Ruby 等等。
    7、管理界面(Management UI)
    RabbitMQ 提供了一个易用的用户界面,使得用户可以监控和管理消息 Broker 的许多方面。
    8、跟踪机制(Tracing)
    如果消息异常,RabbitMQ 提供了消息跟踪机制,使用者可以找出发生了什么。
    9、插件机制(Plugin System)
    RabbitMQ 提供了许多插件,来从多方面进行扩展,也可以编写自己的插件。

    四、RabbitMQ中的概念模型
    消息模型
    所有 MQ 产品从模型抽象上来说都是一样的过程:
    消费者(consumer)订阅某个队列。生产者(producer)创建消息,然后发布到队列(queue)中,最后将消息发送到监听的消费者。
    这里写图片描述

    RabbitMQ 基本概念
    上面只是最简单抽象的描述,具体到 RabbitMQ 则有更详细的概念需要解释。上面介绍过 RabbitMQ 是 AMQP 协议的一个开源实现,所以其内部实际上也是 AMQP 中的基本概念:
    这里写图片描述

    1、Message
    消息,消息是不具名的,它由消息头和消息体组成。消息体是不透明的,而消息头则由一系列的可选属性组成,这些属性包括routing-key(路由键)、priority(相对于其他消息的优先权)、delivery-mode(指出该消息可能需要持久性存储)等。
    2、Publisher
    消息的生产者,也是一个向交换器发布消息的客户端应用程序。
    3、Exchange
    交换器,用来接收生产者发送的消息并将这些消息路由给服务器中的队列。
    4、Binding
    绑定,用于消息队列和交换器之间的关联。一个绑定就是基于路由键将交换器和消息队列连接起来的路由规则,所以可以将交换器理解成一个由绑定构成的路由表。
    5、Queue
    消息队列,用来保存消息直到发送给消费者。它是消息的容器,也是消息的终点。一个消息可投入一个或多个队列。消息一直在队列里面,等待消费者连接到这个队列将其取走。
    6、Connection
    网络连接,比如一个TCP连接。
    7、Channel
    信道,多路复用连接中的一条独立的双向数据流通道。信道是建立在真实的TCP连接内地虚拟连接,AMQP 命令都是通过信道发出去的,不管是发布消息、订阅队列还是接收消息,这些动作都是通过信道完成。因为对于操作系统来说建立和销毁 TCP 都是非常昂贵的开销,所以引入了信道的概念,以复用一条 TCP 连接。
    8、Consumer
    消息的消费者,表示一个从消息队列中取得消息的客户端应用程序。
    9、Virtual Host
    虚拟主机,表示一批交换器、消息队列和相关对象。虚拟主机是共享相同的身份认证和加密环境的独立服务器域。每个 vhost 本质上就是一个 mini 版的 RabbitMQ 服务器,拥有自己的队列、交换器、绑定和权限机制。vhost 是 AMQP 概念的基础,必须在连接时指定,RabbitMQ 默认的 vhost 是 / 。
    10、Broker
    表示消息队列服务器实体。

    五、消息队列的应用及好处

    例如

    (1)服务员点菜快,厨师做菜慢,服务员只需要下单给厨师,然后就可以继续去服务顾客,不需要等待厨师把菜做完

    点菜单就相当于消息,放单子的位置就相当于队列

    (2)业务系统需要发短信,但短信发送模块速度跟不上,业务系统就可以把发送短信的相关信息封装为一个消息,放入队列,短信发送模块从队列中获取消息进行处理

    消息队列的好处
    (1)提高系统响应速度
    使用消息队列,生产者一方,把消息往消息队列里一扔,就可以立马返回响应用户,无需等待处理结果
    (2)保证消息的传递
    如果发送消息时接收者不可用,消息队列会保留消息,直到成功的传递它
    (3)解耦
    只要信息格式不变,即使接收者的接口、位置、或者配置改变,也不会给发送者带来任何改变
    消息发送者无需知道消息接收者是谁,使得系统设计更清晰
    为什么需要分布式消息队列
    (1)多系统协作需要分布式
    例如消息队列的数据需要在多个系统之间共享,所以需要提供分布式通信机制、协同机制
    (2)可靠
    消息会被持久化到分布式存储中,这样避免了单台机器存储的消息由于机器问题导致消息丢失
    (3)可扩展
    分布式消息队列,会随着访问量的增加而方便的增加处理服务器

    展开全文
  • [MQ]什么是消息队列?

    万次阅读 多人点赞 2019-06-22 22:18:58
    什么是消息队列MQ(Message Queue)? 消息(Message):传输的数据。 队列(Queue):队列是一种先进先出的数据结构。 消息队列从字面的含义来看就是一个存放消息的容器。 消息队列可以简单理解为:把要传输的数据...
  • 消息队列”是在消息的传输过程中保存消息的容器。 “消息”是在两台计算机间传送的数据单位。消息可以非常简单,例如只包含文本字符串;也可以更复杂,可能包含嵌入对象。 消息被发送到队列中。“消息队列”是在...
  • 什么是消息队列(Message queue)

    万次阅读 2018-04-13 21:47:05
    最近接触到消息中间件,想通过本篇博文总结一些关于消息队列的知识以及 Java 语言中面向消息中间件(MOM)的API(JMS),希望能够帮助大家更好的理解消息中间件。 一、消息队列概述 消息队列(英语:Message queue)...
  • 面试官问你什么是消息队列?把这篇甩给他!

    千次阅读 多人点赞 2019-04-04 00:00:00
    来源:Java3y(ID:java3y)一、什么是消息队列消息队列不知道大家看到这个词的时候,会不会觉得它是一个比较高端的技术,反正我是觉得它好像是挺牛逼的。消息队列,...
  • 在此请教各位前辈到底什么是消息队列?Java中如何实现消息队列? 来个个人通俗的解释吧。 消息队列,顾名思义 首先是个队列。 队列的操作有入队和出队 也就是你有一个程序在产生内容然后入队(生产者) ...
  • 什么是消息队列?(Message Queue)

    千次阅读 2019-03-28 14:44:19
    一、消息队列概述消息队列中间件是分布式系统中重要的组件,主要解决应用解耦,异步消息,流量削锋等问题,实现高性能,高可用,可伸缩和最终一致性架构。目前使用较多的消息队列有ActiveMQ,RabbitMQ,ZeroMQ,...
  • 消息队列(mq)是什么?技术详解

    千次阅读 多人点赞 2019-06-25 13:37:28
    一、什么是消息队列消息队列不知道大家看到这个词的时候,会不会觉得它是一个比较高端的技术,反正我是觉得它好像是挺牛逼的。 消息队列,一般我们会简称它为MQ(Message Queue),嗯,就是很直白的简写。 我们...
  • 一张贴告诉你什么是消息队列

    千次阅读 2020-03-23 15:20:21
    1、消息队列的介绍 消息(Message):是指在应用之间传送的数据,消息可以非常简单,比如只包含文本字符串,也可以更复杂,可能包含嵌入对象。 消息队列(Message Queue):是一种应用间的通信方式,消息发送后...
  • SpringCloud笔记(四)消息队列

    千次阅读 2022-04-22 10:51:44
    那么,什么是消息队列呢? 我们之前如果需要进行远程调用,那么一般可以通过发送HTTP请求来完成,而现在,我们可以使用第二种方式,就是消息队列,它能够将发送方发送的信息放入队列中,当新的消息入队时,会通知...
  • JS 异步编程 JavaScript 语言的执行环境是单线程的,一次只能执行一个任务,多任务需要排队等候,这种模式可能会阻塞代码,导致代码执行效率低下。 为了避免这个问题,出现了异步编程。...消息队列:是用来存放宏任.
  • 1 为什么要使用消息队列? 回答:这个问题,咱只答三个最主要的应用场景(不可否认还有其他的,但是只答三个主要的),即以下六个字: (1)解耦 传统模式: 传统模式的缺点:系统间耦合性太强,如上图所示,系统A在代码中...
  • 消息队列和任务队列有什么区别?

    千次阅读 2020-11-03 22:46:19
    前言 昨天发了一篇文章是关于machinery的入门教程,有一位读者在留言中问我 这...回归正题,我们再来介绍一下什么是消息队列消息队列,一般我们会简称它为MQ(Message Queue)。他是由两个单词组成,我们应该对队列(Q
  • 消息中间件(消息队列

    千次阅读 2022-02-17 13:52:30
    消息中间件
  • 二、为什么需要消息队列? 三、使用消息队列什么好处? 四、为什么需要分布式? 五、分布式环境下需要解决哪些问题? 六、如何实现? 七、常见消息队列对比和选型 一、消息队列的特性 业务无关,一个具有普适...
  • 通俗易懂讲消息队列

    万次阅读 多人点赞 2020-03-05 17:00:21
    一、什么是消息队列消息队列不知道大家看到这个词的时候,会不会觉得它是一个比较高端的技术,反正我是觉得它好像是挺牛逼的。 消息队列,一般我们会简称它为MQ(Message Queue),嗯...
  • 一、基础知识 关于消息队列,你可以先看看博客,然后再看微软官网。如何你能完全领悟下面的链接,特别是官网的消息队列知识,你就不用看其他博客或链接了。 1、博客 ... ...
  • 消息队列中间件是分布式系统中重要的组件,主要解决应用解耦,异步消息,流量削锋等问题,实现高性能,高可用,可伸缩和最终一致性架构。目前使用较多的消息队列有ActiveMQ,RabbitMQ,ZeroMQ,Kafka,MetaMQ,...
  • 消息队列其实很简单

    千次阅读 2019-06-05 23:27:10
    1 什么是消息队列 2 为什么要用消息队列 (1) 通过异步处理提高系统性能(削峰、减少响应所需时间) (2) 降低系统耦合性 3 使用消息队列带来的一些问题 4 JMS VS AMQP 4.1 JMS 4.2 AMQP 4.3 JMS vs AMQP 5 ...
  • 今天,我们一起来看看,消息队列是个啥? 消息队列是否了解? 消息队列初步来看,是由“消息”和“队列”组成,英文叫做:Message Queue,一般这些玩意都会根据英文名称来个简称,而简称一般就是英文名字的首字母...
  • 消息队列MQ与微消息队列MQTT

    千次阅读 2019-11-10 20:24:35
    文章目录为什么要使用MQ消息队列1. 解耦(可用性)2. 流量削峰3. 数据分发缺点MQ对比传统消息队列RocketMQ和微消息队列MQTT对比 https://www.jianshu.com/p/15081799d66b 为什么要使用MQ消息队列 1. 解耦(可用性) ...
  • 什么是消息队列(Message Queue)?

    千次阅读 2015-12-21 16:26:13
    在计算机科学中,消息队列和邮箱是用于进程间通信或同一进程内的线程间通信的软件工程组件。他们使用一个队列来传播消息——传递控制或者内容。群体传播系统提供类似的功能。 译文:机器学习ML简史 浅谈语音识别、...
  • mq消息队列到底是什么

    千次阅读 2019-01-15 15:03:59
    很多人 不知道 mq 到底干嘛的 那么 就以自己理解说一下 到底什么是mq 为什么会需要消息队列(MQ)? 按照业务场景 也就是 : 当有大量的 insert update 语句 去请求mysql 可能 直接导致无数 行锁 表锁 甚至最后...
  • 一、队列简介 ...由于队列用来传递消息的,所以也称为消息队列。FreeRTOS中的信号量的也是依据队列实现的!所以有必要深入的了解FreeRTOS的队列。 1、数据存储 通常队列采用先进先出(FIFO)的存储缓冲机制,
  • 消息队列是在分布式系统中非常重要的分布式架构,那引入这样的架构到底有什么优势?引入之后又会带来哪些需要考虑的地方? 目前市面上流行的各个消息队列中:ActiveMQ 、RocketMQ 、RabbitMQ 和 Kafka ,我们应该...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 579,823
精华内容 231,929
关键字:

什么是消息队列

友情链接: 114.zip