(using the pika 0.10.0 Python client)
In the previous tutorial we built a simple logging system. We were able to broadcast log messages to many receivers.
In this tutorial we‘re going to add a feature to it - we‘re going to make it possible to subscribe only to a subset of the messages. For example, we will be able to direct only critical error messages to the log file (to save disk space), while still being able to print all of the log messages on the console.
# 以上均是客套话，哥自己看的懂就算了，不给翻译了，节省时间，哈哈。
Bindings
In previous examples we were already creating bindings. You may recall code like:
channel.queue_bind(exchange=exchange_name,queue=queue_name)
A binding is a relationship between an exchange and a queue. This can be simply read as: the queue is interested in messages from this exchange.
Bindings can take an extra routing_key parameter. To avoid the confusion with a basic_publishparameter we‘re going to call it a binding key. This is how we could create a binding with a key:
# 简单的翻译下：绑定是exchange和队列之间的一种关系，这可以简单的理解为： 这个队列对来自于exchange的信息非常感兴趣，绑定需要采取一个额外的参数routing_key , 为了避免这个有关于basic_publish 这个参数的困惑，我们准备称呼它为binding key,这就是我们如何用一个钥匙创建一个绑定
channel.queue_bind(exchange=exchange_name,queue=queue_name,routing_key=‘black‘)
The meaning of a binding key depends on the exchange type. The fanout exchanges, which we used previously, simply ignored its value.
#translate: 这个意思是说 绑定钥匙取决于exchange的类型，这个扇出exchange，是我们以前使用过的，简单的忽略其值
Direct exchange
Our logging system from the previous tutorial broadcasts all messages to all consumers. We want to extend that to allow filtering messages based on their severity. For example we may want the script which is writing log messages to the disk to only receive critical errors, and not waste disk space on warning or info log messages.
We were using a fanout exchange, which doesn‘t give us too much flexibility - it‘s only capable of mindless broadcasting.
We will use a direct exchange instead. The routing algorithm behind a direct exchange is simple - a message goes to the queues whose binding key exactly matches the routing keyof the message.
# translate：我们的日志系统从前面的教程里面可知会广播信息到所有的消费者，我们想扩展它，允许基于信息的严重性来过滤一些信息，例如我们可以想要这个脚本只把接收到的极重要的错误信息写入磁盘，不想把磁盘的空间浪费在警告或者提示信息里面
我们使用扇出交换器，这个扇出exchange不会给我们太多的灵活性，它，它只能怪盲目的广播。
我们也会使用直连交换器去替代扇出exchange，这个直连exchange背后的路由算法更加简单，一条信息能准确匹配到到绑定了key的队列里面。
To illustrate that, consider the following setup:
In this setup, we can see the direct exchange X with two queues bound to it. The first queue is bound with binding key orange, and the second has two bindings, one with binding key blackand the other one with green.
In such a setup a message published to the exchange with a routing key orange will be routed to queue Q1. Messages with a routing key of black or green will go to Q2. All other messages will be discarded.
# translate: 在这一步，我们能够看到这个直连交换器x被两个队列所束缚住，这个第一个队列是束缚住了orange这个key，第二个有两个绑定，一个绑定的key是blackend，另一个key是green
Emitting logs
We‘ll use this model for our logging system. Instead of fanout we‘ll send messages to a directexchange. We will supply the log severity as a routing key. That way the receiving script will be able to select the severity it wants to receive. Let‘s focus on emitting logs first.
# translate: 我们为我们的日志系统使用这个模型，我们发送信息到直连exchange上而不是扇出exchange,我们能够提供这个日志严重程度对于routing key，在这种方式下接收脚本能够去选择他想要接受的严重性，首先让我们集中精力在这发送日志脚本上
Like always we need to create an exchange first:
channel.exchange_declare(exchange=‘direct_logs‘,type=‘direct‘)
And we‘re ready to send a message:
channel.basic_publish(exchange=‘direct_logs‘,routing_key=severity,body=message)
To simplify things we will assume that ‘severity‘ can be one of ‘info‘, ‘warning‘, ‘error‘.
Subscribing
Receiving messages will work just like in the previous tutorial, with one exception - we‘re going to create a new binding for each severity we‘re interested in.
result=channel.queue_declare(exclusive=True)queue_name=result.method.queueforseverityinseverities:channel.queue_bind(exchange=‘direct_logs‘,queue=queue_name,routing_key=severity)
Putting it all together
