精华内容
下载资源
问答
  • 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及其原理

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

    mq为了解决什么问题?

    1、异步通信

       有些业务不想也不需要立即处理消息。消息队列提供了异步处理机制,允许用户把一个消息放入队列,但并不立即处理它。想向队列中放入多少消息就放多少,然后在需要的时候再去处理它们。

    2、解耦

       降低工程间的强依赖程度,针对异构系统进行适配。在项目启动之初来预测将来项目会碰到什么需求,是极其困难的。通过消息系统在处理过程中间插入了一个隐含的、基于数据的接口层,两边的处理过程都要实现这一接口,当应用发生变化时,可以独立的扩展或修改两边的处理过程,只要确保它们遵守同样的接口约束

    3、冗余

       有些情况下,处理数据的过程会失败。除非数据被持久化,否则将造成丢失。消息队列把数据进行持久化直到它们已经被完全处理,通过这一方式规避了数据丢失风险。许多消息队列所采用的"插入-获取-删除"范式中,在把一个消息从队列中删除之前,需要你的处理系统明确的指出该消息已经被处理完毕,从而确保你的数据被安全的保存直到你使用完毕。

    4、扩展性

       因为消息队列解耦了你的处理过程,所以增大消息入队和处理的频率是很容易的,只要另外增加处理过程即可。不需要改变代码、不需要调节参数。便于分布式扩容

    5、过载保护

       在访问量剧增的情况下,应用仍然需要继续发挥作用,但是这样的突发流量无法提取预知;如果以为了能处理这类瞬间峰值访问为标准来投入资源随时待命无疑是巨大的浪费。使用消息队列能够使关键组件顶住突发的访问压力,而不会因为突发的超负荷的请求而完全崩溃

    6、可恢复性

       系统的一部分组件失效时,不会影响到整个系统。消息队列降低了进程间的耦合度,所以即使一个处理消息的进程挂掉,加入队列中的消息仍然可以在系统恢复后被处理。

    7、顺序保证

       在大多使用场景下,数据处理的顺序都很重要。大部分消息队列本来就是排序的,并且能保证数据会按照特定的顺序来处理。

    8、缓冲

       在任何重要的系统中,都会有需要不同的处理时间的元素。消息队列通过一个缓冲层来帮助任务最高效率的执行,该缓冲有助于控制和优化数据流经过系统的速度。以调节系统响应时间。

    9、数据流处理

    分布式系统产生的海量数据流,如:业务日志、监控数据、用户行为等,针对这些数据流进行实时或批量采集汇总,然后进行大数据分析是当前互联网的必备技术,通过消息队列完成此类数据收集是最好的选择

    Mq原理

    1)MQ原型-Pub/Sub发布订阅

    (广播:生产者-消费之1对多):使用topic作为通信载体

    希望发送的消息可以不被做任何处理、或者只被一个消息者处理、或者可以被多个消费者处理的话,那么可以采用Pub/Sub模型

    2) MQ原型-PTP点对点

    :使用queue作为通信载体

     如果希望发送的每个消息都会被成功处理的话,那么需要P2P模式。

    3 MQ原型-多点广播:

    MQ适用于不同类型的应用。其中重要的,也是正在发展中的是"多点广播"应用,即能够将消息发送到多个目标站点(Destination List)。可以使用一条MQ指令将单一消息发送到多个目标站点,并确保为每一站点可靠地提供信息。MQ不仅提供了多点广播的功能,而且还拥有智能消息分发功能,在将一条消息发送到同一系统上的多个用户时,MQ将消息的一个复制版本和该系统上接收者的名单发送到目标MQ系统。目标MQ系统在本地复制这些消息,并将它们发送到名单上的队列,从而尽可能减少网络的传输量。

    4 MQ原型-群集(Cluster):

    为了简化点对点通讯模式中的系统配置,MQ提供Cluster(群集)的解决方案。群集类似于一个域(Domain),群集内部的队列管理器之间通讯时,不需要两两之间建立消息通道,而是采用群集(Cluster)通道与其它成员通讯,从而大大简化了系统配置。此外,群集中的队列管理器之间能够自动进行负载均衡,当某一队列管理器出现故障时,其它队列管理器可以接管它的工作,从而大大提高系统的高可靠性

     

    2、MQ组成结构

       Broker:消息服务器,作为server提供消息核心服务

       Producer:消息生产者,业务的发起方,负责生产消息传输给broker,

       Consumer:消息消费者,业务的处理方,负责从broker获取消息并进行业务逻辑处理

       Topic:主题,发布订阅模式下的消息统一汇集地,不同生产者向topic发送消息,由MQ服务器分发到不同的订阅 者,实现消息的广播

       Queue:队列,PTP模式下,特定生产者向特定queue发送消息,消费者订阅特定的queue完成指定消息的接收

       Message:消息体,根据不同通信协议定义的固定格式进行编码的数据包,来封装业务数据,实现消息的传输

    RabbitMq与kafaka选型比较

    https://blog.csdn.net/yifansj/article/details/79248586

    架构方面:

    Kafaka是正常的mq架构,包括provider broker consumer。,kafaka没有消息确认机制

    rabbitMq 中的broker由exchange、binder queue三部分组成,其中exchange和binding组成了消息的路由键;客户端Producer通过连接channel和server进行通信,Consumer从queue获取消息进行消费,rabbit有消息确认机制

    吞吐量方面:

    Kafaka采用zero-copy方式,即数据存储和获取是本地磁盘顺序批量操作,具有O(1)复杂度,数据处理效率很高

    RabbitMq在吞吐量方面不如kafaka,RabbitMq支持对消息可靠的传递,支持事务,不支持批量的操作。

    可用性方面

    Kafaka的broker采用主备模式,所以可用性很高

    RabbitMq支持miror queue,主queue失效,minor queue生效

    集群负载方面

    Kafaka使用zookeeper实现负载均衡,zookeeper管理集群中的broker sonsumer,通过zookeeper的协调机制,producer会记录topic对应的broker,对broker进行轮询或者随机访问broker,实现负载均衡

    RabbitMq需要单独自定义负载均衡

     

    一般推荐使用mq,例如RabbitMq,activeMq等,已经比较成熟和稳定了,性能也一般,一般推荐使用这些。Redies适用于在内存中存储数据库,作为消息队列可靠性较差,而且依赖于网络IO;kafaka设计的初衷是日志统计分析,现在也可以配合zookeeper用于消息

    展开全文
  • 常用MQ命令

    2021-03-10 01:16:52
    最近在配置MQ,记下了一些常用MQ命令,如下:创建队列管理器crtmqm –q QMgrName-q是指创建缺省的队列管理器删除队列管理器dltmqm QmgrName启动队列管理器strmqm QmgrName如果是启动默认的队列管理器,可以不带其名字...

    最近在配置MQ,记下了一些常用的MQ命令,如下:

    创建队列管理器

    crtmqm –q QMgrName

    -q是指创建缺省的队列管理器

    删除队列管理器

    dltmqm QmgrName

    启动队列管理器

    strmqm QmgrName

    如果是启动默认的队列管理器,可以不带其名字

    停止队列管理器

    endmqm QmgrName 受控停止

    endmqm –i QmgrName 立即停止

    endmqm –p QmgrName 强制停止

    显示队列管理器

    dspmq –m QmgrName

    运行MQ命令

    runmqsc QmgrName

    如果是默认队列管理器,可以不带其名字

    往队列中放消息

    amqsput QName QmgrName

    如果队列是默认队列管理器中的队列,可以不带其队列管理器的名字

    从队列中取出消息

    amqsget QName QmgrName

    如果队列是默认队列管理器中的队列,可以不带其队列管理器的名字

    启动通道

    runmqchl –c ChlName –m QmgrName

    启动侦听

    runmqlsr –t TYPE –p PORT –m QMgrName

    停止侦听

    endmqlsr -m QmgrName

    下面是在MQ环境中可以执行的MQ命令(即在runmqsc环境下可以敲的命令)

    定义持久信队列

    DEFINE QLOCAL(QNAME) DEFPSIST(YES) REPLACE

    设定队列管理器的持久信队列

    ALTER QMGR DEADQ(QNAME)

    定义本地队列

    DEFINE QL(QNAME) REPLACE

    定义别名队列

    DEFINE QALIAS(QALIASNAME) TARGQ(QNAME)

    远程队列定义

    DEFINE QREMOTE(QRNAME) +

    RNAME(AAA) RQMNAME(QMGRNAME) +

    XMITQ(QTNAME)

    定义模型队列

    DEFINE QMODEL(QNAME) DEFTYPE(TEMPDYN)

    定义本地传输队列

    DEFINE QLOCAL(QTNAME) USAGE(XMITQ) DEFPSIST(YES) +

    INITQ(SYSTEM.CHANNEL.INITQ)+

    PROCESS(PROCESSNAME) REPLACE

    创建进程定义

    DEFINE PROCESS(PRONAME) +

    DESCR(‘STRING’)+

    APPLTYPE(WINDOWSNT)+

    APPLICID(’ runmqchl -c SDR_TEST -m QM_ TEST’)

    其中APPLTYPE的值可以是:CICS、UNIX、WINDOWS、WINDOWSNT等

    创建发送方通道

    DEFINE CHANNEL(SDRNAME) CHLTYPE(SDR)+

    CONNAME(‘100.100.100.215(1418)’) XMITQ(QTNAME) REPLACE

    其中CHLTYPE可以是:SDR、SVR、RCVR、RQSTR、CLNTCONN、SVRCONN、CLUSSDR和CLUSRCVR。

    创建接收方通道

    DEFINE CHANNEL(SDR_ TEST) CHLTYPE(RCVR) REPLACE

    创建服务器连接通道

    DEFINE CHANNEL(SVRCONNNAME) CHLTYPE(SVRCONN) REPLACE

    显示队列的所有属性

    DISPLAY QUEUE(QNAME) [ALL]

    显示队列的所选属性

    DISPLAY QUEUE(QNAME) DESCR GET PUT

    DISPLAY QUEUE(QNAME)MAXDEPTH CURDEPTH

    显示队列管理器的所有属性

    DISPLAY QMGR [ALL]

    显示进程定义

    DISPLAY PROCESS(PRONAME)

    更改属性

    ALTER QMGR DESCR(‘NEW DESCRIPTION’)

    ALTER QLOCAL(QNAME) PUT(DISABLED)

    ALTER QALIAS(QNAME) TARGQ(TARGQNAME)

    删除队列

    DELETE QLOCAL(QNAME)

    DELETE QREMOTE(QRNAME)

    清除队列中的所有消息

    CLEAR QLOCAL(QNAME)

    以下是一些高级配置的命令:

    amqmcert                  配置SSL证书

    amqmdain                配置windows上的MQ服务

    crtmqcvx                    转换数据

    dmpmqaut                转储对象权限管理

    dmpmqlog                转储日志管理

    dspmq                         显示队列管理器

    dspmqaut                  显示打开对象的权限

    dmpmqcap               显示处理程序容量和处理程序数

    dspmqcsv                 显示命令服务器状态

    dspmqfls                   显示文件名

    dspmqtrc                   跟踪MQ输出(HP-UNIX LINUX Solaris)

    dspmqrtn                   显示事务的详细信息

    endmqcsv                 停止队列管理器上的命令服务器

    strmqcsv                    启动队列管理器上的命令服务器

    endmqtrc                   停止跟踪

    rcdmqimg                  向日志写对象的映像

    rcmqobj                      根据日志中的映像重新创建一个对象

    rsvmqtrn                     提交或逆序恢复事务

    posted on 2007-12-26 17:26 john 阅读(2487) 评论(0)  编辑  收藏 所属分类: Linux

    展开全文
  • 这是一个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-02-16 09:34:58
    mq 测试工具
  • 常用MQ命令

    2018-09-10 21:37:28
    消息是MQ中最小的概念,本质上就是一段数据,它能被一个或者多个应用程序所理解,是应用程序之间传递的信息载体。 2.队列(Queue) 2.1本地队列 本地队列按照功能可划分为初始化队列,传输队列,目标队列和死信...
  • ActiveMQ:支持万级的吞吐量,较成熟完善;官方更新迭代较少,社区的活跃度不是很高,有消息丢失的情况。 RabbitMQ:延时低,微妙级延时,社区活跃度高,bug 修复及时,而且提供了很友善的后台界面;...
  • 目录 一、简述: 二、应用场景: 1、应用耦合: 2、应用耦合实例: 3、异步处理: 4、异步处理实例: 5、限流削峰: 6、限流削峰实例: ...四、常用消息队列: 1、RabbitMQ: (1)简介: ...
  • 什么是MQ MQ(Message Queue),为消息队列,又叫消息中间件,是类似于数据库一样的应用,需要单独去部署。 消息 – 是在两台计算机间传送的数据单位。消息可以非常简单,例如只包含文本字符串; 也可以更复杂,可能...
  • 一、MQ简介及特点 MQ全称为Message Queue, 消息队列(MQ)是一种应用程序对应用程序的通信方法。应用程序通过写和检索出入列队的针对应用程序的数据(消息)来通信,而无需专用连接来链接它们。消息传递指的是...
  • 常用MQ命令(2)

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

    2018-04-08 22:18:00
    2019独角兽企业重金招聘Python工程师标准>>> MQ选型对比文档 转载于:https://my.oschina.net/Howard2016/blog/1791456
  • 常用mq比较

    千次阅读 2017-02-17 10:13:46
    常用MQ产品比较 ActiveMQ Joram HornetQ OpenMQ MuleMQ SonicMQ RabbitMQ ZeroMQ
  • 最近学习了一下MQ的相关知识,就目前最常用的4个MQ中间件做一个简单的总结,非常片面和不成熟,欢迎指正 1. ActiveMQ 优点:技术成熟;功能强大 缺点:小概率消息丢失;社区不活跃,版本维护周期长,有可能会发生...
  • 传统的MQ,消息被消化掉后会被mq删除,而kafka中消息被消化后不会被删除,而是到配置的expire时间后,才删除 传统的MQ,消息的Offset是由MQ维护,而kafka中消息的Offset是由客户端自己维护 分布式,把写入压力均摊到...
  • 常用的消息队列中间件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...
  • mq常用命令详解

    2012-05-13 21:34:48
    这里详细地介绍了mq常用命令,分享快乐
  • 常见主流MQ之间的对比

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

    万次阅读 多人点赞 2020-06-27 12:12:08
    不少候选人,说自己项目里用了 Redis、MQ,但是其实他并不知道自己为什么要用这个东西。其实说白了,就是为了用而用,或者是别人设计的架构,他从头到尾都没思考过。 没有对自己的架构问过为什么的人,一定是平时...
  • MQ详解及四大MQ比较

    2020-03-16 15:21:46
    消息中间件(一)MQ详解及四大MQ比较 1、概述 消息队列已经逐渐成为企业IT系统内部通信的核心手段。它具有低耦合、可靠投递、广播、流量控制、最终一致性等一系列功能,成为异步RPC的主要手段之一。当今市面上...
  • 常见MQ队列介绍

    千次阅读 2019-04-24 15:39:11
    分析:既然在项目中用了MQ,肯定事先要对业界流行的MQ进行调研,如果连每种MQ的优缺点都没了解清楚,就拍脑袋依据喜好,用了某种MQ,还是给项目挖坑。如果面试官问:"你为什么用这种MQ?。"你直接回答"领导决定的。...
  • MQ常用命令

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

    2011-06-05 15:57:18
    MQ常用命令 如何测试MQ 测试MQ远程队列
  • 【消息队列】几种常见的MQ总结对比

    千次阅读 2020-10-29 15:27:51
    不少候选人,说自己项目里用了 Redis、MQ,但是其实他并不知道自己为什么要用这个东西。其实说白了,就是为了用而用,或者是别人设计的架构,他从头到尾都没思考过。 没有对自己的架构问过为什么的人,一定是平时...
  • IBM MQ常用命令

    2021-05-12 00:44:23
    常用命令创建队列管理器crtmqm –q QMgrName-q是指创建缺省的队列管理器删除队列管理器dltmqm QmgrName启动队列管理器strmqm QmgrName如果是启动默认的队列管理器,可以不带其名字停止队列管理器endmqm QmgrName ...
  • WebSphere MQ常用命令

    2012-01-08 20:55:30
    WebSphere MQ常用命令,非常详细的命令与说明
  • 常用MQ比较

    2020-11-13 15:38:28
    afka的集群依赖于zookeeper,zookeeper支持热扩展,所有的broker、消费者、分区都可以动态加入移除,而无需关闭服务,于不依靠zookeeper集群的mq相比,这是最大的优势。 rabbitmq:支持简单集群,‘复制’模式,对...
  • ibm——mq常用命令

    2015-01-11 19:13:51
    ibm——mq常用命令

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 31,702
精华内容 12,680
关键字:

常用的mq