10000 Recompile. · seanhuang/rabbitmq-tutorials@e0ec9b5 · GitHub
[go: up one dir, main page]

Skip to content

Commit e0ec9b5

Browse files
committed
Recompile.
1 parent 6cce9c0 commit e0ec9b5

File tree

3 files changed

+77
-76
lines changed

3 files changed

+77
-76
lines changed

python/tutorial-one.md

Lines changed: 14 additions & 14 deletions
Original file line numberDiff line numberDiff line change
@@ -57,15 +57,15 @@ Introduction
5757

5858
RabbitMQ is a message broker. The principle idea is pretty simple: it accepts
5959
and forwards messages. You can think about it as a post office: when you send
60-
mail to the post box and you're pretty sure that Mr. Postman will eventually
60+
mail to the post box you're pretty sure that Mr. Postman will eventually
6161
deliver the mail to your recipient. Using this metaphor RabbitMQ is a post box,
62-
post office and a postman.
62+
a post office and a postman.
6363

6464
The major difference between RabbitMQ and the post office is the fact that it
6565
doesn't deal with the paper, instead it accepts, stores and forwards binary
6666
blobs of data - _messages_.
6767

68-
RabbitMQ uses a weird jargon, but it's simple once you'll get it. For example:
68+
RabbitMQ uses a specific jargon. For example:
6969

7070
* _Producing_ means nothing more than sending. A program that sends messages
7171
is a _producer_. We'll draw it like that, with "P":
@@ -82,7 +82,7 @@ RabbitMQ uses a weird jargon, but it's simple once you'll get it. For example:
8282
is not bound by any limits, it can store how many messages you
8383
like - it's essentially an infinite buffer. Many _producers_ can send
8484
messages that go to the one queue, many _consumers_ can try to
85-
receive data from one _queue_. Queue'll be drawn as like that, with
85+
receive data from one _queue_. A queue will be drawn as like that, with
8686
its name above it:
8787

8888

@@ -91,7 +91,7 @@ RabbitMQ uses a weird jargon, but it's simple once you'll get it. For example:
9191
</div></center>
9292

9393

94-
* _Consuming_ has a similar meaning to receiving. _Consumer_ is a program
94+
* _Consuming_ has a similar meaning to receiving. A _consumer_ is a program
9595
that mostly waits to receive messages. On our drawings it's shown with "C":
9696

9797

@@ -121,10 +121,10 @@ messages from that queue.
121121

122122
> #### RabbitMQ libraries
123123
>
124-
> RabbitMQ speaks AMQP protocol. To use Rabbit you'll need a library that
125-
> understands the same protocol as Rabbit. There is a choice of libraries
126-
> for almost every programming language. Python it's not different and there is
127-
> a bunch of libraries to choose from:
124+
> RabbitMQ speaks a protocol called AMQP. To use Rabbit you'll need a library
125+
> that understands the same protocol as Rabbit. There is a choice of libraries
126+
> for almost every programming language. For python it's not different and there
127+
> is a bunch of libraries to choose from:
128128
>
129129
> * [py-amqplib](http://barryp.org/software/py-amqplib/)
130130
> * [txAMQP](https://launchpad.net/txamqp)
@@ -178,12 +178,12 @@ the message will be delivered, let's name it _test_:
178178

179179

180180
At that point we're ready to send a message. Our first message will
181-
just contain a string _Hello World!_, we want to send it to our
181+
just contain a string _Hello World!_ and we want to send it to our
182182
_test_ queue.
183183

184-
In RabbitMQ a message never can be send directly to the queue, it always
184+
In RabbitMQ a message can never be send directly to the queue, it always
185185
needs to go through an _exchange_. But let's not get dragged by the
186-
details - you can read more about _exchanges_ in [third part of this
186+
details - you can read more about _exchanges_ in [the third part of this
187187
tutorial](http://github.com/rabbitmq/rabbitmq-tutorials/blob/master/python/tutorial-three.md). All we need to know now is how to use a default exchange
188188
identified by an empty string. This exchange is special - it
189189
allows us to specify exactly to which queue the message should go.
@@ -212,7 +212,7 @@ them on the screen.
212212
Again, first we need to connect to RabbitMQ server. The code
213213
responsible for connecting to Rabbit is the same as previously.
214214

215-
Next step, just like before, is to make sure that the
215+
The next step, just like before, is to make sure that the
216216
queue exists. Creating a queue using `queue_declare` is idempotent - we can
217217
run the command as many times you like, and only one will be created.
218218

@@ -223,7 +223,7 @@ You may ask why to declare the queue again - we have already declared it
223223
in our previous code. We could have avoided that if we were sure
224224
that the queue already exists. For example if `send.py` program was
225225
run before. But we're not yet sure which
226-
program to run as first. In such case it's a good practice to repeat
226+
program to run first. In such cases it's a good practice to repeat
227227
declaring the queue in both programs.
228228

229229
> #### Listing queues

python/tutorial-three.md

Lines changed: 33 additions & 31 deletions
Original file line numberDiff line numberDiff line change
@@ -9,19 +9,19 @@ Learning RabbitMQ, part 3 (Broadcast)
99
</div></center>
1010

1111

12-
In [previous part](http://github.com/rabbitmq/rabbitmq-tutorials/blob/master/python/tutorial-two.md) of this tutorial we've learned how
13-
to create a task queue. The core assumption behind a task queue is that a task
12+
In [previous part](http://github.com/rabbitmq/rabbitmq-tutorials/blob/master/python/tutorial-two.md) of this tutorial we created
13+
a task queue. The core assumption behind a task queue is that a task
1414
is delivered to exactly one worker. In this part we'll do something completely
1515
different - we'll try to deliver a message to multiple consumers. This
1616
pattern is known as "publish-subscribe".
1717

18-
To illustrate this this tutorial, we're going to build a simple
19-
logging system. It will consist of two programs - first will emit log
20-
messages and second will receive and print them.
18+
To illustrate this, we're going to build a simple
19+
logging system. It will consist of two programs - the first will emit log
20+
messages and the second will receive and print them.
2121

2222
In our logging system every running copy of the receiver program
23-
will be able to get the same messages. That way we'll be able to run one
24-
receiver and direct the logs to disk, in the same time we'll be able to run
23+
will get the same messages. That way we'll be able to run one
24+
receiver and direct the logs to disk; and at the same time we'll be able to run
2525
another receiver and see the same logs on the screen.
2626

2727
Essentially, emitted log messages are going to be broadcasted to all
@@ -32,14 +32,14 @@ Exchanges
3232
---------
3333

3434
In previous parts of the tutorial we've understood how to send and
35-
receive messages. Now it's time to introduce the full messaging model
36-
in Rabbit.
35+
receive messages to and from a queue. Now it's time to introduce
36+
the full messaging model in Rabbit.
3737

38-
Let's quickly remind what we've learned:
38+
Let's quickly cover what we've learned:
3939

40-
* _Producer_ is user application that sends messages.
41-
* _Queue_ is a buffer that stores messages.
42-
* _Consumer_ is user application that receives messages.
40+
* A _producer_ is user application that sends messages.
41+
* A _queue_ is a buffer that stores messages.
42+
* A _consumer_ is user application that receives messages.
4343

4444

4545
The core idea in the messaging model in Rabbit is that the
@@ -52,7 +52,7 @@ exchange is a very simple thing. On one side it receives messages from
5252
producers and the other side it pushes them to queues. The exchange
5353
must know exactly what to do with a received message. Should it be
5454
appended to a particular queue? Should it be appended to many queues?
55-
Or should it get silently discarded. The exact rules for that are
55+
Or should it get discarded. The exact rules for that are
5656
defined by the _exchange type_.
5757

5858

@@ -89,8 +89,8 @@ queues it knows. And that's exactly what we need for our logger.
8989
> amq.headers headers
9090
> ...done.
9191
>
92-
> You can see a few `amq.` exchanges. They're created by default, but with a
93-
> bit of luck you'll never need to use them.
92+
> You can see a few `amq.` exchanges. They're created by default, but
93+
> chances are you'll never need to use them.
9494
9595
<div></div>
9696

@@ -105,23 +105,24 @@ queues it knows. And that's exactly what we need for our logger.
105105
> routing_key='test',
106106
> body=message)
107107
>
108-
> The _empty string_ exchange is special: message is
108+
> The _empty string_ exchange is special: messages are
109109
> routed to the queue with name specified by `routing_key`.
110110
111111

112112

113113
Temporary queues
114114
----------------
115115

116-
As you may remember previously we were using queues which had a specified name -
117-
`test` in first `task_queue` in second tutorial. Being able to name a
116+
As you may remember previously we were using queues which had a specified name
117+
(remember `test` and `task_queue`?). Being able to name a
118118
queue was crucial for us - we needed to point the workers to the same
119-
queue. Essentially, giving a queue a name is important when you don't
120-
want to loose any messages when the consumer disconnects.
119+
queue. Essentially, giving a queue a name is important when you
120+
want to share the queue between multiple con 10000 sumers.
121121

122-
But that's not true for our logger. We do want to hear only about
123-
currently flowing log messages, we do not want to hear the old
124-
ones. To solve that problem we need two things.
122+
But that's not true for our logger. We do want to hear about all
123+
currently flowing log messages, we do not want to receive only a subset
124+
of messages. We're also interested only in currently flowing messages
125+
not in the old ones. To solve that we need two things.
125126

126127
First, whenever we connect to Rabbit we need a fresh, empty queue. To do it
127128
we could create a queue with a random name, or, even better - let server
@@ -152,7 +153,7 @@ Bindings
152153

153154

154155
We've already created a fanout exchange and a queue. Now we need to
155-
tell the exchange to send messages to our queue. That relationship,
156+
tell the exchange to send messages to our queue. That relationship
156157
between exchange and a queue is called a _binding_.
157158

158159
<div><pre><code class='python'>channel.queue_bind(exchange='logs',
@@ -165,7 +166,7 @@ our queue.
165166
> #### Listing bindings
166167
>
167168
> You can list existing bindings using, you guessed it,
168-
> `rabbitmqctl list_bindings` command.
169+
> `rabbitmqctl list_bindings`.
169170
170171

171172
Putting it all together
@@ -179,9 +180,9 @@ Putting it all together
179180

180181
The producer program, which emits log messages, doesn't look much
181182
different than in previous tutorial. The most important change is
182-
that, we now need to publish messages to `logs` exchange instead of
183-
the nameless one. We need to supply the `routing_key` parameter, but
184-
it's value is ignored for `fanout` exchanges. Here goes the code for
183+
that, we now need to publish messages to the `logs` exchange instead of
184+
the nameless one. We need to supply a `routing_key`, but
185+
its value is ignored for `fanout` exchanges. Here goes the code for
185186
`emit_log.py` script:
186187

187188
<div><pre><code class='python'>#!/usr/bin/env python
@@ -201,9 +202,10 @@ print &quot; [x] Sent %r&quot; % (message,)</code></pre></div>
201202

202203
[(emit_log.py source)](http://github.com/rabbitmq/rabbitmq-tutorials/blob/master/python/emit_log.py)
203204

204-
As you see, we avoided declaring exchange. If the `logs` exchange
205+
As you see, we avoided declaring exchange here. If the `logs` exchange
205206
isn't created at the time this code is executed the message will be
206-
lost. That's okay for us.
207+
lost. That's okay for us - if no consumer is listening yet (ie:
208+
the exchange hasn't been created) we can discard the message.
207209

208210
The code for `receive_logs.py`:
209211

0 commit comments

Comments
 (0)
0