之前发布的文章因为在编辑后代码部分在手机上看不清已被及时删除,本文重新编辑好之后再发布一次,带来不便请谅解! 專 欄 ZZR,Python中文社区专栏作者,OpenStack工程师,曾经的NLP研究者。主要兴趣方向:OpenStack、Python爬虫、Python数据分析。 Blog:http:/// fanout exchange 在上一篇中,task_queue所解决的问题是,一个message只能被一种consumer所接收。现在我们有了新的需求,我们需要一个日志系统,我们希望有两种consumer,一种consumer将日志输出到屏幕,另一种consumer写到disk。为了实现这个目的,我们希望message被投到两个queue中,交给不同的consumer进行处理。如下所示: 对于producer,不再指定哪一个queue来接收消息,而是哪一个exchange来接收消息。exchange不保存信息,如果没有queue绑定在这个exchange上的话,消息就丢失了。代码如下: 对于consumer,自己创建临时queue( 如下图所示,每一个consumer都建了自己的临时queue,并与exchange进行了绑定: direct exchange 上面的例子中,queue_bind()的时候我们没有指定routing_key(为了避免混淆,后续将其称为binding_key)。binding_key的功能与exchange的类型有关。对于fanout exchange而言,binding_key没有意义。对于direct exchange而言,如下图所示,只有消息的routing_type与queue的binding_key相同时才会发送到该queue: 可以指定相同的binding_key,如下图所示: 借此,我们可以将日志系统改造为以下模式,不同的consumer只接收特定类型的日志信息: 完整代码如下: topic exchang topic exchange与direct exchange类似,只是它允许binding_key使用特殊字符(注意,特殊字符代表的是单词,不是字母): - 比如下面这个例子。routing_key定义为 当binding_key不使用这些特殊字符时,topic exchange其实就是direct exchange;当binding_key使用 一些极端的例子: 完整代码: 总结 在上一篇中: 再回顾一下上面的代码。首先明确,这种情况使用的是默认exchange。对于producer,它将消息交给exchange,然后exchange通过routing key来判断要将消息交到哪个queue。实际上相当于将消息直接发送到queue中。而consumer直接指定queue的名字,也就是它直接绑定到这个queue。这个过程中exchange其实没什么存在感。 而这一篇,实际上producer只认exchange。它只负责将消息交给exchange。consumer自己搭建queue,将queue绑定到它感兴趣的exchange上。exchange决定它以什么样的形式提供服务,是fanous还是direct。 ⊙生成器: 关于生成器的那些事儿 ⊙爬虫代理: 如何构建爬虫代理服务 ⊙地理编码: 怎样用Python实现地理编码 ⊙nginx日志: 使用Python分析nginx日志 ⊙ 淘宝女郎: 一个批量抓取淘女郎写真图片的爬虫 ⊙ IP代理池: 突破反爬虫的利器——开源IP代理池 ⊙ 布隆去重: 基于Redis的Bloomfilter去重(附代码) ⊙ 内建函数: Python中内建函数的用法 ⊙ QQ空间爬虫: QQ空间爬虫最新分享,一天 400 万条数据 ⊙ 对象: Python教你找到最心仪对象 ⊙ 线性回归: Python机器学习算法入门之梯度下降法实现线性回归⊙ 匿名代理池:进击的爬虫:用Python搭建匿名代理池⊙ 发射导弹:Python发射导弹的正确姿势 |
|
来自: LibraryPKU > 《Python》