This document is for Kombu's development version, which can be significantly different from previous releases. Get the stable docs here: 5.0.

引言¶

什么是消息传递？¶

在很久以前，人们没有电子邮件。他们有邮政服务，这种服务以极大的勇气将邮件送到世界各地。部署在遥远战地的士兵只能通过邮政服务与家人联系，而邮寄信件意味着收信人要到几周或几个月后，有时是几年后才能真正收到信。

今天很难想象这一点，因为人们被期望在一天的每分钟都可以打电话。

因此，人类需要相互通信，这对任何人来说都不是新闻，但为什么应用程序会呢？

银行就是一个例子。当你从一家银行向另一家银行转账时，你的银行会向中央票据交换所发送一个信息。然后，票据交换所记录和协调交易。银行每天需要发送和接收数以百万计的消息，而丢失一条消息将意味着要么损失你的钱(坏账)，要么损失银行的钱(非常糟糕)

另一个例子是证券交易所，它们也需要非常高的消息吞吐量，并有严格的可靠性要求。

电子邮件是人们交流的一种很好的方式。这比使用邮政服务快得多，但仍然使用电子邮件作为程序通信的手段，就像上面的士兵一样，等待家乡女友的生命迹象。

请求/回复

请求/回复模式的工作原理与邮政服务示例类似。邮件的收件人是单一收件人，背面印有回邮地址。收件人可以通过将邮件发回原始发件人来回复邮件，也可以不回复邮件。

请求-回复是通过使用 direct 交流。
广播

在广播场景中，消息被发送到所有各方。这可以是无收件人、一个收件人或多个收件人。

通过以下方式实现广播 fanout 交流。
发布/订阅

在发布/订阅场景中，生产者向主题发布消息，消费者订阅他们感兴趣的主题。

如果没有消费者订阅该主题，则消息将不会传递给任何人。如果几个消费者订阅了该主题，则消息将被传递给他们所有人。

发布-订阅是通过使用 topic 交流。

对于某些应用来说，可靠性非常重要。丢失消息是一种绝对不能发生的危急情况。对于其他应用程序，丢失消息是可以的，它可能会以其他方式恢复，或者消息无论如何都会作为定期更新重新发送。

AMQP定义了两种内置交付模式：

到目前为止，瞬时消息传递是发送和接收消息的最快方式，因此拥有持久消息是有代价的，但对于某些应用程序来说，这是必要的代价。