(二)rabbitmq python 踩坑记录

2017-01-13 19:13:48来源:CSDN作者:cloudmq人点击

第七城市

(二)RabbitMQ python部分api的使用


写在前面的
以为日常做的东西杂,多,不经常写的话容易忘。记录一些api的说明,方便以后的使用。也供需要的剪子们参考(可能会有错误,有错请留言,尽情拍砖)


direct

a.直连,publisher发送消息后,投递到绑定到同一个exchange上的所有queue.消息路由是通过routing_key来路由,与queue_name没有太大的关系
要求:consumer的exchangename 和 routing_key 与 publisher要一致,否则消息不会被处理
b.消息会轮流给每个consumer发送

durable

使用durable=True声明queue是持久化的,这样即便MQ崩溃了重启后queue仍然存在,这样可以防止消息的丢失。

delivery_mode

除了要声明queue是持久化的外,还需声明message是持久化的basic_publish的properties参数指定message的属性 此处pika.BasicProperties中的delivery_mode=2指明message为持久的,这样一来RabbitMQ崩溃重启后queue仍然存在其中的message也仍。但需注意的是将message标记为持久的并不能完全保证message不丢失,因为从RabbitMQ接收到message到将其存储到disk仍需一段时间,若此时RabbitMQ崩溃则message会丢失。况且RabbitMQ不会对每条message做fsync动作。这时可通过publisher confirms实现更强壮的持久性保证。
a.exchange持久化,在声明时指定durable => 1
b.queue持久化,在声明时指定durable => 1
c.消息持久化,在投递时指定delivery_mode => 2(1是非持久化)

channel.basic_publish(exchange=’test_exchange’, routing_key=’standard_key’, body=’queue:group’, properties=pika.BasicProperties(content_type=’text/plain’, delivery_mode=1))

basic_ack

在处理完消息时,返回应答状态。你要默认加上,别忘了!!!
channel.basic_ack(delivery_tag = method.delivery_tag)
假如不返回应答状态,即使这个consumer处理完成当前的任务,他也不会去从任务池里取下个任务,会一直等待下去(这是不合理的),他处理完后不会去通知publish,是给mq说一声,我处理完了这个任务了,再给我一个任务吧。否则mq会认为,这家伙那么忙,我找别人干活去,不给他任务了。

no_ack

channel.basic_consume(on_message, ‘queuename’,no_ack=False);basic_consume里的参数里no_ack的含义为no_ack=False意思为,您需要手动设置一下,即调用basic_ack来决定消息处理是否处理完成.这种状态下,publish发送的任务会到任务池里,增加consume时,直接从任务池里取任务
当调用basic_consume(…no_ack=True…)时,所有的任务都会分配给当前正在执行的consume,因为mq会把当前的consume当成空闲状态,consume接受任务后,立即回给mq说干完了(和perfetch_count不冲突)。(例如:当前正在执行3个consume,当第四个consume来到后,会检索到任务池里没有任务,因为任务全部被consume执行了,所以publish再次执行4次才可以被第4个consume发现)

prefetch_count:

channel.basic_qos(prefetch_count= 1 ): 这个是流量控制,比如我有5个consumer在同时消费,publisher发送任务后,consumer自动去任务池里去获取任务,处理完后,再次去取任务,直到任务完全取完。每个consumer都最大分配1个任务。当第6个consumer来到后,也是直接拿起任务就干.
若prefetch_count=2,那么每个consumer最大容纳2个任务。比如任务池里有10个任务(假设任务是耗时的,很长时间才能处理完毕),当前只有3个consumer(a,b,c)在执行。任务分配的情况:a->1,b->2,c->3,a->4,b->5,c->6.(刚开始是抢任务,每个consumer抢一个,轮完后发现还有任务,再第二轮抢,此时a的第二轮有肯能是任务5,任务6,视其效率而定)任务7,8,9,10就得等待。此时第4个consumer到了,会拿到7,8。
举个通俗的例子:
学校买个10张桌子给1班,每个桌子最大可以做2个学生。 假如有10个学生,老师决定,每个桌子坐1个学生。刚好分完。假如有15个学生,那么部分桌子是2个人的,其余的还是1个人。此时,又来了一张桌子,又来了5个学生,老师说了,新桌子不准用,旧桌子啥时候坐满了,啥时候再用新桌子。那么第11张桌子只能等到第21个学生来了(桌子=consumer,学生=publisher,老师=规则)

passive

channel.exchange_declare(exchange="test_exchange", exchange_type="direct", passive=False, durable=True, auto_delete=False)

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

Exclusive

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

auto_delete

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

第七城市

最新文章

123

最新摄影

微信扫一扫

第七城市微信公众平台