mirror of https://github.com/celery/kombu.git
working on an introduction section in the userguide
This commit is contained in:
parent
aceaa71956
commit
c1db84a6c1
|
@ -0,0 +1,75 @@
|
||||||
|
What is messaging?
|
||||||
|
==================
|
||||||
|
|
||||||
|
In times long ago people didn't have email.
|
||||||
|
They had the postal service, which would couragely deliver mail,
|
||||||
|
from hand to hand all over the globe. Soldiers deployed at wars far away could only
|
||||||
|
communicate with their families through the postal service, and
|
||||||
|
posting a letter would mean that the recipient wouldn't actually
|
||||||
|
receive the letter until weeks or months, and sometimes years later.
|
||||||
|
It's hard to imagine this today when people are expected to be available
|
||||||
|
for phone calls every minute of the day.
|
||||||
|
|
||||||
|
So humans need to communicate with each other, this shouldn't
|
||||||
|
be news to anyone, but why would applications want to send
|
||||||
|
messages?
|
||||||
|
|
||||||
|
One example is the banks.
|
||||||
|
When you transfer money from one bank to another, this is sent
|
||||||
|
as a message to the banks messaging central. Banks
|
||||||
|
need to send and receive millions and millions of these
|
||||||
|
messages every day, and losing a single message would mean either losing
|
||||||
|
your money (bad) or the banks money (very bad)
|
||||||
|
|
||||||
|
Another is the stock exchange, which also have a need
|
||||||
|
for very high message througputs and strict reliability requirements.
|
||||||
|
|
||||||
|
Email is a great way for people to communicate. It is much faster
|
||||||
|
than using the postal service, but still using email as a means for
|
||||||
|
programs to communicate would be like the solider above, waiting
|
||||||
|
for signs of life from his girlfriend back home.
|
||||||
|
|
||||||
|
Messaging Scenarios
|
||||||
|
===================
|
||||||
|
|
||||||
|
* Request/Reply
|
||||||
|
|
||||||
|
The request/reply pattern works like the postal service example.
|
||||||
|
A message is addressed to a single recipient, with a return address
|
||||||
|
printed on the back. The receipient may or may not reply to the
|
||||||
|
message by sending it back to the original sender.
|
||||||
|
|
||||||
|
Request-Reply is achieved using *direct* exchanges.
|
||||||
|
|
||||||
|
* Broadcast
|
||||||
|
|
||||||
|
Broadcast is achieved using *fanout* exchanges.
|
||||||
|
|
||||||
|
* Publish/Subscribe
|
||||||
|
|
||||||
|
Pubsub is achieved using *topic* exchanges.
|
||||||
|
|
||||||
|
Reliability
|
||||||
|
===========
|
||||||
|
|
||||||
|
For some applications reliability is very important. Losing a message is
|
||||||
|
a critical situtation that must never happen. For other applications
|
||||||
|
losing a message is fine, it can maybe recover in other ways,
|
||||||
|
or the message is resent anyway as periodic updates.
|
||||||
|
|
||||||
|
AMQP comes with two persistency modes:
|
||||||
|
|
||||||
|
* persistent
|
||||||
|
|
||||||
|
Messages are written to disk and survives a broker restart.
|
||||||
|
|
||||||
|
* transient
|
||||||
|
|
||||||
|
Messages may or may not be written to disk, as the broker sees fit
|
||||||
|
to optimize memory contents. The messages will not survive a broker
|
||||||
|
restart.
|
||||||
|
|
||||||
|
Transient messaging is by far the fastest way to send and receive messages,
|
||||||
|
so persistency comes with a price, but a necessary cost.
|
||||||
|
|
||||||
|
|
Loading…
Reference in New Issue