101 lines
3.2 KiB
ReStructuredText
101 lines
3.2 KiB
ReStructuredText
.. _guide-intro:
|
|
|
|
==============
|
|
Introduction
|
|
==============
|
|
|
|
.. _intro-messaging:
|
|
|
|
What is messaging?
|
|
==================
|
|
|
|
In times long ago people didn't have email.
|
|
They had the postal service, which with great courage would 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, 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?
|
|
|
|
One example is banks.
|
|
When you transfer money from one bank to another, your bank sends
|
|
a message to a central clearinghouse. The clearinghouse
|
|
then records and coordinates the transaction. Banks
|
|
need to send and receive millions and millions of
|
|
messages every day, and losing a single message would mean either losing
|
|
your money (bad) or the banks money (very bad)
|
|
|
|
Another example is the stock exchanges, which also have a need
|
|
for very high message throughputs and have 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 soldier above, waiting
|
|
for signs of life from his girlfriend back home.
|
|
|
|
.. _messaging-scenarios:
|
|
|
|
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 recipient may or may not reply to the
|
|
message by sending it back to the original sender.
|
|
|
|
Request-Reply is achieved using *direct* exchanges.
|
|
|
|
* Broadcast
|
|
|
|
In a broadcast scenario a message is sent to all parties.
|
|
This could be none, one or many recipients.
|
|
|
|
Broadcast is achieved using *fanout* exchanges.
|
|
|
|
* Publish/Subscribe
|
|
|
|
In a publish/subscribe scenario producers publish messages
|
|
to topics, and consumers subscribe to the topics they are
|
|
interested in.
|
|
|
|
If no consumers subscribe to the topic, then the message
|
|
will not be delivered to anyone. If several consumers
|
|
subscribe to the topic, then the message will be delivered
|
|
to all of them.
|
|
|
|
Pub-sub is achieved using *topic* exchanges.
|
|
|
|
.. _messaging-reliability:
|
|
|
|
Reliability
|
|
===========
|
|
|
|
For some applications reliability is very important. Losing a message is
|
|
a critical situation 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 defines two built-in delivery 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 having persistent messages comes with a price, but for some
|
|
applications this is a necessary cost.
|