从AMQP协议可以看出,MessageQueue、Exchange和Binding构成了AMQP协议的核心。下面我们就围绕这三个主要组件,从应用使用的角度全面的介绍如何利用RabbitMQ构建消息队列以及使用过程中的注意事项。

声明MessageQueue:

在RabbitMQ中,无论是生产者发送消息还是消费者接收消息,都首先需要声明一个MessageQueue。这就存在一个问题,是生产者声明还是消费者声明呢?要解决这个问题,首先要明确:

1)消费者是无法订阅或者获取不存在的MessageQueue中的信息。

2)消息被Exchange接收以后,如果没有匹配的Queue,则会被丢弃。

明白了上述两点以后,就容易理解如果是消费者去声明Queue,就有可能会出现在声明Queue之前,生产者已发送的消息被丢弃的隐患。如果应用能够通过消息重发的机制允许消息丢失,则使用此方案没有任何问题。但是如果不能接受该方案,则会就需要无论是生产者还是消费者,在发送或者接收消息前,都需要去尝试建立消息队列。这里有一点需要明确,如果客户端尝试建立一个已经存在的消息队列,RabbitMQ不会做任何事情,并返回客户端建立成功的。

如果一个消费者在一个channel中正在监听某一个队列的消息,RabbitMQ是不允许该消费者在同一个channel中去声明其他队列的。RabbitMQ中,可以通过queue.declare命令声明一个队列,可以设置该队列一下属性:

1)Exclusive:排他队列,如果一个队列被声明为排他队列,该队列仅对首次声明它的连接可见,并在连接断开时自动删除。这里需要注意三点:其一,排他队列是基于连接可见的,同一连接的不同信道是可以同时访问同一个连接创建的排他队列的。其二,“首次”,如果一个连接已经声明了一个排他队列,其他连接是不允许建立同名的排他队列的,这个与普通队列不同。其三,即使该队列是持久化的,一旦连接关闭或者客户端腿粗,该排他队列都会被自动删除的。这种队列适用于只限于一个客户端发送读取消息的应用场景。

2)Auto-delete:自动删除,如果该队列没有任何订阅的消费者的话,该队列会被自动删除。这种队列适用于临时队列。

3)Durable:持久化,这个会在后面作为专门讨论。

其他选项,例如如果用户仅仅想查询某一个队列是否已存在,如果不存在,不想建立该队列,仍然可以调用queue.declare,只不过需要将参数passive设为true,传给queue.declare,如果该队列已存在,则会返回true;如果不存在,则会返回Error,但是不会创建新的队列。

生产者发送消息:

在AMQP模型中,Exchange是接收生产者消息并将消息路由到消息队列的关键组件。ExchangeType和Binding决定了消息的路由规则。所以生产者想要发送消息,首先必须要声明一个Exchange和该Exchange对应的Binding。可以通过ExchangeDeclare和BindingDeclare完成。在RabbitMQ中,有三种类型的Exchange:direct、fanout和topic,不同的Exchange会表现出不同的路由行为。Durable是Exchange的持久化属性,这个会在消息持久化章节讨论。声明一个Binding需要提供一个QueueName,ExchangeName和BindingKey。

消费者订阅消息:

在RabbitMQ中消费者有2种方式获取队列中的消息:

a)一种是通过basic.consume命令,订阅某一个队列中的消息,channel会自动在处理完上一条消息之后,接收下一条消息。(同一个channel消息处理是串行的)。除非关闭channel或者取消订阅,否则客户端将会一直接收队列的消息。

b)另外一种方式是通过basic.get命令主动获取队列中的消息,但是绝对不可以通过循环调用basic.get来代替basic.consume,这是因为basic.get RabbitMQ在实际执行的时候,是首先consume某一个队列,然后检索第一条消息,然后再取消订阅。如果是高吞吐率的消费者,最好还是建议使用basic.consume。

如果有多个消费者同时订阅同一个队列的话,RabbitMQ是采用循环的方式分发消息的,每一条消息只能被一个订阅者接收。

消费者在接到消息以后,都需要给服务器发送一条确认命令。如果消费者在接到消息以后还没来得及返回ACK就断开了连接,消息服务器会重传该消息给下一个订阅者,如果没有订阅者就会存储该消息。

既然RabbitMQ提供了ACK某一个消息的命令,当然也提供了Reject某一个消息的命令。当客户端发生错误,调用basic.reject命令拒绝某一个消息时,可以设置一个requeue的属性,如果为true,则消息服务器会重传该消息给下一个订阅者;如果为false,则会直接删除该消息。当然,有可以通过ack,让消息服务器直接删除该消息并且不会重传。

持久化:

RabbitMQ默认是不持久队列、Exchange、Binding以及队列中的消息,这意味着一旦消息服务器重启,所有已声明的队列,Exchange,Binding以及队列中的消息都会丢失。通过设置Exchange和MesageQueue的durable属性为true,可以使得队列和Exchange持久化,但是这还不能使得队列中的消息持久化,这需要生产者在发送消息的时候,将delivery mode设置为2,只有这三个全部设置完成后,才能保证服务器重启不会对现有的队列造成影响。这里需要注意的是,只有durable为true的Exchange和durable为true的Queues才能绑定,否则在绑定时,RabbitMQ都会报错的。持久化对RabbitMQ的性能造成比较大的影响,可能会下降10被不止。

事务:

对事务的支持是AMQP协议的一个重要特性。假设当生产者将一个持久化消息发送给服务器时,因为consume命令本身没有任何Response返回,所以即使服务器崩溃,没有持久化该消息,生产者也无法获知该消息已经丢失。如果此时使用事务,即通过txSelect()开启一个事务,然后发送消息给服务器,然后通过txCommit()提交该事务,即可以保证,如果txCommit()提交了,则该消息一定会持久化,如果txCommit()还未提交即服务器崩溃,则该消息不会被服务器接收。当然RabbitMQ也提供了txRollback()命令用于回滚某一个事务。

Confirm机制:

使用事务固然可以保证只有提交的事务,才会被服务器执行。但是这样同时也将客户端与消息服务器同步起来,这背离了消息队列解耦的本子。RabbitMQ提供了一个更加轻量级的机制来保证生产者可以感知服务器消息是否已被路由到正确的队列中--Confirm。如果设置channel为confirm状态,则通过该channel发送的消息都会被分配一个唯一的ID,然后一旦该消息被正确的路由到匹配的队列中后,服务器会返回给生产者一个Confirm,该Confirm会包含该消息的ID,这样生产者就会知道该消息已被正确分发。对于持久化消息,只有该消息被持久化后,才会返回Confirm。Confirm机制的最大优点在于异步,生产者在发送消息以后,即可继续执行其他任务。而服务器返回Confirm后,会触发生产者的回调函数,生产者在回调函数中处理Confirm信息。如果消息服务器发生异常,导致该消息丢失,会返回给生产者一个ack,表示消息已经丢失,这样生产者就可以通过重发消息,保证消息不丢失。Confirm机制在性能上要比事务优越很多。但是Confirm机制,无法进行回滚,就是一旦服务器崩溃,生产者无法得到Confirm信息,生产者其实本身也不知道该消息已经被持久化,只有继续重发来保证消息不丢失,但是如果原先已经持久化的消息,并不会被回滚,这样队列中就会存在两条相同的消息,系统需要支持去重。

RabbitMQ系列二(构建消息队列)的更多相关文章

  1. 二、消息队列之如何在C#中使用RabbitMQ(转载)

    二.消息队列之如何在C#中使用RabbitMQ 1.什么是RabbitMQ.详见 http://www.rabbitmq.com/. 作用就是提高系统的并发性,将一些不需要及时响应客户端且占用较多资源 ...

  2. 二、消息队列之如何在C#中使用RabbitMQ

    1.什么是RabbitMQ.详见 http://www.rabbitmq.com/. 作用就是提高系统的并发性,将一些不需要及时响应客户端且占用较多资源的操作,放入队列,再由另外一个线程,去异步处理这 ...

  3. 在Node.js中使用RabbitMQ系列二 任务队列

    在上一篇文章在Node.js中使用RabbitMQ系列一 Hello world我有使用一个任务队列,不过当时的场景是将消息发送给一个消费者,本篇文章我将讨论有多个消费者的场景. 其实,任务队列最核心 ...

  4. 高并发架构系列:MQ消息队列的12点核心原理总结

    消息队列已经逐渐成为分布式应用场景.内部通信.以及秒杀等高并发业务场景的核心手段,它具有低耦合.可靠投递.广播.流量控制.最终一致性 等一系列功能. 无论是 RabbitMQ.RocketMQ.Act ...

  5. 【RabbitMQ学习记录】- 消息队列存储机制源码分析

    本文来自 网易云社区 . RabbitMQ在金融系统,OpenStack内部组件通信和通信领域应用广泛,它部署简单,管理界面内容丰富使用十分方便.笔者最近在研究RabbitMQ部署运维和代码架构,本篇 ...

  6. RabbitMQ系列(二)--基础组件

    声明:对于RabbitMQ的学习基于某课网相关视频和<RabbitMQ实战指南>一书,后续关于RabbitMQ的博客都是基于二者 一.什么是RabbitMQ RabbitMQ是开源代理和队 ...

  7. Kafka 消息队列系列之分布式消息队列Kafka

    介绍 ApacheKafka®是一个分布式流媒体平台.这到底是什么意思呢?我们认为流媒体平台具有三个关键功能:它可以让你发布和订阅记录流.在这方面,它类似于消​​息队列或企业消息传递系统.它允许您以容 ...

  8. rabbitmq和redis用作消息队列的区别

    将redis发布订阅模式用做消息队列和rabbitmq的区别: 可靠性redis :没有相应的机制保证消息的可靠消费,如果发布者发布一条消息,而没有对应的订阅者的话,这条消息将丢失,不会存在内存中:r ...

  9. rabbitmq系列二 之工作队列

    ---恢复内容开始--- 1.工作队列的简介 在上一篇中,我们已经写了一个从已知队列中发送和获取消息的程序,在这里,我们创建一个工作队列(work queue), 会发送一些耗时的任务给多个工作者.模 ...

随机推荐

  1. paper 56 :机器学习中的算法:决策树模型组合之随机森林(Random Forest)

    周五的组会如约而至,讨论了一个比较感兴趣的话题,就是使用SVM和随机森林来训练图像,这样的目的就是 在图像特征之间建立内在的联系,这个model的训练,着实需要好好的研究一下,下面是我们需要准备的入门 ...

  2. paper 45:latex的使用

    本教程面向对LaTeX完全无认知无基础的新人. 旨在让新人能够用最简单快捷的方式,轻松入门,能够迅速使用LaTeX完成基本的文本编辑. 尤其旨在破除部分新人对LaTeX在传闻中难以学习的恐惧感. 在入 ...

  3. EBS常用小常识(转)

    值集: 1.编辑信息:取上一个值集所选的数据.(值集关联) WHERE BANK_ACCOUNT_ID = :$FLEX$.CE_BANK_ACCOUNT_NUM_NAME ORDER BY STAT ...

  4. 夺命雷公狗ThinkPHP项目之----企业网站23之网站前台二级分类的跳转(URL跳转到列表页或产品页)

    我们现在开始做实现我们的二级菜单如何跳转到指定的列表页或者产品也呢?? 我们分享下数据库情况: 我们的数据库里提前给我们预留了一个cate_type的字段,那么我们可以让这个字段进行判断,从而遍历出指 ...

  5. Verilog中的specify block和timing check

    在ASIC设计中,有两种HDL construct来描述delay信息: 1)Distributed delays:通过specify event经过gates和nets的time,来描述delay; ...

  6. jQuery讲解

    在讲解jQuery时,要和JavaScript进行对比的讲解,易于理解 JavaScript部分 <title>jquery讲解使用</title> <script sr ...

  7. php curl 抓去远程页面内容

    <?php/*** php curl抓取远程网页内容* edit by www.jbxue.com*/$curlPost = 'a=1&b=2';//模拟POST数据$ch = curl ...

  8. redis make test报错 Test replication partial resync: ok psync

    更改 tests/integration/replication-psync.tcl 文件: vi tests/integration/replication-psync.tcl 把对应报错的那段代码 ...

  9. Linux内存管理原理【转】

    转自:http://www.cnblogs.com/zhaoyl/p/3695517.html 本文以32位机器为准,串讲一些内存管理的知识点. 1. 虚拟地址.物理地址.逻辑地址.线性地址 虚拟地址 ...

  10. 测试过程中LR的关联报错

    在测试过程中,录制的脚本会做一些关联.在测试的过程中,常常出现关联失败的情况. 如果最后的结果有检查点,检查点失败而事务失败. 每次出现这样的情况,我都不知道如何办.为了不出现错误,我都在关联函数里面 ...