AMQPの構成要素
- メッセージブローカー:AMQPクライアントが接続するサーバ(サーバはクラスタ構成にできるが仕様書は規定しない)
- 交換(Exchange)とキューで構成
- ユーザ: IDとパスワードでブローカーに認証して接続するもの。
- コネクション: TCP/IPなどを使っての物理的な接続。各コネクションはユーザと結びつけられる。
- チャネル: 論理的なコネクション。
- ステートフル
- 各コネクションでの並列実行する時は、スレッドごとに別のチャネルで操作
- メッセージを送受信するエンティティはチャネル上に宣言
- 一度宣言したエンティティを別のプロパティに変更しようとするとエラー
- プロパティの変更は一度削除してから
- エンティティは名前付き(オプション)
- 名前はエンティティとブローカの中でユニーク
- 利用可能な名前付きエンティティのリストを取得できない
- エンティティ名についての知識は、そのエンティティ上でできる操作も定義している
- アプリケーションはそれを知っているはず
- 名前はUTF-8で1から255文字(バイト?)
- 数字か文字か、アンダースコアーで始まること
交換(Exchange)
- メッセージの送信先を制御するエンティティ
- 名前とプロパティ付き
- プロパティ
- durable: ブローカーを再起動しても永続化されている
- auto-delete: キューがなくなったら破棄される。
- passive: よくわからん。すでにあればそれを使うけど、なければエラーにする?
キュー
- メッセージの受信先エンティティ
- 名前とプロパティ付き
- クライアントがキューを購読すると、
- ブローカーがキューにあるメッセージをクライアントに配信
- クライアントがキューにあるメッセージをポーリング
- キューはFIFOで配信
- プロパティ
- alternate-exchange: メッセージがクライアントに拒否されたり、キューが削除されたときに、メッセージをexchaneに戻す。
- passive: よくわからん。キューが存在していればそれをつかって、なければエラー?
- durable: ブローカーを再起度すいてもキューが永続化されている
- exclusive: 特定のキューに対してクライアントは一つだけ
- auto-delete: クライアントがいなければキューを自動削除
- キューがauto-deleteの時は、exchageの時もauto-delete
- AMQP1.0でキューがexchangeと統合されるらしい?
メッセージ
- exchangeに発行して購読しているクライアントに配信される実体
- ヘッダーとコンテントで構成
- ヘッダープロパティ
- routing-key: exchnageのタイプに応じて使用する
- immediate: クライアントが一つも購読していないキューが一つでもあれば、転送できない
- delivery-mode: メッセージを永続化して確実に配送させる
- priority: 0から9でメッセージ配信の優先度を指定
- expiration: メッセージの配送をあきらめるまでの時間(ミリ秒)
バインディング
- exchangeからキューにメッセージが流れる方法を定義したもの
- exchangeで使われるルーティングアルゴリズムの指定
- でも1.0ではexchangeとキューが一つになるので気を付けてね
- 条件に応じて配信するキューを制御しようとしていた
- でも条件が多くなりすぎて、フローが急激に複雑になりすぎた
- direct: メッセージのルーティングキーとバインディングのキーが同一の場合
- fanout: キーなくても常にマッチ
- topic: メッセージのルーティングキープロパティとバインディングキーがマッチする場合
- words: ワードはドットで区切られた文字列。
- *: 一単語にマッチ
- #: 0からN単語にマッチ。
AMQPの製品
- OpenAMQ
- StormMQ
- RabbitMQ
- Apache Qpid (ApacheプロジェクトはMQ関係の製品を二つも持っているのか・・・)
AMQPの敵
- Storm: テキストベースのpubsubプロトコル
- RestMS:AMQPの接続形態をHTTPベースにした感じ
- XMPP: Extensible Messaging and Presence Protocol。JabberとかのIMで。XMLは・・・
- AMQPとXMPPとの比較はそのうち(とっても似ているらしい)
0 件のコメント:
コメントを投稿