導入された概念に基づいてのRabbitMQのメッセージング・ミドルウェア

A、AMQPの概要

何1.AMQPこと？

AMQP：RabbitMQのプロトコルうち、あなたがしなければならない最初の図を説明する前に。

AMQP（アドバンスト・メッセージ・キューイング・プロトコル、高度なメッセージキュープロトコル）、ミドルウェアメッセージングのために特別に設計されたネットワークプロトコルであり、それは（ミドルウェアブローカーメッセージング）クライアントアプリケーション（アプリ）とメッセージングミドルウェアエージェントの要件は間で行わ出会いをサポートしています通信。メッセージミドルウェアに基づいてのみのActiveMQのJavaプラットフォームとして使用することは、JMS仕様を実装しました。そして限り自然なクロスプラットフォームの機能を備えたメッセージベースのミドルウェアAQMPプロトコルの実装、など、制限は、言語の発達に影響されないのJavaやPython、C＃および他の多くの開発言語は、RabbitMQのよう、サポートしています。

何2.RabbitMQこと？

RabbitMQのがAQMPを実現し、大規模、高可用性の要件を満たすために、分散及び関節構成で配置することができるアーラン・メッセージング・ミドルウェアによって開発された言語です。

3. Message Agentは、彼らが果たす役割

メッセージ・ブローカ（メッセージブローカ）があり、また、生産者（プロデューサ）として知られている発行元からのメッセージ（出版社）、受信するために確立されたルーティング規則に従いを消費者がメッセージ（消費者）を処理するために、受信されたメッセージを送信します。

AMQPは、ネットワークプロトコル、放出のようなプロセスであるので、消費者は、メッセージ・ブローカは、異なるデバイス上に存在することができます。

4.AMQP 0-9-1モデルのプロフィール

下に示すように、AMQP 0-9-1作業工程：

発行者（発行者）は、スイッチ（交換機）に送信されるメッセージ（メッセージ）は、スイッチは、多くの場合、郵便局またはメールボックスになぞらえされます。
次いで、分散キュー（待ち行列）を結合ルーティングルールに従って、受信したメッセージを切り替えます。
最後にAMQPエージェントはオンデマンドで自分のを得るために、このキューに登録し、消費者、または消費者に配信されるメッセージが送信されます。

出版社は、ときにメッセージニュースリリースメッセージにさまざまな属性を割り当てることができます。一部の属性は、メッセージ・ブローカーが使用することができるが、他のプロパティは、彼らが唯一のメッセージを受信するためにアプリケーションが完全に不透明で使用することができますされています。

セキュリティの観点からは、ネットワークが信頼できない場合、アプリケーションは、メッセージを処理するとき、メッセージはまた失敗することがあり受け取ります。このため、AMQPモジュールは、メッセージの確認応答の概念が含まれています。メッセージは、消費者へのキューから配信されると、消費者はこれを自動化することができ、報道機関について通知されますが、それはまた、アプリケーション開発者メッセージによって処理することができます実行。「メッセージの確認応答が」有効にすると、それは消費者からの確認領収書を受け取るまで、Message Agentは完全にメッセージをキューから削除されません。

このようなメッセージが正常にルーティングすることができない場合など、いくつかのケースでは、メッセージは、出版社に戻り、破棄されることがあります。メッセージは、エージェントが実行された操作を遅らせる場合は代わりに、メッセージはいわゆる不能キューに配置されます。この場合、メッセージの発行者は、これらの特殊なケースを処理するために、特定のパラメータを選択することができます。

キュー、スイッチ及び結合実体はAMQP（AMQPエンティティ）と呼ばれます。

第二に、スイッチ（交換）タイプ、およびスイッチ

スイッチAMQPエンティティは、メッセージを送信するために使用されます。スイッチのルーティング後は、キューまたはゼロにメッセージを取得します。これは、ルーティング・アルゴリズムは、スイッチタイプと決定により結合ルール（バインディング）と呼ばれる使用します。AMQP 0-9-1プロキシは、4つのスイッチが用意されています。

名前（スイッチタイプ）	デフォルトの事前宣言名（デフォルト名は事前宣言しました）
直接交換（方向スイッチ）	（空文字列）とamq.direct
ファンアウト交換（扇形スイッチ）	amq.fanout
トピックエクスチェンジ（テーマスイッチ）	amq.topic
ヘッダ交換（ヘッドスイッチ）	amq.match（およびRabbitMQの中amq.headers）

スイッチタイプに加えて、スイッチを伴う文の中で最も重要なものであるかを、他の多くの性質を持つことができます。

名前
耐久性改訂（再起動のメッセージブローカ後、そこにスイッチするかどうか）
自動削除（このスイッチの使用を完了しているにバインドされているすべてのキューのメッセージの後に、それを削除します）
引数（従属エージェント自身）

持続（耐久性）、一時的な（過渡）：**スイッチは、2つの状態を持つことができます。**スイッチの持続性は、依然としてメッセージ・ブローカー（仲介）の再起動後も存在しますが、一時的なスイッチは、（彼らは再びライン上のエージェントの後に宣言する必要があります）はありません。しかし、すべてのシナリオは、永続的なスイッチを必要としません。

1.スイッチのデフォルト（既定交換）

デフォルトのスイッチが実際に事前に報道機関によって優れた声明で、何の名前は（名前は空の文字列）を直接接続されていないスイッチ（直接交換）。それは特別なプロパティは、単純なアプリケーションに特に有用なものがあります、であることを自動的キューの名前と同じ名前（キーをルーティング）ルーティングのデフォルトキーバインディングを切り替えるにバインドされたそれぞれの新しいキュー（待ち行列）。

栗の場合：あなたは、「検索・インデックス・オンライン」と呼ばれるキューがある宣言した場合、AMQPエージェントは自動的にデフォルトのスイッチにバインドし、ルーティング（結合）の結合は、キー名である検索-indexing-を」でありますオンライン」。名前のキーをルーティング運ぶ際にこのようにして、「検索・インデックス・オンライン」のデフォルトのメッセージには、スイッチに送信され、スイッチメッセージは、「検索・インデックス・オンライン」の名前のデフォルトのキューにルーティングすることができます。言い換えれば、それはそうです、そうではありません技術的に関連の操作を行うが、キューに直接、デフォルトのメッセージ配信を切り替えることが可能です。

2方向スイッチ（直接交換）

スイッチは、直接メッセージに結合されているキューに配信されたメッセージに対応する（キールーティング）キーをルーティング運びます。（ルーティングユニキャスト）メッセージを処理するため**直接ユニキャストルーティングスイッチ（それはまた、マルチキャストルーティングを扱うことができるが）。**下記それがどのように動作するかについて説明します。

バインディングキー（ルーティングキー）を付与しながら、スイッチへのルートを結合するキュー
結合は、経路を搬送されたときにRメッセージが直接それが同じ値に結合するルートスイッチに接続され送信されたときにRキュー。

方向スイッチは、多くの場合、ループの労働者（作業者）の複数のタスクを分散するために使用されます。その際、我々はそれを理解する必要がAMQP 0-9-1に、メッセージではなくキューよりも消費者（消費者）の間で行われる間の負荷分散があります。

ダイレクトスイッチ凡例：

直接交換ルーティング

3.ファンスイッチ（ファンアウト交換）

ルーティングキーバインディングに関係なく、その身体の全てに結合するメッセージキューをルーティング**ファンスイッチ（funout交換）。メッセージは、そのファンのスイッチに送信されたときに** Nキューがファンのスイッチにバインドされている場合、スイッチはすべてのNキューに送信されたメッセージをコピーします。メッセージ（ブロードキャストルーティング）をルーティングするための放送スイッチを処理するためのファン。

ファンスイッチはそれにバインドされたすべてのキューにメッセージのコピーを提供するので、自分のアプリケーションの例は非常に似ているので：

大規模多人数参加型オンライン（MMO）ゲームは、グローバルリーダーボードの更新や他の事象に対処するためにそれを使用することができます
スポーツのニュースサイト、モバイルクライアントにほぼリアルタイムのスコアの更新に使用することができます
さまざまなステータスおよび設定の更新をブロードキャストする物流システムの使用も
ときに、ユーザーにメッセージを配信するために使用されるグループチャットは、グループチャットに参加します。（AMQPはなしXMPP、プレゼンスの概念を内蔵しており、それゆえ、より良い選択かもしれません）

セクタースイッチ凡例：

ファンアウト交換ルーティング

4.スイッチのテーマ（トピック交換）

**ルーティング及び1つ以上のキューにメッセージをルーティングする、結合モードスイッチとの間のキーと一致するようにメッセージ・キューイングによってスイッチ話題（話題交換）。**話題スイッチは、多くの場合、配信/サブスクリプションモデルとその亜種の多様性を実装するために使用されています。テーマスイッチは、典型的には、マルチキャストルーティングメッセージ（マルチキャストルーティング）を実装するために使用されます。

テーマスイッチ凡例：

トピック交換

主题交换机拥有非常广泛的用户案例。无论何时，当一个问题涉及到那些想要有针对性的选择需要接收消息的多消费者/多应用（multiple consumers/applications）的时候，主题交换机都可以被列入考虑范围。

使用案例：

分发有关于特定地理位置的数据，例如销售点
由多个工作者（workers）完成的后台任务，每个工作者负责处理某些特定的任务
股票价格更新（以及其他类型的金融数据更新）
涉及到分类或者标签的新闻更新（例如，针对特定的运动项目或者队伍）
云端的不同种类服务的协调
分布式架构/基于系统的软件封装，其中每个构建者仅能处理一个特定的架构或者系统。

5.头交换机（headers exchange）

有时消息的路由操作会涉及到多个属性，此时使用消息头就比用路由键更容易表达，头交换机就是为此而生的。**头交换机使用多个消息属性来代替路由键建立路由规则。**通过判断消息头的值能否与指定的绑定相匹配来确立路由规则。

我们可以绑定一个队列到头交换机上，并给他们之间的绑定使用多个用于匹配的头（header）。消息代理需要考虑某条消息（message）是需要部分匹配还是全部匹配，所以应用开发者需要定义"x-match"参数，和消息一起发给消息代理。当"x-match"设置为“any”时，消息头的任意一个值被匹配就可以满足条件，而当"x-match"设置为“all”的时候，就需要消息头的所有值都匹配成功。

头交换机可以视为直连交换机的另一种表现形式。头交换机能够像直连交换机一样工作，不同之处在于头交换机的路由规则是建立在头属性值之上，而不是路由键。路由键必须是一个字符串，而头属性值则没有这个约束，它们甚至可以是整数或者哈希值（字典）等。

三、队列（queue）

AMQP中的队列跟其他消息队列或任务队列中的队列是很相似的：它们存储着即将被应用消费掉的消息。队列跟交换机共享某些属性，但是队列也有一些另外的属性。

Name
Durable（消息代理重启后，队列依旧存在）
Exclusive（只被一个连接（connection）使用，而且当连接关闭后队列即被删除）
Auto-delete（当最后一个消费者退订后即被删除）
Arguments（一些消息代理用他来完成类似与TTL的某些额外功能）

队列在声明（declare）后才能被使用。

如果一个队列尚不存在，声明一个队列会创建它。
如果声明的队列已经存在，并且属性完全相同，那么此次声明不会对原有队列产生任何影响。
如果声明中的属性与已存在队列的属性有差异，那么一个错误代码为406的通道级异常就会被抛出。

1.队列名称

队列的名字可以由应用（application）来取，也可以让消息代理（broker）直接生成一个。队列的名字可以是最多255字节的一个utf-8字符串。若希望AMQP消息代理生成队列名，需要给队列的name参数赋值一个空字符串：在同一个通道（channel）的后续的方法（method）中，我们可以使用空字符串来表示之前生成的队列名称。之所以之后的方法可以获取正确的队列名是因为通道可以默默地记住消息代理最后一次生成的队列名称。

以"amq."开始的队列名称被预留做消息代理内部使用。 如果试图在队列声明时打破这一规则的话，一个通道级的403 (ACCESS_REFUSED)错误会被抛出。

2.队列持久化

持久化队列（Durable queues）会被存储在磁盘上，当消息代理（broker）重启的时候，它依旧存在。 没有被持久化的队列称作暂存队列（Transient queues）。并不是所有的场景和案例都需要将队列持久化。

持久化的队列并不会使得路由到它的消息也具有持久性。 倘若消息代理挂掉了，重新启动，那么在重启的过程中持久化队列会被重新声明，无论怎样，只有经过持久化的消息才能被重新恢复。

四、绑定（Binding）

绑定是交换机（exchange）将消息（message）路由给队列（queue）所需遵循的规则。如果要指示交换机“E”将消息路由给队列“Q”，那么“Q”就需要与“E”进行绑定。绑定操作需要定义一个可选的路由键（routing key）属性给某些类型的交换机。路由键的意义在于从发送给交换机的众多消息中选择出某些消息，将其路由给绑定的队列。

打个比方：

队列（queue）是我们想要去的位于纽约的目的地
交换机（exchange）是JFK机场
绑定（binding）就是JFK机场到目的地的路线。能够到达目的地的路线可以是一条或者多条

拥有了交换机这个中间层，很多由发布者直接到队列难以实现的路由方案能够得以实现，并且避免了应用开发者的许多重复劳动。

如果AMQP的消息无法路由到队列（例如，发送到的交换机没有绑定队列），消息会被就地销毁或者返还给发布者。如何处理取决于发布者设置的消息属性。

五、消费者（Consumer）

消息如果只是存储在队列里是没有任何用处的。被应用消费掉，消息的价值才能够体现。在AMQP 0-9-1 模型中，有两种途径可以达到此目的：

将消息投递给应用 (“push API”)
应用根据需要主动获取消息 (“pull API”)

使用push API，应用（application）需要明确表示出它在某个特定队列里所感兴趣的，想要消费的消息。如是，我们可以说应用注册了一个消费者，或者说订阅了一个队列。一个队列可以注册多个消费者，也可以注册一个独享的消费者（当独享消费者存在时，其他消费者即被排除在外）。

每个消费者（订阅者）都有一个叫做消费者标签的标识符，它可以被用来退订消息。消费者标签实际上是一个字符串。

六、消息确认

消费者应用（Consumer applications） - 用来接受和处理消息的应用 - 在处理消息的时候偶尔会失败或者有时会直接崩溃掉。而且网络原因也有可能引起各种问题。这就给我们出了个难题，AMQP代理在什么时候删除消息才是正确的？AMQP 0-9-1 规范给我们两种建议：

当消息代理（broker）将消息发送给应用后立即删除。（使用AMQP方法：basic.deliver或basic.get-ok）
待应用（application）发送一个确认回执（acknowledgement）后再删除消息。（使用AMQP方法：basic.ack）

前者被称作自动确认模式（automatic acknowledgement model），后者被称作显式确认模式（explicit acknowledgement model）。在显式模式下，由消费者应用来选择什么时候发送确认回执（acknowledgement）。应用可以在收到消息后立即发送，或将未处理的消息存储后发送，或等到消息被处理完毕后再发送确认回执（例如，成功获取一个网页内容并将其存储之后）。

如果一个消费者在尚未发送确认回执的情况下挂掉了，那AMQP代理会将消息重新投递给另一个消费者。如果当时没有可用的消费者了，消息代理会死等下一个注册到此队列的消费者，然后再次尝试投递。

1.拒绝消息

当一个消费者接收到某条消息后，处理过程有可能成功，有可能失败。应用可以向消息代理表明，本条消息由于“拒绝消息（Rejecting Messages）”的原因处理失败了（或者未能在此时完成）。当拒绝某条消息时，应用可以告诉消息代理如何处理这条消息——销毁它或者重新放入队列。当此队列只有一个消费者时，请确认不要由于拒绝消息并且选择了重新放入队列的行为而引起消息在同一个消费者身上无限循环的情况发生。

2.预取消息

在多个消费者共享一个队列的案例中，明确指定在收到下一个确认回执前，每个消费者一次可以接受多少条消息是非常有用的。**这可以在试图批量发布消息的时候起到简单的负载均衡和提高消息吞吐量的作用。**For example, if a producing application sends messages every minute because of the nature of the work it is doing.（？？？例如，如果生产应用每分钟才发送一条消息，这说明处理工作尚在运行。）

注意，RabbitMQ只支持通道级的预取计数，而不是连接级的或者基于大小的预取。

3.消息属性

AMQP模型中的消息（Message）对象是带有属性（Attributes）的。有些属性及其常见，以至于AMQP 0-9-1 明确的定义了它们，并且应用开发者们无需费心思思考这些属性名字所代表的具体含义。例如：

Content type（内容类型）
Content encoding（内容编码）
Routing key（路由键）
Delivery mode (persistent or not) 投递模式（持久化或非持久化）
Message priority（消息优先权）
Message publishing timestamp（消息发布的时间戳）
Expiration period（消息有效期）
Publisher application id（发布应用的ID）

有些属性是被AMQP代理所使用的，但是大多数是开放给接收它们的应用解释器用的。有些属性是可选的也被称作消息头（headers）。他们跟HTTP协议的X-Headers很相似。消息属性需要在消息被发布的时候定义。

4.消息主体（有效载荷）

AMQP的消息除属性外，也含有一个有效载荷 - Payload（消息实际携带的数据），它被AMQP代理当作不透明的字节数组来对待。**消息代理不会检查或者修改有效载荷，消息可以只包含属性而不携带有效载荷。**它通常会使用类似JSON这种序列化的格式数据，为了节省，协议缓冲器和MessagePack将结构化数据序列化，以便以消息的有效载荷的形式发布。AMQP及其同行者们通常使用"content-type" 和 “content-encoding” 这两个字段来与消息沟通进行有效载荷的辨识工作，但这仅仅是基于约定而已。

消息能够以持久化的方式发布，AMQP代理会将此消息存储在磁盘上。如果服务器重启，系统会确认收到的持久化消息未丢失。**简单地将消息发送给一个持久化的交换机或者路由给一个持久化的队列，并不会使得此消息具有持久化性质：它完全取决与消息本身的持久模式（persistence mode）。**将消息以持久化方式发布时，会对性能造成一定的影响（就像数据库操作一样，健壮性的存在必定造成一些性能牺牲）。

七、其他

1.连接

AMQP连接通常是长连接。**AMQP是一个使用TCP提供可靠投递的应用层协议。**AMQP使用认证机制并且提供TLS（SSL）保护。当一个应用不再需要连接到AMQP代理的时候，需要优雅的释放掉AMQP连接，而不是直接将TCP连接关闭。

2.通道

一部のアプリケーションでは、AMQPブローカーとの複数の接続が必要です。いずれにせよ、オープン複数のTCPコネクションは、それがあまりにも多くのシステムリソースを消費することになるため、適切でないと、それはより困難にファイアウォールを設定することができます。マルチ接続処理用のAMQP 0-9-1チャネル（チャネル）を提供する、チャネルは、重量を共有する複数のTCP接続として理解することができます。

チャンネル（チャンネル）各スレッド/プロセスのためのオープン、複数のスレッド/プロセスを含む用途では非常に一般的であり、これらのチャネルは、スレッド/プロセスを共有することができません。

各AMQP方法はチャンネル番号を搬送する必要があるので、他のチャネル上の特定のチャネル及び通信に関する通信が完全にクライアントがチャネルのために準備され、この方法を指定できるように、単離されています。

3. Webホスティング

コンセプト - 単剤で隔離された環境（ユーザ、グループ、スイッチ、キューなど）の複数を達成するために、AMQPは、仮想サーバー（バーチャルホスト仮想ホスト）を提供します。この概念は、AMQPエンティティのために完全に隔離された環境を提供するWebサーバとWebホスティング、非常によく似ています。接続が確立されると、AMQPクライアントは、仮想ホストを指定します。