精华内容
下载资源
问答
  • 协议很常见,只要是通信,就会用到协议,就像...简单说下常见的消息队列协议: 1.AMQP(Advance Message Queuing Protocol) Message(消息):消息服务器处理消息的原子单元,包括一个内容头,一组属性和一个内容...

    协议很常见,只要是通信,就会用到协议,就像我们说话的语言一样,不同的语言连通着不同的人群。
    所以说,消息队列也是一样,想要互相通信,就要使用同一种协议。
    每个协议下的消息队列,都有着不同的角色定义。
    简单说下常见的消息队列协议:

    1.AMQP(Advance Message Queuing Protocol)

    Message(消息):消息服务器处理消息的原子单元,包括一个内容头,一组属性和一个内容体。
    消息有优先级,高优先级的消息在等待同一消息队列时会比低优先级的消息先发送,而且当消息必须被丢弃时,低优先级的消息优先被丢弃。
    使用AMQP协议,消息服务器不能修改内容体和内容头,但可以在内容头上添加额外信息。
    PubLisher(消息生产者):发送消息
    Consumer(消息消费者):消费消息
    Broker(消息代理):消息队列服务器,负责接收客户端连接,路由消息。
    Queue(消息队列):Broker中的一个角色,一个Broker中可以有多个Queue,负责保存消息直到发送给不同的消费者。算是消息的容器。一个消息可以被投入一个或多个队列中,每个队列的消息都会等待消费者连接到这个队列并被取走。
    Exchange(交换路由):Broker中的一个角色,负责接收生产者发送的消息,并路由给服务器中的队列。可以被理解成一个规则表,指明消息该被投到哪个队列中。
    Channel(信道):信道是一条独立的双向数据流通道。为了解决操作系统无法承受每秒建立特别多的TCP连接。

    生产者发送消息时,必须指定消息要被路由到哪些个消息队列中。
    当消息到消息队列中,消息队列会尝试将消息传给消费者,如果失败,消息队列会存储消息并等待消费者。
    如果没有消费者,消息队列将选择性的将消息返回给生产者。
    如果消息别消费掉,消息队列会删除消息,删除的过程或者是及时的,或者是等到消费者消费结果后才删除的。

    AMQP是二进制协议。

    2.MQTT(Message Queuing Telemetry Transport,消息队列遥测传输)

    由IBM开发,现在被广泛用于物联网公司。因为他的特点就是轻量,简单,开放和易于实现。所以他常用于很多计算能力有限、带宽低、网络不可靠的远程通信应用场景。
    Publisher(发布者):消息发布客户端
    Subscriber(订阅者):消息订阅客户端
    Broker(消息代理):消息服务器端
    Application Message(应用消息):指通过网络传输的应用数据,一般包括主题和负载。
    Topic(主题):应用消息的类型,一般消息发布者会确定消息的主题,订阅者根据自己实际情况选择不同的主题进行消息订阅消费。
    Payload(负载):消息订阅者具体接收的内容。

    MQTT协议是通过交换预定义的MQTT控制报文来通信的。
    控制报文内容由三部分组成:固定报头,可变报头和消息体。
    固定报头通过标识不同位的值来确定报文类型,包括发布订阅的一些完成状态等。
    可变报头的内容根据控制报文类型不同而不同,常作为包的标识符。
    消息体也是根据不同的消息类型有着不同的内容。

    MQTT协议中,客户端和服务端是通过请求应答模式通信的。客户端发送一条控制报文数据给服务器,服务器再发送一条控制报文数据给客户端。

    MQTT在发布消息时,有三种Qos等级:至多一次(0级),至少一次(1级),只有一次(2级)。
    至多一次等级最低,客户端只需要将消息发出去即可,这种等级很low,用于消息不重要但特别多,为了减轻通信压力,就不顾质量,只看数量了。
    至少一次等级中等,客户端要保证发出去的消息至少一次被服务端接收到,所以要收到服务端的回应,否则一直发,这种等级一般用于服务端有幂等处理,所以不怕重复消费,还要保证消息不会丢失。
    只有一次等级最高,客户端先发消息过去,然后本地记录一个我已发送,但不确定你是否收到的状态,然后服务端接收到消息后,回给客户端一个我已接收的报文,同时服务端记录一个我不确定你知不知道我已接收的状态,然后客户端收到这个已接收的消息后,就确定服务端收到这个消息了,于是把自己本地记录的已发送未确定的状态删除,同时再给客户端发送一个我已经知道你收到的报文,服务端收到这个报文,也会把自己之前记录的状态删掉,整个一条报文只有一次的通信才算完成,这种等级就比较严格了,但质量上去了,相对低等级的,数量就会相对小些,但可靠就是王道,不多不少才是最好的。
    只有一次的发送和确定,其实思想和三次握手差不多,都是两端互相确认的过程,所以会一来一回的。如果传输过程中出现丢包,都会由发送者重发上一条消息。

    3.STOMP(Streaming Text Orientated Messaging Protocal,流文本定向消息协议)

    STOMP是一个相对简单的文本消息传输协议,主要特点就是简单易懂,没有特别多的套路。
    客户端:既可以是生产者,也可以是消费者
    服务端:消息中心

    4.XMPP(可扩展通信与表达协议)

    基于XML的流式即时通信协议。
    由于用的XML,所以通用性更强。
    客户端:生产者,消费者
    服务端:消息中心
    XMPP的理念是尽可能的简化客户端,复杂的都放在服务端。

    5.JMS(Java Message Service,java消息服务应用程序接口)

    java消息服务应用接口,是一套java API接口。
    JMS是规范,是对AMQP,MQTT,STOMP,XMPP等协议更高一层的抽象。

    展开全文
  • 常见的消息队列中间件介绍 题目 为什么使用消息队列? 消息队列有什么优点和缺点? Kafka、ActiveMQ、RabbitMQ、RocketMQ 都有什么区别,以及适合哪些场景? 消息中间件各种面试题: 消息...

    常见的消息队列中间件介绍

    题目

    • 为什么使用消息队列?
    • 消息队列有什么优点和缺点?
    • Kafka、ActiveMQ、RabbitMQ、RocketMQ 都有什么区别,以及适合哪些场景?

    消息中间件各种面试题:
    消息中间件面试题:消息丢失怎么办?
    消息中间件面试题:消息队列的优缺点,区别
    消息中间件面试题:消息中间件的高可用
    消息中间件面试题:如何保证消息的顺序性
    消息中间件面试题:如何保证消息不被重复消费
    消息中间件面试题:如何解决消息队列的延时以及过期失效问题?消息队列满了以后该怎么处理?有几百万消息持续积压几小时呢?
    消息中间件面试题:如果让你写一个消息队列,该如何进行架构设计?

    问题目录见简书转载博客:https://www.jianshu.com/p/eaafb1581e55

    面试题剖析

    为什么使用消息队列

    先说一下消息队列常见的使用场景吧,其实场景有很多,但是比较核心的有 3 个:解耦异步削峰

    解耦

    看这么个场景。A 系统发送数据到 BCD 三个系统,通过接口调用发送。如果 E 系统也要这个数据呢?那如果 C 系统现在不需要了呢?A 系统负责人几乎崩溃......

     
    mq-1

    在这个场景中,A 系统跟其它各种乱七八糟的系统严重耦合,A 系统产生一条比较关键的数据,很多系统都需要 A 系统将这个数据发送过来。A 系统要时时刻刻考虑 BCDE 四个系统如果挂了该咋办?要不要重发,要不要把消息存起来?头发都白了啊!

    如果使用 MQ,A 系统产生一条数据,发送到 MQ 里面去,哪个系统需要数据自己去 MQ 里面消费。如果新系统需要数据,直接从 MQ 里消费即可;如果某个系统不需要这条数据了,就取消对 MQ 消息的消费即可。这样下来,A 系统压根儿不需要去考虑要给谁发送数据,不需要维护这个代码,也不需要考虑人家是否调用成功、失败超时等情况。

     
    mq-2

    总结:通过一个 MQ,Pub/Sub 发布订阅消息这么一个模型,A 系统就跟其它系统彻底解耦了。

    面试技巧:你需要去考虑一下你负责的系统中是否有类似的场景,就是一个系统或者一个模块,调用了多个系统或者模块,互相之间的调用很复杂,维护起来很麻烦。但是其实这个调用是不需要直接同步调用接口的,如果用 MQ 给它异步化解耦,也是可以的,你就需要去考虑在你的项目里,是不是可以运用这个 MQ 去进行系统的解耦。在简历中体现出来这块东西,用 MQ 作解耦。

    异步

    再来看一个场景,A 系统接收一个请求,需要在自己本地写库,还需要在 BCD 三个系统写库,自己本地写库要 3ms,BCD 三个系统分别写库要 300ms、450ms、200ms。最终请求总延时是 3 + 300 + 450 + 200 = 953ms,接近 1s,用户感觉搞个什么东西,慢死了慢死了。用户通过浏览器发起请求,等待个 1s,这几乎是不可接受的。

     
    mq-3

    一般互联网类的企业,对于用户直接的操作,一般要求是每个请求都必须在 200 ms 以内完成,对用户几乎是无感知的。

    如果使用 MQ,那么 A 系统连续发送 3 条消息到 MQ 队列中,假如耗时 5ms,A 系统从接受一个请求到返回响应给用户,总时长是 3 + 5 = 8ms,对于用户而言,其实感觉上就是点个按钮,8ms 以后就直接返回了,爽!网站做得真好,真快!

     
    mq-4

    削峰

    每天 0:00 到 12:00,A 系统风平浪静,每秒并发请求数量就 50 个。结果每次一到 12:00 ~ 13:00 ,每秒并发请求数量突然会暴增到 5k+ 条。但是系统是直接基于 MySQL 的,大量的请求涌入 MySQL,每秒钟对 MySQL 执行约 5k 条 SQL。

    一般的 MySQL,扛到每秒 2k 个请求就差不多了,如果每秒请求到 5k 的话,可能就直接把 MySQL 给打死了,导致系统崩溃,用户也就没法再使用系统了。

    但是高峰期一过,到了下午的时候,就成了低峰期,可能也就 1w 的用户同时在网站上操作,每秒中的请求数量可能也就 50 个请求,对整个系统几乎没有任何的压力。

    [图片上传失败...(image-6444f7-1548645188187)]

    如果使用 MQ,每秒 5k 个请求写入 MQ,A 系统每秒钟最多处理 2k 个请求,因为 MySQL 每秒钟最多处理 2k 个。A 系统从 MQ 中慢慢拉取请求,每秒钟就拉取 2k 个请求,不要超过自己每秒能处理的最大请求数量就 ok,这样下来,哪怕是高峰期的时候,A 系统也绝对不会挂掉。而 MQ 每秒钟 5k 个请求进来,就 2k 个请求出去,结果就导致在中午高峰期(1 个小时),可能有几十万甚至几百万的请求积压在 MQ 中。

     
    mq-6

    这个短暂的高峰期积压是 ok 的,因为高峰期过了之后,每秒钟就 50 个请求进 MQ,但是 A 系统依然会按照每秒 2k 个请求的速度在处理。所以说,只要高峰期一过,A 系统就会快速将积压的消息给解决掉。

    消息队列有什么优缺点

    优点上面已经说了,就是在特殊场景下有其对应的好处解耦异步削峰

    缺点有以下几个:

    • 系统可用性降低

      系统引入的外部依赖越多,越容易挂掉。本来你就是 A 系统调用 BCD 三个系统的接口就好了,人 ABCD 四个系统好好的,没啥问题,你偏加个 MQ 进来,万一 MQ 挂了咋整,MQ 一挂,整套系统崩溃的,你不就完了?如何保证消息队列的高可用,可以点击这里查看

    • 系统复杂度提高

      硬生生加个 MQ 进来,你怎么[保证消息没有重复消费]?怎么[处理消息丢失的情况]?怎么保证消息传递的顺序性?头大头大,问题一大堆,痛苦不已。

    • 一致性问题

      A 系统处理完了直接返回成功了,人都以为你这个请求就成功了;但是问题是,要是 BCD 三个系统那里,BD 两个系统写库成功了,结果 C 系统写库失败了,咋整?你这数据就不一致了。

    所以消息队列实际是一种非常复杂的架构,你引入它有很多好处,但是也得针对它带来的坏处做各种额外的技术方案和架构来规避掉,做好之后,你会发现,妈呀,系统复杂度提升了一个数量级,也许是复杂了 10 倍。但是关键时刻,用,还是得用的。

    Kafka、ActiveMQ、RabbitMQ、RocketMQ 有什么优缺点?

    特性ActiveMQRabbitMQRocketMQKafka
    单机吞吐量 万级,比 RocketMQ、Kafka 低一个数量级 同 ActiveMQ 10 万级,支撑高吞吐 10 万级,高吞吐,一般配合大数据类的系统来进行实时数据计算、日志采集等场景
    topic 数量对吞吐量的影响     topic 可以达到几百/几千的级别,吞吐量会有较小幅度的下降,这是 RocketMQ 的一大优势,在同等机器下,可以支撑大量的 topic topic 从几十到几百个时候,吞吐量会大幅度下降,在同等机器下,Kafka 尽量保证 topic 数量不要过多,如果要支撑大规模的 topic,需要增加更多的机器资源
    时效性 ms 级 微秒级,这是 RabbitMQ 的一大特点,延迟最低 ms 级 延迟在 ms 级以内
    可用性 高,基于主从架构实现高可用 同 ActiveMQ 非常高,分布式架构 非常高,分布式,一个数据多个副本,少数机器宕机,不会丢失数据,不会导致不可用
    消息可靠性 有较低的概率丢失数据 基本不丢 经过参数优化配置,可以做到 0 丢失 同 RocketMQ
    功能支持 MQ 领域的功能极其完备 基于 erlang 开发,并发能力很强,性能极好,延时很低 MQ 功能较为完善,还是分布式的,扩展性好 功能较为简单,主要支持简单的 MQ 功能,在大数据领域的实时计算以及日志采集被大规模使用

    综上,各种对比之后,有如下建议:

    一般的业务系统要引入 MQ,最早大家都用 ActiveMQ,但是现在确实大家用的不多了,没经过大规模吞吐量场景的验证,社区也不是很活跃,所以大家还是算了吧,我个人不推荐用这个了;

    后来大家开始用 RabbitMQ,但是确实 erlang 语言阻止了大量的 Java 工程师去深入研究和掌控它,对公司而言,几乎处于不可控的状态,但是确实人家是开源的,比较稳定的支持,活跃度也高;

    不过现在确实越来越多的公司,会去用 RocketMQ,确实很不错(阿里出品),但社区可能有突然黄掉的风险,对自己公司技术实力有绝对自信的,推荐用 RocketMQ,否则回去老老实实用 RabbitMQ 吧,人家有活跃的开源社区,绝对不会黄。

    所以中小型公司,技术实力较为一般,技术挑战不是特别高,用 RabbitMQ 是不错的选择;大型公司,基础架构研发实力较强,用 RocketMQ 是很好的选择。如果是大数据领域的实时计算、日志采集等场景,用 Kafka 是业内标准的,绝对没问题,社区活跃度很高,绝对不会黄,何况几乎是全世界这个领域的事实性规范。



    转载于:https://www.cnblogs.com/wuzm/p/11105176.html

    展开全文
  • 消息队列及常见消息队列介绍 一、消息队列(MQ)概述 消息队列(Message Queue),是分布式系统中重要的组件,其通用的使用场景可以简单地描述为: ...当前使用较多的消息队列有RabbitMQ、RocketMQ、ActiveMQ、Kaf...

    消息队列及常见消息队列介绍

    一、消息队列(MQ)概述

    消息队列(Message Queue),是分布式系统中重要的组件,其通用的使用场景可以简单地描述为:

    不需要立即获得结果,但是并发量又需要进行控制的时候,差不多就是需要使用消息队列的时候。

    消息队列主要解决了应用耦合、异步处理、消峰限流等问题。

    当前使用较多的消息队列有RabbitMQ、RocketMQ、ActiveMQ、Kafka、ZeroMQ、MetaMq等,而部分数据库如Redis、Mysql以及phxsql也可实现消息队列的功能。

    二、消息队列使用场景

    消息队列在实际应用中包括如下四个场景:

    • 应用耦合:多应用间通过消息队列对同一消息进行处理,避免调用接口失败导致整个过程失败;
    • 异步处理:多应用对消息队列中同一消息进行处理,应用间并发处理消息,相比串行处理,减少处理时间;
    • 消峰限流:广泛应用于秒杀或抢购活动中,避免流量过大导致应用系统挂掉的情况;
    • 消息驱动的系统:系统分为消息队列、消息生产者、消息消费者,生产者负责产生消息,消费者(可能有多个)负责对消息进行处理;

    下面详细介绍上述四个场景以及消息队列如何在上述四个场景中使用:

    2.1 异步处理

    具体场景:用户为了使用某个应用,进行注册,系统需要发送注册邮件并验证短信。对这两个操作的处理方式有两种:串行及并行。

    (1)串行方式:新注册信息生成后,先发送注册邮件,再发送验证短信;

    在这种方式下,需要最终发送验证短信后再返回给客户端。

    (2)并行处理:新注册信息写入后,由发短信和发邮件并行处理;

    在这种方式下,发短信和发邮件 需处理完成后再返回给客户端。

    假设以上三个子系统处理的时间均为50ms,且不考虑网络延迟,则总的处理时间:

    串行:50+50+50=150ms
    并行:50+50 = 100ms

    若使用消息队列:

    并在写入消息队列后立即返回成功给客户端,则总的响应时间依赖于写入消息队列的时间,而写入消息队列的时间本身是可以很快的,基本可以忽略不计,因此总的处理时间相比串行提高了2倍,相比并行提高了一倍;也就是说消息队列的处理时间大概是50ms

    2.2 应用耦合

    具体场景:用户使用QQ相册上传一张图片,人脸识别系统会对该图片进行人脸识别,一般的做法是,服务器接收到图片后,图片上传系统立即调用人脸识别系统,调用完成后再返回成功,如下图所示:

    该方法有如下缺点:

    • 人脸识别系统被调失败,导致图片上传失败;
    • 延迟高,需要人脸识别系统处理完成后,再返回给客户端,即使用户并不需要立即知道结果;
    • 图片上传系统与人脸识别系统之间互相调用,需要做耦合;

    若使用消息队列:

    客户端上传图片后,图片上传系统将图片信息如uin、批次写入消息队列,直接返回成功;而人脸识别系统则定时从消息队列中取数据,完成对新增图片的识别。
    此时图片上传系统并不需要关心人脸识别系统是否对这些图片信息的处理、以及何时对这些图片信息进行处理。事实上,由于用户并不需要立即知道人脸识别结果,人脸识别系统可以选择不同的调度策略,按照闲时、忙时、正常时间,对队列中的图片信息进行处理。

    2.3 消峰限流

    具体场景:购物网站开展秒杀活动,一般由于瞬时访问量过大,服务器接收过大,会导致流量暴增,相关系统无法处理请求甚至崩溃。而加入消息队列后,系统可以从消息队列中取数据,相当于消息队列做了一次缓冲。

    该方法有如下优点:

    1. 请求先入消息队列,而不是由业务处理系统直接处理,做了一次缓冲,极大地减少了业务处理系统的压力;
    2. 队列长度可以做限制,事实上,秒杀时,后入队列的用户无法秒杀到商品,这些请求可以直接被抛弃,返回活动已结束或商品已售完信息;

    2.4 消息驱动的系统

    具体场景:用户新上传了一批照片, 人脸识别系统需要对这个用户的所有照片进行聚类,聚类完成后由对账系统重新生成用户的人脸索引(加快查询)。这三个子系统间由消息队列连接起来,前一个阶段的处理结果放入队列中,后一个阶段从队列中获取消息继续处理。

    该方法有如下优点:

    • 避免了直接调用下一个系统导致当前系统失败;
    • 每个子系统对于消息的处理方式可以更为灵活,可以选择收到消息时就处理,可以选择定时处理,也可以划分时间段按不同处理速度处理;

    三、消息队列的两种模式

    消息队列包括两种模式,点对点模式(point to point, queue)和发布/订阅模式(publish/subscribe,topic)。

    3.1 点对点模式

    点对点模式下包括三个角色:

    • 消息队列
    • 发送者 (生产者)
    • 接收者(消费者)

    消息发送者生产消息发送到queue中,然后消息接收者从queue中取出并且消费消息。消息被消费以后,queue中不再有存储,所以消息接收者不可能消费到已经被消费的消息。

    点对点模式特点:

    • 每个消息只有一个接收者(Consumer)(即一旦被消费,消息就不再在消息队列中);
    • 发送者和接收者间没有依赖性,发送者发送消息之后,不管有没有接收者在运行,都不会影响到发送者下次发送消息;
    • 接收者在成功接收消息之后需向队列应答成功,以便消息队列删除当前接收的消息;

    3.2 发布/订阅模式

    发布/订阅模式下包括三个角色:

    • 角色主题(Topic)
    • 发布者(Publisher)
    • 订阅者(Subscriber)

    发布者将消息发送到Topic,系统将这些消息传递给多个订阅者。

    发布/订阅模式特点:

    • 每个消息可以有多个订阅者;
    • 发布者和订阅者之间有时间上的依赖性。针对某个主题(Topic)的订阅者,它必须创建一个订阅者之后,才能消费发布者的消息。
    • 为了消费消息,订阅者需要提前订阅该角色主题,并保持在线运行;

    四、常用消息队列介绍

    本部分主要介绍四种常用的消息队列(RabbitMQ/ActiveMQ/RocketMQ/Kafka)的主要特性、优点、缺点。

    4.1 RabbitMQ

    RabbitMQ 2007年发布,是一个在AMQP(高级消息队列协议)基础上完成的,可复用的企业消息系统,是当前最主流的消息中间件之一。

    主要特性:

    1. 可靠性: 提供了多种技术可以让你在性能和可靠性之间进行权衡。这些技术包括持久性机制、投递确认、发布者证实和高可用性机制;
    2. 灵活的路由: 消息在到达队列前是通过交换机进行路由的。RabbitMQ为典型的路由逻辑提供了多种内置交换机类型。如果你有更复杂的路由需求,可以将这些交换机组合起来使用,你甚至可以实现自己的交换机类型,并且当做RabbitMQ的插件来使用;
    3. 消息集群:在相同局域网中的多个RabbitMQ服务器可以聚合在一起,作为一个独立的逻辑代理来使用;
    4. 队列高可用:队列可以在集群中的机器上进行镜像,以确保在硬件问题下还保证消息安全;
    5. 多种协议的支持:支持多种消息队列协议;
    6. 服务器端用Erlang语言编写,支持只要是你能想到的所有编程语言;
    7. 管理界面: RabbitMQ有一个易用的用户界面,使得用户可以监控和管理消息Broker的许多方面;
    8. 跟踪机制:如果消息异常,RabbitMQ提供消息跟踪机制,使用者可以找出发生了什么;
    9. 插件机制:提供了许多插件,来从多方面进行扩展,也可以编写自己的插件;

    使用RabbitMQ需要:

    • ErLang语言包
    • RabbitMQ安装包

    RabbitMQ可以运行在Erlang语言所支持的平台之上:

    Solaris
    BSD
    Linux
    MacOSX
    TRU64
    Windows NT/2000/XP/Vista/Windows 7/Windows 8
    Windows Server 2003/2008/2012
    Windows 95, 98
    VxWorks

    优点:

    1. 由于erlang语言的特性,mq 性能较好,高并发;
    2. 健壮、稳定、易用、跨平台、支持多种语言、文档齐全;
    3. 有消息确认机制和持久化机制,可靠性高;
    4. 高度可定制的路由;
    5. 管理界面较丰富,在互联网公司也有较大规模的应用;
    6. 社区活跃度高;

    缺点:

    1. 尽管结合erlang语言本身的并发优势,性能较好,但是不利于做二次开发和维护;
    2. 实现了代理架构,意味着消息在发送到客户端之前可以在中央节点上排队。此特性使得RabbitMQ易于使用和部署,但是使得其运行速度较慢,因为中央节点增加了延迟,消息封装后也比较大;
    3. 需要学习比较复杂的接口和协议,学习和维护成本较高;

    4.2 ActiveMQ

    ActiveMQ是由Apache出品,ActiveMQ 是一个完全支持JMS1.1和J2EE 1.4规范的 JMS Provider实现。它非常快速,支持多种语言的客户端和协议,而且可以非常容易的嵌入到企业的应用环境中,并有许多高级功能。

    主要特性:

    1. 服从 JMS 规范:JMS 规范提供了良好的标准和保证,包括:同步或异步的消息分发,一次和仅一次的消息分发,消息接收和订阅等等。遵从 JMS 规范的好处在于,不论使用什么 JMS 实现提供者,这些基础特性都是可用的;
    2. 连接性:ActiveMQ 提供了广泛的连接选项,支持的协议有:HTTP/S,IP 多播,SSL,STOMP,TCP,UDP,XMPP等等。对众多协议的支持让 ActiveMQ 拥有了很好的灵活性。
    3. 支持的协议种类多:OpenWire、STOMP、REST、XMPP、AMQP ;
    4. 持久化插件和安全插件:ActiveMQ 提供了多种持久化选择。而且,ActiveMQ 的安全性也可以完全依据用户需求进行自定义鉴权和授权;
    5. 支持的客户端语言种类多:除了 Java 之外,还有:C/C++,.NET,Perl,PHP,Python,Ruby;
    6. 代理集群:多个 ActiveMQ 代理可以组成一个集群来提供服务;
    7. 异常简单的管理:ActiveMQ 是以开发者思维被设计的。所以,它并不需要专门的管理员,因为它提供了简单又使用的管理特性。有很多中方法可以监控 ActiveMQ 不同层面的数据,包括使用在 JConsole 或者 ActiveMQ 的Web Console 中使用 JMX,通过处理 JMX 的告警消息,通过使用命令行脚本,甚至可以通过监控各种类型的日志。

    使用ActiveMQ需要:

    • Java JDK
    • ActiveMQ安装包

    ActiveMQ可以运行在Java语言所支持的平台之上。

    优点:

    1. 跨平台(JAVA编写与平台无关有,ActiveMQ几乎可以运行在任何的JVM上)
    2. 可以用JDBC:可以将数据持久化到数据库。虽然使用JDBC会降低ActiveMQ的性能,但是数据库一直都是开发人员最熟悉的存储介质。将消息存到数据库,看得见摸得着。而且公司有专门的DBA去对数据库进行调优,主从分离;
    3. 支持JMS :支持JMS的统一接口;
    4. 支持自动重连;
    5. 有安全机制:支持基于shiro,jaas等多种安全配置机制,可以对Queue/Topic进行认证和授权。
    6. 监控完善:拥有完善的监控,包括Web Console,JMX,Shell命令行,Jolokia的REST API;
    7. 界面友善:提供的Web Console可以满足大部分情况,还有很多第三方的组件可以使用,如hawtio;
      缺点:

    8. 社区活跃度不及RabbitMQ高;

    9. 根据其他用户反馈,会出莫名其妙的问题,会丢失消息;
    10. 目前重心放到activemq6.0产品-apollo,对5.x的维护较少;
    11. 不适合用于上千个队列的应用场景;

    4.3 RocketMQ

    RocketMQ出自 阿里公司的开源产品,用 Java 语言实现,在设计时参考了 Kafka,并做出了自己的一些改进,消息可靠性上比 Kafka 更好。RocketMQ在阿里集团被广泛应用在订单,交易,充值,流计算,消息推送,日志流式处理,binglog分发等场景。

    主要特性:

    1. 是一个队列模型的消息中间件,具有高性能、高可靠、高实时、分布式特点;
    2. Producer、Consumer、队列都可以分布式;
    3. Producer向一些队列轮流发送消息,队列集合称为Topic,Consumer如果做广播消费,则一个consumer实例消费这个Topic对应的所有队列,如果做集群消费,则多个Consumer实例平均消费这个topic对应的队列集合;
    4. 能够保证严格的消息顺序;
    5. 提供丰富的消息拉取模式;
    6. 高效的订阅者水平扩展能力;
    7. 实时的消息订阅机制;
    8. 亿级消息堆积能力;
    9. 较少的依赖;

    使用RocketMQ需要:

    • Java JDK
    • 安装git、Maven
    • RocketMQ安装包

    RocketMQ可以运行在Java语言所支持的平台之上。

    优点:

    1. 单机支持 1 万以上持久化队列
    2. RocketMQ 的所有消息都是持久化的,先写入系统 PAGECACHE,然后刷盘,可以保证内存与磁盘都有一份数据,
      访问时,直接从内存读取。
    3. 模型简单,接口易用(JMS 的接口很多场合并不太实用);
    4. 性能非常好,可以大量堆积消息在broker中;
    5. 支持多种消费,包括集群消费、广播消费等。
    6. 各个环节分布式扩展设计,主从HA;
    7. 开发度较活跃,版本更新很快。

    缺点:

    支持的客户端语言不多,目前是java及c++,其中c++不成熟;
    RocketMQ社区关注度及成熟度也不及前两者;
    没有web管理界面,提供了一个CLI(命令行界面)管理工具带来查询、管理和诊断各种问题;
    没有在 mq 核心中去实现JMS等接口;

    4.4 Kafka

    Apache Kafka是一个分布式消息发布订阅系统。它最初由LinkedIn公司基于独特的设计实现为一个分布式的提交日志系统( a distributed commit log),,之后成为Apache项目的一部分。Kafka系统快速、可扩展并且可持久化。它的分区特性,可复制和可容错都是其不错的特性。

    主要特性:

    1. 快速持久化,可以在O(1)的系统开销下进行消息持久化;
    2. 高吞吐,在一台普通的服务器上既可以达到10W/s的吞吐速率;
    3. .完全的分布式系统,Broker、Producer、Consumer都原生自动支持分布式,自动实现负载均衡;
    4. 支持同步和异步复制两种HA;
    5. 支持数据批量发送和拉取;
    6. zero-copy:减少IO操作步骤;
    7. 数据迁移、扩容对用户透明;
    8. 无需停机即可扩展机器;
    9. 其他特性:严格的消息顺序、丰富的消息拉取模型、高效订阅者水平扩展、实时的消息订阅、亿级的消息堆积能力、定期删除机制;

    使用Kafka需要:

    • Java JDK
    • Kafka安装包

    优点:

    1. 客户端语言丰富,支持java、.net、php、ruby、python、go等多种语言;
    2. 性能卓越,单机写入TPS约在百万条/秒,消息大小10个字节;
    3. 提供完全分布式架构, 并有replica机制, 拥有较高的可用性和可靠性, 理论上支持消息无限堆积;
    4. 支持批量操作;
    5. 消费者采用Pull方式获取消息, 消息有序, 通过控制能够保证所有消息被消费且仅被消费一次;
    6. 有优秀的第三方Kafka Web管理界面Kafka-Manager;
    7. 在日志领域比较成熟,被多家公司和多个开源项目使用;

    缺点:

    1. Kafka单机超过64个队列/分区,Load会发生明显的飙高现象,队列越多,load越高,发送消息响应时间变长
    2. 使用短轮询方式,实时性取决于轮询间隔时间;
    3. 消费失败不支持重试;
    4. 支持消息顺序,但是一台代理宕机后,就会产生消息乱序;
    5. 社区更新较慢;

    4.5 RabbitMQ/ActiveMQ/RocketMQ/Kafka对比

    这里列举了上述四种消息队列的差异对比:

    结论:

    Kafka在于分布式架构,RabbitMQ基于AMQP协议来实现,RocketMQ/思路来源于kafka,改成了主从结构,在事务性可靠性方面做了优化。广泛来说,电商、金融等对事务性要求很高的,可以考虑RabbitMQ和RocketMQ,对性能要求高的可考虑Kafka。

    五、参考资料:

    5.1 消息队列:

    1. 大型网站架构之分布式消息队列 http://blog.csdn.net/shaobingj126/article/details/50585035
    2. 消息队列的使用场景 https://www.zhihu.com/question/34243607/answer/127666030
    3. 浅谈异步消息队列模型 http://www.cnblogs.com/sunkeydev/p/5248855.html
    4. 消息队列的两种模式 http://blog.csdn.net/heyutao007/article/details/50131089

    5.2 RabbitMQ

    1. RabbitMQ主页 https://www.rabbitmq.com/
    2. RabbitMQ学习教程 https://www.rabbitmq.com/getstarted.html
    3. 专栏:RabbitMQ从入门到精通 http://blog.csdn.net/column/details/rabbitmq.html
    4. RabbitMQ能为你做些什么 http://rabbitmq.mr-ping.com/description.html
    5. RabbitMQ指南(1)-特性及功能 https://blog.zenfery.cc/archives/79.html

    5.3 ActiveMQ

    1. ActiveMQ主页 http://activemq.apache.org/
    2. Apache ActiveMQ介绍 http://jfires.iteye.com/blog/1187688
    3. ActiveMQ的简介与安装 http://blog.csdn.net/sl1992/article/details/72824562
    4. ActiveMQ 和消息简介 http://www.cnblogs.com/craftsman-gao/p/7002605.html

    5.4 RocketMQ

    1. 主页 https://github.com/alibaba/RocketMQ
    2. RocketMQ 原理简介 http://alibaba.github.io/RocketMQ-docs/document/design/RocketMQ_design.pdf
    3. RocketMQ与kafka对比(18项差异) http://jm.taobao.org/2016/03/24/rmq-vs-kafka/

    5.5 Kafka

    1.Kafka主页: http://kafka.apache.org/

    1. Kafka特性 http://www.cnblogs.com/lsx1993/p/4847719.html
    2. Kafka客户端支持语言 https://cwiki.apache.org/confluence/display/KAFKA/Clients

    5.6 RabbitMQ/ActiveMQ/RocketMQ/Kafka对比

    1. RocketMQ,队列选型 http://www.zmannotes.com/index.php/2016/01/17/rocketmq/
    2. RabbitMQ和Kafka http://www.dongcoder.com/detail-416804.html
    3. 即时通信RabbitMQ二-性能测试 http://www.jianshu.com/p/d31ae9e3bfb6
    4. RabbitMq、ActiveMq、ZeroMq、kafka之间的比较,资料汇总 http://blog.csdn.net/linsongbin1/article/details/47781187
    5. 消息队列软件产品大比拼 http://www.cnblogs.com/amityat/archive/2011/08/31/2160293.html

    总结:

    消息队列利用高效可靠的消息传递机制进行平台无关的数据交流,并基于数据通信来进行分布式系统的集成。目前业界有很多的MQ产品,例如RabbitMQ、RocketMQ、ActiveMQ、Kafka、ZeroMQ、MetaMq等,也有直接使用数据库redis充当消息队列的案例。而这些消息队列产品,各有侧重,在实际选型时,需要结合自身需求及MQ产品特征,综合考虑。

     

    原文链接:https://cloud.tencent.com/community/article/129032

    展开全文
  • 面试题剖析为什么使用消息队列先说一下消息队列常见的使用场景吧,其实场景有很多,但是比较核心的有 3 个:解耦、异步、削峰。解耦看这么个场景。A 系统发送数据到 BCD 三个系统,通过接口调用发送。如果 E 系统也...

    题目

    为什么使用消息队列?

    消息队列有什么优点和缺点?

    Kafka、ActiveMQ、RabbitMQ、RocketMQ 都有什么区别,以及适合哪些场景?

    面试题剖析

    为什么使用消息队列

    先说一下消息队列常见的使用场景吧,其实场景有很多,但是比较核心的有 3 个:解耦、异步、削峰。

    解耦

    看这么个场景。A 系统发送数据到 BCD 三个系统,通过接口调用发送。如果 E 系统也要这个数据呢?那如果 C 系统现在不需要了呢?A 系统负责人几乎崩溃......

    mq-1

    在这个场景中,A 系统跟其它各种乱七八糟的系统严重耦合,A 系统产生一条比较关键的数据,很多系统都需要 A 系统将这个数据发送过来。A 系统要时时刻刻考虑 BCDE 四个系统如果挂了该咋办?要不要重发,要不要把消息存起来?头发都白了啊!

    如果使用 MQ,A 系统产生一条数据,发送到 MQ 里面去,哪个系统需要数据自己去 MQ 里面消费。如果新系统需要数据,直接从 MQ 里消费即可;如果某个系统不需要这条数据了,就取消对 MQ 消息的消费即可。这样下来,A 系统压根儿不需要去考虑要给谁发送数据,不需要维护这个代码,也不需要考虑人家是否调用成功、失败超时等情况。

    mq-2

    总结:通过一个 MQ,Pub/Sub 发布订阅消息这么一个模型,A 系统就跟其它系统彻底解耦了。

    面试技巧:你需要去考虑一下你负责的系统中是否有类似的场景,就是一个系统或者一个模块,调用了多个系统或者模块,互相之间的调用很复杂,维护起来很麻烦。但是其实这个调用是不需要直接同步调用接口的,如果用 MQ 给它异步化解耦,也是可以的,你就需要去考虑在你的项目里,是不是可以运用这个 MQ 去进行系统的解耦。在简历中体现出来这块东西,用 MQ 作解耦。

    异步

    再来看一个场景,A 系统接收一个请求,需要在自己本地写库,还需要在 BCD 三个系统写库,自己本地写库要 3ms,BCD 三个系统分别写库要 300ms、450ms、200ms。最终请求总延时是 3 + 300 + 450 + 200 = 953ms,接近 1s,用户感觉搞个什么东西,慢死了慢死了。用户通过浏览器发起请求,等待个 1s,这几乎是不可接受的。

    mq-3

    一般互联网类的企业,对于用户直接的操作,一般要求是每个请求都必须在 200 ms 以内完成,对用户几乎是无感知的。

    如果使用 MQ,那么 A 系统连续发送 3 条消息到 MQ 队列中,假如耗时 5ms,A 系统从接受一个请求到返回响应给用户,总时长是 3 + 5 = 8ms,对于用户而言,其实感觉上就是点个按钮,8ms 以后就直接返回了,爽!网站做得真好,真快!

    mq-4

    削峰

    每天 0:00 到 12:00,A 系统风平浪静,每秒并发请求数量就 50 个。结果每次一到 12:00 ~ 13:00 ,每秒并发请求数量突然会暴增到 5k+ 条。但是系统是直接基于 MySQL 的,大量的请求涌入 MySQL,每秒钟对 MySQL 执行约 5k 条 SQL。

    一般的 MySQL,扛到每秒 2k 个请求就差不多了,如果每秒请求到 5k 的话,可能就直接把 MySQL 给打死了,导致系统崩溃,用户也就没法再使用系统了。

    但是高峰期一过,到了下午的时候,就成了低峰期,可能也就 1w 的用户同时在网站上操作,每秒中的请求数量可能也就 50 个请求,对整个系统几乎没有任何的压力。

    [图片上传失败...(image-6444f7-1548645188187)]

    如果使用 MQ,每秒 5k 个请求写入 MQ,A 系统每秒钟最多处理 2k 个请求,因为 MySQL 每秒钟最多处理 2k 个。A 系统从 MQ 中慢慢拉取请求,每秒钟就拉取 2k 个请求,不要超过自己每秒能处理的最大请求数量就 ok,这样下来,哪怕是高峰期的时候,A 系统也绝对不会挂掉。而 MQ 每秒钟 5k 个请求进来,就 2k 个请求出去,结果就导致在中午高峰期(1 个小时),可能有几十万甚至几百万的请求积压在 MQ 中。

    mq-6

    这个短暂的高峰期积压是 ok 的,因为高峰期过了之后,每秒钟就 50 个请求进 MQ,但是 A 系统依然会按照每秒 2k 个请求的速度在处理。所以说,只要高峰期一过,A 系统就会快速将积压的消息给解决掉。

    消息队列有什么优缺点

    优点上面已经说了,就是在特殊场景下有其对应的好处,解耦、异步、削峰。

    缺点有以下几个:

    系统可用性降低

    系统引入的外部依赖越多,越容易挂掉。本来你就是 A 系统调用 BCD 三个系统的接口就好了,人 ABCD 四个系统好好的,没啥问题,你偏加个 MQ 进来,万一 MQ 挂了咋整,MQ 一挂,整套系统崩溃的,你不就完了?如何保证消息队列的高可用,可以点击这里查看。

    系统复杂度提高

    硬生生加个 MQ 进来,你怎么[保证消息没有重复消费]?怎么[处理消息丢失的情况]?怎么保证消息传递的顺序性?头大头大,问题一大堆,痛苦不已。

    一致性问题

    A 系统处理完了直接返回成功了,人都以为你这个请求就成功了;但是问题是,要是 BCD 三个系统那里,BD 两个系统写库成功了,结果 C 系统写库失败了,咋整?你这数据就不一致了。

    所以消息队列实际是一种非常复杂的架构,你引入它有很多好处,但是也得针对它带来的坏处做各种额外的技术方案和架构来规避掉,做好之后,你会发现,妈呀,系统复杂度提升了一个数量级,也许是复杂了 10 倍。但是关键时刻,用,还是得用的。

    Kafka、ActiveMQ、RabbitMQ、RocketMQ 有什么优缺点?

    特性ActiveMQRabbitMQRocketMQKafka

    单机吞吐量

    万级,比 RocketMQ、Kafka 低一个数量级

    同 ActiveMQ

    10 万级,支撑高吞吐

    10 万级,高吞吐,一般配合大数据类的系统来进行实时数据计算、日志采集等场景

    topic 数量对吞吐量的影响

    topic 可以达到几百/几千的级别,吞吐量会有较小幅度的下降,这是 RocketMQ 的一大优势,在同等机器下,可以支撑大量的 topic

    topic 从几十到几百个时候,吞吐量会大幅度下降,在同等机器下,Kafka 尽量保证 topic 数量不要过多,如果要支撑大规模的 topic,需要增加更多的机器资源

    时效性

    ms 级

    微秒级,这是 RabbitMQ 的一大特点,延迟最低

    ms 级

    延迟在 ms 级以内

    可用性

    高,基于主从架构实现高可用

    同 ActiveMQ

    非常高,分布式架构

    非常高,分布式,一个数据多个副本,少数机器宕机,不会丢失数据,不会导致不可用

    消息可靠性

    有较低的概率丢失数据

    基本不丢

    经过参数优化配置,可以做到 0 丢失

    同 RocketMQ

    功能支持

    MQ 领域的功能极其完备

    基于 erlang 开发,并发能力很强,性能极好,延时很低

    MQ 功能较为完善,还是分布式的,扩展性好

    功能较为简单,主要支持简单的 MQ 功能,在大数据领域的实时计算以及日志采集被大规模使用

    综上,各种对比之后,有如下建议:

    一般的业务系统要引入 MQ,最早大家都用 ActiveMQ,但是现在确实大家用的不多了,没经过大规模吞吐量场景的验证,社区也不是很活跃,所以大家还是算了吧,我个人不推荐用这个了;

    后来大家开始用 RabbitMQ,但是确实 erlang 语言阻止了大量的 Java 工程师去深入研究和掌控它,对公司而言,几乎处于不可控的状态,但是确实人家是开源的,比较稳定的支持,活跃度也高;

    不过现在确实越来越多的公司,会去用 RocketMQ,确实很不错(阿里出品),但社区可能有突然黄掉的风险,对自己公司技术实力有绝对自信的,推荐用 RocketMQ,否则回去老老实实用 RabbitMQ 吧,人家有活跃的开源社区,绝对不会黄。

    所以中小型公司,技术实力较为一般,技术挑战不是特别高,用 RabbitMQ 是不错的选择;大型公司,基础架构研发实力较强,用 RocketMQ 是很好的选择。如果是大数据领域的实时计算、日志采集等场景,用 Kafka 是业内标准的,绝对没问题,社区活跃度很高,绝对不会黄,何况几乎是全世界这个领域的事实性规范。

    展开全文
  • 使用较多的消息队列有ActiveMQ,RabbitMQ,ZeroMQ,Kafka,MetaMQ,RocketMQ 二、消息队列应用场景 以下介绍消息队列在实际应用中常用的使用场景。异步处理,应用解耦,流量削锋和消息通讯四个场景 ...
  • 这是网上的一篇教程写的很好,不知原作者是谁,没法注明出处,我看的时候也是别人转载的,这里就注明一下那篇转载的地址:...使用较多的消息队列有ActiveMQ,RabbitMQ
  • 几种常见的消息队列

    2018-11-07 11:14:00
    常见的消息对队如下:一、MSMQ:是微软的产品 应用于.net框架二、ActiveMQ:是apache的产品 做业务用图广泛三、RabbitQM:是爱立信的产品(早期手机生产厂商)基于erlang语言(函数式编程大数据 scala语言)四、ZeroMQ:...
  • 一.上图 ...二....activeMQ使用越来越少,无法应用于大规模...rocketMQ 10万级吞吐量 ,是阿里发布中间件,适合具有研发能力大公司开发项目 kafaka 具有大规模吞吐能力,主要用于大数据实时计算与日志记录 ...
  • 一些常见的消息队列面试题整理

    千次阅读 2019-03-29 10:24:52
    你们公司生产环境用是什么消息中间件? RabbitMQ、ActiveMQ、RocketMQ、Kafka优缺点与应用场景 为什么在你们系统架构中要引入消息中间件? 系统解耦、异步调用、流量削峰 说说系统架构引入消息中间件有什么...
  • 接下来我们简单了解一下消息中间件应用场景: 1.其实我们在双11时候,当我们凌晨大量秒杀和抢购商品,然后去结算时候,就会发现,界面会提醒我们,让我们稍等,以及一些友好图片文字提醒。而不是像前几...
  • 最近组内需要做流水server的选型升级,这里对消息队列及常见的消息队列进行了一次调研,整理了相关资料,分享给大家。 一、消息队列(MQ)概述 消息队列(Message Queue),是分布式系统中重要的组件,其通用的使用...
  • 最近组内需要做流水server的选型升级,这里对消息队列及常见的消息队列进行了一次调研,整理了相关资料,分享给大家。 一、消息队列(MQ)概述 消息队列(Message Queue),是分布式系统中重要的组件,其通用的使用...
  • 常见消息队列对比

    2019-08-08 16:57:39
    本文主要从多个方面对比几种常见的消息队列 消息队列对比表 对比方向 ActiveMQ RabbitMQ RocketMQ Kafka 吞吐量 万级(最差) 万级 十万级 百万级 可用性 基于主从实现高可用 基于主从实现高可用 基于分布式...
  • 一、消息队列(MQ)概述 消息队列(Message Queue),是分布式系统中重要的组件,其通用的使用场景可以简单地描述为: ...当前使用较多的消息队列有RabbitMQ、RocketMQ、ActiveMQ、Kafka、ZeroMQ、MetaM...
  • MQ消息队列的常见用法

    千次阅读 2019-05-16 14:38:56
    目前常见的消息队列有三种:ActiveMQ,RabbitMQ,Kafka 今天我想来梳理一下MQ消息队列的具体常见用法: 1.异步处理 用户注册之后,需要发短信和加积分,注册信息写入数据库后,通过异步消息,让短信服务和积分服务去...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 2,795
精华内容 1,118
关键字:

常见的消息队列