精华内容
下载资源
问答
  • 常用mq比较

    千次阅读 2017-02-17 10:13:46
    常用MQ产品比较 ActiveMQ Joram HornetQ OpenMQ MuleMQ SonicMQ RabbitMQ ZeroMQ

    常用MQ产品比较


    ActiveMQJoramHornetQOpenMQMuleMQSonicMQRabbitMQZeroMQ
    关注度
    成熟度成熟比较成熟比较成熟比较成熟新产品无成功案例成熟成熟不成熟
    所属社区/公司ApacheOW2JbossSunMuleProgress

    社区活跃度
    文档
    特点功能齐全,被大量开源项目使用
    在Linux平台上直接调用操作系统的AIO,性能得到很大的提升
    性能非常好,与MuleESB无缝整合性能优越的商业MQ由于Erlang语言的并发能力,性能很好低延时,高性能,最高43万条消息每秒
    授权方式开源开源开源开源商业商业开源开源
    开发语言JavaJavaJavaJavaJavaJavaErlangC
    支持的协议OpenWire、STOMP、REST、XMPP、AMQPJMSJMSJMSJMSJMSAMQPTCP、UDP
    客户端支持语言Java、C、C++、Python、PHP、Perl、.net等JavaJavaJavaJavaJava、C、C++、.netJava、C、C++、Python、PHP、Perl等python、java、php、.net等
    持久化内存、文件、数据库内存、文件内存、文件内存、文件内存、文件内存、文件、数据库内存、文件在消息发送端保存
    事务支持支持支持支持支持支持不支持不支持
    集群支持支持支持支持支持支持支持不支持
    负载均衡支持支持支持支持支持支持支持不支持
    管理界面一般
    一般一般一般
    部署方式独立、嵌入独立、嵌入独立、嵌入独立、嵌入独立独立独立独立
    评价成熟稳定,开源首选依赖容器,不适合跨语言调用推出的时间不长,尚无使用案例,不适合跨语言调用依赖容器,不适合跨语言调用推出的时间不长,无成功案例,目前仅支持Java成熟稳定Queue的数量大于50后,高并发下无法持续稳定的提供服务不支持事务、集群,并且消息不能在服务端持久化 

    节选自:http://blog.csdn.net/apanious/article/details/51014396

    展开全文
  • Java常用MQ比较

    2020-01-14 16:33:43
    kafka的集群依赖与zookeeper, zookeeper支持热拓展, 所有的broker, 消费者, 分区都可以动态移除, 而无需关闭服务, 与不依赖zookeeper集群的mq相比, 这是最大的优势. rabbitmq:支持简单集群,'复制’模式,对 高级...
    KafkaRabbitMQRocketMQActiveMQ
    资料文档中。有kafka作者自己写的书,网上资料也有一些稍微长一点的文本多。有一些不错的书,网上资料多少。没有专门写rocketmq的书,网上的资料良莠不齐,官方文档很简洁,但是对技术细节没有过多的描述
    开发语言ScalaErlangjavajava
    支持的协议自己定义的一套…(基于TCP)AMQP自己定义的一套…OpenWire、STOMP、REST、XMPP、AMQP
    消息存储Kafka:内存、磁盘、数据库。支持大量堆积。kafka的最小存储单元是分区,一个topic包含多个分区,kafka创建主题时,这些分区会被分配在多个服务器上,通常一个broker一台服务器。 分区首领会均匀地分布在不同的服务器上,分区副本也会均匀的分布在不同的服务器上,确保负载均衡和高可用性,当新的broker加入集群的时候,部分副本会被移动到新的broker上。 根据配置文件中的目录清单,kafka会把新的分区分配给目录清单里分区数最少的目录。 默认情况下,分区器使用轮询算法把消息均衡地分布在同一个主题的不同分区中,对于发送时指定了key的情况,会根据key的hashcode取模后的值存到对应的分区中。**内存、磁盘。支持少量堆积。**rabbitmq的消息分为持久化的消息和非持久化消息,不管是持久化的消息还是非持久化的消息都可以写入到磁盘。持久化的消息在到达队列时就写入到磁盘,并且如果可以,持久化的消息也会在内存中保存一份备份,这样可以提高一定的性能,当内存吃紧的时候会从内存中清除。非持久化的消息一般只存在于内存中,在内存吃紧的时候会被换入到磁盘中,以节省内存。引入镜像队列机制,可将重要队列“复制”到集群中的其他broker上,保证这些队列的消息不会丢失。配置镜像的队列,都包含一个主节点master和多个从节点slave,如果master失效,加入时间最长的slave会被提升为新的master,除发送消息外的所有动作都向master发送,然后由master将命令执行结果广播给各个slave,rabbitmq会让master均匀地分布在不同的服务器上,而同一个队列的slave也会均匀地分布在不同的服务器上,保证负载均衡和高可用性。磁盘。支持大量堆积 commitLog文件存放实际的消息数据,每个commitLog上限是1G,满了之后会自动新建一个commitLog文件保存数据。ConsumeQueue队列只存放offset、size、tagcode,非常小,分布在多个broker上。ConsumeQueue相当于CommitLog的索引文件,消费者消费时会从consumeQueue中查找消息在commitLog中的offset,再去commitLog中查找元数据。ConsumeQueue存储格式的特性,保证了写过程的顺序写盘(写CommitLog文件),大量数据IO都在顺序写同一个commitLog,满1G了再写新的。加上rocketmq是累计4K才强制从PageCache中刷到磁盘(缓存),所以高并发写性能突出。内存、磁盘、数据库。支持少量堆积
    消息事务支持支持。客户端将信道设置为事务模式,只有当消息被rabbitMq接收,事务才能提交成功,否则在捕获异常后进行回滚。使用事务会使得性能有所下降支持支持
    负载均衡
    集群方式
    管理界面一般一般
    可用性非常高(分布式)高(主从)非常高(分布式)高(主从)
    消息重复支持at least once、at most once支持at least once、at most once支持at least once支持at least once
    吞吐量TPS(十万级,17万)极大Kafka按批次发送消息和消费消息。发送端将多个小消息合并,批量发向Broker,消费端每次取出一个批次的消息批量处理(万级别,5万)比较大(十万级别)大 rocketMQ接收端可以批量消费消息,可以配置每次消费的消息数,但是发送端不是批量发送(万级别)比较大
    订阅形式和消息分发
    顺序消息设置生产者的max.in.flight.requests.per.connection为1, 可以保证消息是按照发送顺序写入服务器的,即使发生了重试. Kafka保证同一个分区的消息是有序的, 但是这种分两种情况: key为null, 消息逐个写入不同的主机分区中, 但是对于每个分区依然是有序的. key不为null, 消息被写入同一个分区,这个分区的消息都是有序的不支持不支持不支持
    消息确认支持支持支持支持
    消息回溯支持指定分区offset位置的回溯不支持支持指定时间点的回溯不支持
    消息重试
    并发度

    负载均衡

    Kafka: 支持负载均衡

    1. 一个broker通常就是一台服务器节点. 对于同一个Topic的不同分区, Kafka会尽力将这些分区分布刀不同的Broker服务器上, zookeeper保存了broker, 主题和分区的元数据信息. 分区首领会处理来自客户端的生产请求, Kafka分区首领会被分配到不同的zookeeper服务器上, 让不同的broker服务器共同分担任务.

      每一个broker都缓存元数据信息, 客户端可以从任意一个broker获取元数据信息并缓存起来, 根据元数据信息知道要往哪里发送请求.

      1. Kafka的消费者组订阅同一个topic, 会尽可能地使得每一个消费者分配到相同数量的分区, 分摊负载.

      2. 当消费者组订阅了同一个topic, 还会促发再均衡, 为每一个消费者重新分配分区, 分摊负责。

        Kafka的负载均衡大部分是自动完成的, 分区的创建也是Kafka完成的, 隐藏了许多细节, 避免了繁琐的配置和人为疏忽造成的负载问题。

        4.发送端由topic和key来决定消息发送到那个分区,如果key为null,那么会使用轮询算法将消息负载发送到同一个topic的不同分区中。 如果key不为null,那么会根据key的hashcode取模计算要发往的分区。

    rabbitmq:对负载均衡的支持不好

    1.消息被投递到那个队列是由交换机和key决定的, 交换器,路由键, 队列都需要手动创建

    rabbitMQ客户端发送消息要和broker建立连接, 需要事先知道broker有那些交换器, 有那些队列。通常要声明发送的目标队列, 如果没有目标队列, 会在broker上创建一个队列,如果有,就什么都不处理, 接着往这个队列发送消息。假设大部分繁琐的任务都在同一个broker上,那这个broker的负载会过大。(可以在上线前预先创建队列,无需声明要发送的队列,但是发送时不会尝试去创建队列,可能出现找不到队列的问题, rabbitmq的备份交换器会把找不到队列的消息保存到一个专门的队列中,以便以后查询用)

    使用镜像队列机制建立rabbitmq集群可以解决这个问题, 形成master-slave的架构, master节点会均匀分布在不同的服务器上, 让每一台服务器分摊负载. slave节点只是负责转发, 在master失效时会选择加入时间最长的slaver成为master

    当新节点加入镜像队列的时候, 队列中的消息不会同步到新的slaver中,除非调用同步命令, 但是调用命令后, 队列会阻塞, 不能在生产环境中调用同步命令

    2.当rabbitmq队列拥有多个消费者的时候,队列收到的消息将以轮询的分发方式发送给消费者。每条消息只会发送给订阅列表里的一个消费者,不会重复。

    这种方式非常适合扩展,而且是专门为并发程序设计的。

    如果某些消费者的任务比较繁重,那么可以设置basicQos限制信道上消费者能保持的最大未确认消息的数量,在达到上限时,rabbitmq不再向这个消费者发送任何消息。

    3.对于rabbitmq而言,客户端与集群建立的TCP连接不是与集群中所有的节点建立连接,而是挑选其中一个节点建立连接。

    但是rabbitmq集群可以借助HAProxy、LVS技术,或者在客户端使用算法实现负载均衡,引入负载均衡之后,各个客户端的连接可以分摊到集群的各个节点之中。

    rocketmq:支持负载均衡

    一个broker通常是一个服务器节点,broker分为master和slave,master和slave存储的数据一样,slave从master同步数据。

    1.nameserver与每个集群成员保持心跳,保存着Topic-Broker路由信息,同一个topic的队列会分布在不同的服务器上。

    2.发送消息通过轮询队列的方式发送,每个队列接收平均的消息量。发送消息指定topic、tags、keys,无法指定投递到哪个队列(没有意义,集群消费和广播消费跟消息存放在哪个队列没有关系)。

    tags选填,类似于 Gmail 为每封邮件设置的标签,方便服务器过滤使用。目前只支 持每个消息设置一个 tag,所以也可以类比为 Notify 的 MessageType 概念。

    keys选填,代表这条消息的业务关键词,服务器会根据 keys 创建哈希索引,设置后, 可以在 Console 系统根据 Topic、Keys 来查询消息,由于是哈希索引,请尽可能 保证 key 唯一,例如订单号,商品 Id 等。

    3.rocketmq的负载均衡策略规定:Consumer数量应该小于等于Queue数量,如果Consumer超过Queue数量,那么多余的Consumer 将不能消费消息。这一点和kafka是一致的,rocketmq会尽可能地为每一个Consumer分配相同数量的队列,分摊负载。

    activemq:支持负载均衡。可以基于zookeeper实现负载均衡

    集群方式

    Kafka:天然的’Leader-Slave’无状态集群, 每台服务既是Master也是Slave

    分区首领均匀地分布在不同的Kafka服务器上, 分区副本业均匀地分布在不同的Kafka服务器上, 所以每台kafka服务既含分区首领, 同时又含有分区副本, 每一台kafka服务器是某一台kafka服务器的Slave, 同时也是某一台kafka服务器的leader

    kafka的集群依赖与zookeeper, zookeeper支持热拓展, 所有的broker, 消费者, 分区都可以动态移除, 而无需关闭服务, 与不依赖zookeeper集群的mq相比, 这是最大的优势.

    rabbitmq:支持简单集群,'复制’模式,对高级集群模式支持不好

    rabbitmq的每一个节点,不管是单一节点系统或者是集群中的一部分,要么是内存节点,要么是磁盘节点,集群中至少要有一个是磁盘节点。

    在rabbitmq集群中创建队列,集群只会在单个节点创建队列进程和完整的队列信息(元数据、状态、内容),而不是在所有节点上创建。没有拓展性可言

    引入镜像队列,可以避免单点故障,确保服务的可用性,但是需要人为地为某些重要的队列配置镜像。

    rocketmq:常用 多对’Master-Slave’ 模式,开源版本需手动切换Slave变成Master

    Name Server是一个几乎无状态节点,可集群部署,节点之间无任何信息同步。

    Broker部署相对复杂,Broker分为Master与Slave,一个Master可以对应多个Slave,但是一个Slave只能对应一个Master,Master与Slave的对应关系通过指定相同的BrokerName,不同的BrokerId来定义,BrokerId为0表示Master,非0表示Slave。Master也可以部署多个。每个Broker与Name Server集群中的所有节点建立长连接,定时注册Topic信息到所有Name Server。

    Producer与Name Server集群中的其中一个节点(随机选择)建立长连接,定期从Name Server取Topic路由信息,并向提供Topic服务的Master建立长连接,且定时向Master发送心跳。Producer完全无状态,可集群部署。

    Consumer与Name Server集群中的其中一个节点(随机选择)建立长连接,定期从Name Server取Topic路由信息,并向提供Topic服务的Master、Slave建立长连接,且定时向Master、Slave发送心跳。Consumer既可以从Master订阅消息,也可以从Slave订阅消息,订阅规则由Broker配置决定。
    客户端先找到NameServer, 然后通过NameServer再找到 Broker。
    一个topic有多个队列,这些队列会均匀地分布在不同的broker服务器上。rocketmq队列的概念和kafka的分区概念是基本一致的,kafka同一个topic的分区尽可能地分布在不同的broker上,分区副本也会分布在不同的broker上。

    rocketmq集群的slave会从master拉取数据备份,master分布在不同的broker上。

    activemq:支持简单集群模式,比如’主-备’,对高级集群模式支持不好

    订阅形式和消息分发

    Kafka:基于topic以及按照topic进行正则匹配的发布订阅模式

    [发送]

    ​ 发送端由topic和key来决定消息将发往那个分区,如果key为null, 那么会使用轮询算法将消息均衡地发送到同一个topic的不同分区中. 如果key不是null, 那么会将key的hashcode取模计算出要发往的分区.

    [接受]

    1.consumer向群组协调器broker发送心跳来维持他们和群组的从属关系以及他们对分区的从属关系以及他们对分区的所有权关系,所有权关系一旦被分配到不会改变除非发生再均衡(比如有一个comsumer加入或者离开consumer group), consumer只会从对应的分区读取消息.

          2. Kafka限制consumer个数要**少于**分区个数, 每个消息只会被同一个consumer Group的一个消费者(非广播)
    
      3. Kafka的consumer group订阅同一个topic, 会尽可能地使得每一个consumer分配到相同数量的分区,不同consumer group同一个主题互相独立, 同一个消息会被不同的consumer group处理
    

    rabbitmq:提供了4种:direct, topic ,Headers和fanout

    [发送]

    ​ 先声明一个队列, 这个队列会被创建或者已经被创建, 队列是基本的存储单元.

    有exchage和key决定消息队列存储到那个队列

    fanout>与key无关,会发送到所有和exchange绑定的队列 (比如订阅模式)

    direct>发送到bindingKey完全匹配的队列(比如路由模式)

    topic>路由key是含有".“的字符串, 会发送到含有”*", "#"进行模糊匹配的bindingKey对应的队列(比如topic模式, 也叫主题模式)

    headers>与key无关, 消息内容的headers属性(一个键值对)和绑定的键值对完全匹配时, 会发送此队列. 此方式性能低一般不用.

    [接受]

    rabbitmq的队列是基本存储单元, 不在被分区或者分片, 对于我们已经创建了队列,消费端要指定从那个队列接收消息.

    work模式, 路由模式, topic模式: 当rabbitmq队列拥有多个consumer的时候, 每条消息只会发送给订阅列表里的一个consumer, 不会重复. 这种方式非常合适拓展, 而是专门为并发程序设计的

    PS: 如果某些消费者的任务比较繁重, 那么可以设置basicQos限制信道上消费者能保持的最大未确认消息的数量,在达到上限时, rabbitmq不再向这个消费发送任何消息.

    rocketmq:基于topic/messageTag以及按照消息类型、属性进行正则匹配的发布订阅模式

    activemq:点对点(p2p)、广播(发布-订阅)

    消息确认

    Kafka:支持

    发送机制:

    ack=0, 不管消息是否成功写入分区

    ack=1, 消息成功写入首领分区后,返回成功

    ack=all, 消息成功写入所有分区后, 返回成功

    接收方确认机制:

    自动或者手动提交分区偏移量,早期版本的kafka偏移量是提交给Zookeeper的,这样使得zookeeper的压力比较大,更新版本的kafka的偏移量是提交给kafka服务器的,不再依赖于zookeeper群组,集群的性能更加稳定

    Rabbitmq:支持

    发送方确认机制:

    消息被投递到所有匹配的队列后,返回成功。如果消息和队列是可持久化的,那么在写入磁盘后,返回成功。支持批量确认和异步确认

    接收方确认机制

    设置autoAck为false,需要显式确认,设置autoAck为true,自动确认。

    当autoAck为false的时候,rabbitmq队列会分成两部分,一部分是等待投递给consumer的消息,一部分是已经投递但是没收到确认的消息。如果一直没有收到确认信号,并且consumer已经断开连接,rabbitmq会安排这个消息重新进入队列,投递给原来的消费者或者下一个消费者。
    未确认的消息不会有过期时间,如果一直没有确认,并且没有断开连接,rabbitmq会一直等待,rabbitmq允许一条消息处理的时间可以很久很久,

    所以这里有个疑问: 如果consumer设置autoAck=false, 然后在处理某消息的时候宕机了, 而MQ一直在等待怎么办? 还说说如果断开连接了, MQ会将这个消息重发给consumer处理?

    ​ 刚刚做了测试, 如果在consumer处理的时候, 手动杀死其进程, 好像rabbitmq会自动将这消息重新入队

    消息重试

    Kafka: 不支持, 但是可以实现

    Kafka支持指定分区offset位置的回溯, 可以实现消息重试.

    rabbitmq, 不支持,但是可以利用消息确认机制实现

    生产者:

    等待补充!!!其实RabbitMQ几乎可以保证99.99%发生成功, 但是偶尔也有失败,

    处理方式大概2种类: 1定时重发, 2记录日志人工处理, 如果是重要的消息可以发起系统预警

    消费者:

    当autoAck为false的时候,rabbitmq队列会分成两部分,一部分是等待投递给consumer的消息,一部分是已经投递但是没收到确认的消息。如果一直没有收到确认信号,并且consumer已经断开连接,rabbitmq会安排这个消息重新进入队列,投递给原来的消费者或者下一个消费者

    如果消费者消费3次都失败,可以根据业务情况进入死信队列

    rocketmq:支持

    消息消费失败的大部分场景下, 立即重试99%都会失败, 所以rocketmq的策略是在消费失败时定时重试,每次时间间隔相同.

    生产者: (发送端的 send 方法本身支持内部重试)

    a.最多重试3次

    b.如果发送失败, 则轮转到下一个broker

    c. 这个方法的总耗时不超过sendMsgTimeout 设置的值,默认 10s,超过时间不在重试

    消费者: 消费消息失败后,要提供一种重试机制,令消息再消费一次。Consumer 消费消息失败通常可以分为以下两种情况:

    1.由于消息本身的原因, 例如反序列化失败, 消息数据本身无法处理(比如充话费的时候,当前手机号不存在). 定时重试机制,比如超过10s后再重试

    2.由于依赖的下游应用服务器不可用, 例如db连接不可用, 外系统网络不可达.

    即使跳过当前失败的消息,消费其他消息同样也会报错。这种情况可以 sleep 30s,再消费下一条消息,减轻 Broker 重试消息的压力。

    activemq:不支持

    并发度

    Kafka 高

    一个线程一个消费者, Kafka限制消费者的个数要**<=**分区数,如果要提高并行度, 可以在消费者中开启多线程, 或者增加consumer实例数量

    RabbitMQ: 极高(下面这段文字上面有提起)

    本身是用Erlang语言写的,并发性能高。

    可在消费者中开启多线程,最常用的做法是一个channel对应一个消费者,每一个线程把持一个channel,多个线程复用connection的tcp连接,减少性能开销。

    当rabbitmq队列拥有多个消费者的时候,队列收到的消息将以轮询的分发方式发送给消费者。每条消息只会发送给订阅列表里的一个消费者,不会重复。

    这种方式非常适合扩展,而且是专门为并发程序设计的。

    如果某些消费者的任务比较繁重,那么可以设置basicQos限制信道上消费者能保持的最大未确认消息的数量,在达到上限时,rabbitmq不再向这个消费者发送任何消息

    rocketmq:高

    1. rocketmq限制消费者个数**<=**队列数,但是可以在消费者再开启多线程, 这一点和Kafka是一致的,提高并行度的方法相同.

      修改消费并行度方法:

      a.同一个ConsumerGroup下, 通过增加Consumer实例数量来提高并发度, 超过订阅队列数的Consumer实例无效.

      b.提高单个Consumer的消费并行线程, 通过修改参数consumeThreadMin, consumeThreadMax

    2.同一个网络连接connection, 客户端多个线程连接可以同事发送请求,连接会被复用, 减少性能开销.

    activemq: 高

    单个ActiveMQ的接收和消费消息的速度在1万笔/秒(持久化 一般为1-2万, 非持久化 2 万以上),在生产环境中部署10个Activemq就能达到10万笔/秒以上的性能,部署越多的activemq broker 在MQ上latency也就越低,系统吞吐量也就越高

    文章来自于

    展开全文
  • 这是一个MQ的系列文章,主要由MQ的基础认识到深入了解,和针对不同业务对MQ的技术选型问题。通过文章了解不同MQ的各种区别,和使用MQ会存在的一些问题。

    前言

    这是一个MQ的系列文章,主要由MQ的基础认识到深入了解,和针对不同业务对MQ的技术选型问题。通过文章了解不同MQ的各种区别,和使用MQ会存在的一些问题。

    入门篇:MQ(消息队列)系列学习—MQ基础认识
    基础篇:MQ(消息队列)系列学习—MQ组件优劣势比较
    晋级篇:MQ(消息队列)系列学习—MQ如何保证消息队列高可用
    在这里插入图片描述

    1.文字总结

    1.1 ActiveMQ

    优点

    • 单机吞吐量:万级
    • topic数量都吞吐量的影响:
    • 时效性:ms级
    • 可用性:高,基于主从架构实现高可用性
    • 消息可靠性:有较低的概率丢失数据
    • 功能支持:MQ领域的功能极其完备

    缺点

    • 社区维护较少,官方版本
    • 在大规模吞吐下性能较差

    1.2 Kafka

    优点

    • 单机吞吐量:十万级
    • 专为大数据准备,数据采集、传输、存储
    • 可用性:高,kafka是分布式
      缺点
    • 社区更新较慢
    • 支持消息顺序,但一台代理服务器宕机会导致消息乱序
    • 使用轮询,消息的实时性取决于轮询间隔时间
    • 消息有可能会被重复消费

    1.3 RabbitMQ

    优点

    • 由于是erlang语言开发,性能较好,支持高并发
    • 中小公司都选择它
    • 时效性最高
    • 社区活跃性高
    • 管理界面友好

    缺点

    • 由于是erlang语言开发,不能定制开发。较难维护,不利于二次开发
    • 吞吐量较低

    1.4 RocketMQ

    优点

    • 阿里出品,基于java语言。已在阿里中订单、交易、充值、流计算各种高并发场景中使用
    • 单机吞吐量:最高(十万级)
    • 消息可靠性:那是相当可靠,杠杠的
    • 可以自己进行定制化开发

    缺点

    • 支持命令行界面,可视化页面不太友好
    • 社区活跃性一般

    2.MQ选择推荐

    (1)中小型软件公司,建议选RabbitMQ.

    1.支持高并发
    2.管理界面友好
    3.社区活跃,一般中小公司都选择该MQ进行开发,碰见bug在网上也能较快找到
    4.消息时效性最高-微秒级

    (2)大型软件公司,建议选择 RocketMQ

    1.单机的吞吐量最高
    2.消息可靠性极高,理论不会丢失。如有对消息可靠性有要求,那么RocketMQ首选
    3.基于java开发,可以定制化开发
    4.稳定性极好,阿里双11年年帮我们测试

    (3)大型数据型公司,建议选Kafka

    1.如果由日志采集功能、实时计算-Kafka首选
    2.吞吐量极高
    3.适合大数据,专门用于处理数据

    展开全文
  • 常见主流MQ之间的对比

    千次阅读 2019-07-02 17:13:35
    今天梳理一下一些主流MQ的优缺点,我们用表格对比一下: 特性 ActiveMq RabbitMq RocketMQ Kafka 成熟度 成熟 成熟 比较成熟 成熟的日志领域 时效性 微秒级 毫秒级 毫秒级 社区活跃度 低 高 高 高 ...

    今天梳理一下一些主流MQ的优缺点,我们用表格对比一下:

    特性ActiveMqRabbitMqRocketMQKafka
    成熟度成熟成熟比较成熟成熟的日志领域
    时效性微秒级毫秒级毫秒级
    社区活跃度
    单机吞吐量万级,吞吐量比RocketMQ和Kafka要低了一个数量级万级,吞吐量比RocketMQ和Kafka要低了一个数量级10万级,RocketMQ也是可以支撑高吞吐的一种MQ10万级别,这是kafka最大的优点,就是吞吐量高。一般配合大数据类的系统来进行实时数据计算、日志采集等场景
    topic数量对吞吐量的影响topic可以达到几百,几千个的级别,吞吐量会有较小幅度的下降这是RocketMQ的一大优势,在同等机器下,可以支撑大量的topictopic从几十个到几百个的时候,吞吐量会大幅度下降所以在同等机器下,kafka尽量保证topic数量不要过多。如果要支撑大规模topic,需要增加更多的机器资源
    可用性高,基于主从架构实现高可用性高,基于主从架构实现高可用性非常高,分布式架构非常高,kafka是分布式的,一个数据多个副本,少数机器宕机,不会丢失数据,不会导致不可用
    消息可靠性有较低的概率丢失数据经过参数优化配置,可以做到0丢失经过参数优化配置,消息可以做到0丢失
    功能支持MQ领域的功能极其完备基于erlang开发,所以并发能力很强,性能极其好,延时很低MQ功能较为完善,还是分布式的,扩展性好功能较为简单,主要支持简单的MQ功能,在大数据领域的实时计算以及日志采集被大规模使用,是事实上的标准
    优劣势总结非常成熟,功能强大,在业内大量的公司以及项目中都有应用偶尔会有较低概率丢失消息而且现在社区以及国内应用都越来越少,官方社区现维护越来越少,几个月才发布一个版本而且确实主要是基于解耦和异步来用的,较少在大规模吞吐的场景中使用rlang语言开发,性能极其好,延时很低;吞吐量到万级,MQ功能比较完备而且开源提供的管理界面非常棒,用起来很好用社区相对比较活跃,几乎每个月都发布几个版本分在国内一些互联网公司近几年用rabbitmq也比较多一些但是问题也是显而易见的,RabbitMQ确实吞吐量会低一些,这是因为他做的实现机制比较重。而且erlang开发,国内有几个公司有实力做erlang源码级别的研究和定制?如果说你没这个实力的话,确实偶尔会有一些问题,你很难去看懂源码,你公司对这个东西的掌控很弱,基本职能依赖于开源社区的快速维护和修复bug。而且rabbitmq集群动态扩展会很麻烦,不过这个我觉得还好。其实主要是erlang语言本身带来的问题。很难读源码,很难定制和掌控。接口简单易用,而且毕竟在阿里大规模应用过,有阿里品牌保障日处理消息上百亿之多,可以做到大规模吞吐,性能也非常好,分布式扩展也很方便,社区维护还可以,可靠性和可用性都是ok的,还可以支撑大规模的topic数量,支持复杂MQ业务场景而且一个很大的优势在于,阿里出品都是java系的,我们可以自己阅读源码,定制自己公司的MQ,可以掌控社区活跃度相对较为一般,不过也还可以,文档相对来说简单一些,然后接口这块不是按照标准JMS规范走的有些系统要迁移需要修改大量代码还有就是阿里出台的技术,你得做好这个技术万一被抛弃,社区黄掉的风险,那如果你们公司有技术实力我觉得用RocketMQ挺好的kafka的特点其实很明显,就是仅仅提供较少的核心功能,但是提供超高的吞吐量,ms级的延迟,极高的可用性以及可靠性,而且分布式可以任意扩展同时kafka最好是支撑较少的topic数量即可,保证其超高吞吐量而且kafka唯一的一点劣势是有可能消息重复消费,那么对数据准确性会造成极其轻微的影响,在大数据领域中以及日志采集中,这点轻微影响可以忽略这个特性天然适合大数据实时计算以及日志收集

    一般的业务系统要引入MQ,最早大家都用ActiveMQ,但是现在确实大家用的不多了,没经过大规模吞吐量场景的验证,社区也不是很活跃;
    后来大家开始用RabbitMQ,但是确实erlang语言阻止了大量的java工程师去深入研究和掌控他,对公司而言,几乎处于不可控的状态,但是确实人是开源的,比较稳定的支持,活跃度也高;

    不过现在确实越来越多的公司,会去用RocketMQ,确实很不错,但是我提醒一下自己想好社区万一突然黄掉的风险,对自己公司技术实力有绝对自信的,我推荐用RocketMQ,否则回去老老实实用RabbitMQ吧,人是活跃开源社区,绝对不会黄

    所以中小型公司,技术实力较为一般,技术挑战不是特别高,用RabbitMQ是不错的选择;大型公司,基础架构研发实力较强,用RocketMQ是很好的选择

    如果是大数据领域的实时计算、日志采集等场景,用Kafka是业内标准的,绝对没问题,社区活跃度很高,绝对不会黄,何况几乎是全世界这个领域的事实性规范

    展开全文
  • 比较于RocketMQ等其他常见消息系统,Kafka在保障了大部分功能特性的同时,还提供了超一流的读写性能。针对Kafka性能方面进行简单分析,相关数据请参考:https://segmentfault.com/a/1190000003985468,下面介绍...
  • ActiveMQ:支持万级的吞吐量,较成熟完善;官方更新迭代较少,社区的活跃度不是很高,有消息丢失的情况。 RabbitMQ:延时低,微妙级延时,社区活跃度高,bug 修复及时,而且提供了很友善的后台界面;...
  • 常用MQ及其原理

    万次阅读 2018-07-20 17:56:42
    mq为了解决什么问题? 1、异步通信 有些业务不想也不需要立即处理消息。消息队列提供了异步处理机制,允许用户把一个消息放入队列,但并不立即处理它。想向队列中放入多少消息就放多少,然后在需要的时候再去处理...
  • MQ常用命令

    千次阅读 2019-01-08 22:15:08
    一.MQ基本操作  MQ中有几个很重要的组件:队列管理器(QueueManager)、队列(Queue)和通道(Channel)。其基本的操作方法如下:  创建队列管理器   crtmqm –q QMgrName   -q是指创建缺省的队列管理器 ...
  • MQ详解及四大MQ比较

    万次阅读 2019-01-11 20:58:57
    同时将阿里系内部多款mq产品(Notify、metaq)进行整合,只维护核心功能,去除了所有其他运行时依赖,保证核心功能最简化,在此基础上配合阿里上述其他开源产品实现不同场景下mq的架构,目前主要多用于订单交易系统...
  • 消息中间件之MQ详解及四大MQ比较

    千次阅读 2020-02-01 16:05:16
    同时将阿里系内部多款mq产品(Notify、metaq)进行整合,只维护核心功能,去除了所有其他运行时依赖,保证核心功能最简化,在此基础上配合阿里上述其他开源产品实现不同场景下mq的架构,目前主要多用于订单交易系统...
  • 一、MQ简介及特点 MQ全称为Message Queue, 消息队列(MQ)是一种应用程序对应用程序的通信方法。应用程序通过写和检索出入列队的针对应用程序的数据(消息)来通信,而无需专用连接来链接它们。消息传递指的是...
  • mq常用命令详解

    2012-05-13 21:34:48
    这里详细地介绍了mq常用命令,分享快乐
  • 常用MQ命令

    2018-09-10 21:37:28
    消息是MQ中最小的概念,本质上就是一段数据,它能被一个或者多个应用程序所理解,是应用程序之间传递的信息载体。 2.队列(Queue) 2.1本地队列 本地队列按照功能可划分为初始化队列,传输队列,目标队列和死信...
  • WebSphere MQ常用命令

    2012-01-08 20:55:30
    WebSphere MQ常用命令,非常详细的命令与说明
  • 消息中间件MQ与RabbitMQ面试题(2020最新版)

    万次阅读 多人点赞 2020-03-01 11:11:21
    文章目录为什么使用MQMQ的优点消息队列有什么优缺点?RabbitMQ有什么优缺点?你们公司生产环境用的是什么消息中间件?Kafka、ActiveMQ、RabbitMQ、RocketMQ 有什么优缺点?MQ 有哪些常见问题?如何解决这些问题?...
  • ibm——mq常用命令

    2015-01-11 19:13:51
    ibm——mq常用命令
  • 目录 一、简述: 二、应用场景: 1、应用耦合: 2、应用耦合实例: 3、异步处理: 4、异步处理实例: 5、限流削峰: 6、限流削峰实例: ...四、常用消息队列: 1、RabbitMQ: (1)简介: ...
  • 什么是MQ MQ(Message Queue),为消息队列,又叫消息中间件,是类似于数据库一样的应用,需要单独去部署。 消息 – 是在两台计算机间传送的数据单位。消息可以非常简单,例如只包含文本字符串; 也可以更复杂,可能...
  • 最近需要用到MQ组件,对具体组件的选型有一些调研,集合网上已有的一些材料,将粗略归纳的选型材料展示成列表形式,方便比对: 参考:https://www.cnblogs.com/imstudy/p/11064589.html
  • IBM MQ常用的命令

    万次阅读 2018-08-16 11:51:28
    1、通道:指MQ访问的一个物理API接口,因为MQ都实现了JMS协议,底层走的是SOCKET, 而通道就是封装了协议和操作SOCKET的一个接口,我们连MQ的时候,没有显示的声明SOCKET连接等,就是因为有通道的存在。 2、 Q:...
  • IBM MQ常用命令

    万次阅读 2018-11-14 14:45:47
    WebSphere MQ 使用 MQI 通道在 MQI 客户机和队列管理器之间传送 MQI 调用和响应。 2.1.1 定义接收通道 def chl(通道名) chltype(rcvr) trptype(tcp) def chl(SYS.SVRCONN) chltype(rcvr) trptype(tcp) ...
  • 一、常见消息中间件MQ介绍 1、RocketMQ 阿里系下开源的一款分布式、队列模型的消息中间件,原名Metaq,3.0版本名称改为RocketMQ,是阿里参照kafka设计思想使用java实现的一套mq。同时将阿里系内部多款mq产品(Notify...
  • 消息中间件 MQ详解及四大MQ比较

    千次阅读 2019-05-10 16:14:48
    同时将阿里系内部多款mq产品(Notify、metaq)进行整合,只维护核心功能,去除了所有其他运行时依赖,保证核心功能最简化,在此基础上配合阿里上述其他开源产品实现不同场景下mq的架构,目前主要多用于订单交易系统...
  • 常用的消息队列中间件mq对比

    万次阅读 2018-05-08 14:24:01
    本部分内容介绍常用的消息中间件(Active MQ,Rabbit MQ,Zero MQ,Kafka)以及他们的特点。 5.1 ActiveMQ ActiveMQ 是Apache出品,最流行的,能力强劲的开源消息总线。ActiveMQ 是一个完全支持JMS1.1和J2EE 1.4...
  • IBM_MQ常用命令 总结

    2011-06-05 15:57:18
    MQ常用命令 如何测试MQ 测试MQ远程队列
  • 常用MQ命令(2)

    2018-09-10 21:38:13
    显示结果中QMNAME表示MQ队列管理器的名称,STATUS表示当前运行状态。 运行状态有如下几种: Starting 正在启动 Running 正在运行 Ending 正在停止 Ended normally 已经正常终止 Ended im...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 30,104
精华内容 12,041
关键字:

常用mq比较