Contenu connexe
Similaire à Principles of Transaction Processing Second Edition 4章 5~9節 (20)
Plus de Yuichiro Saito (15)
Principles of Transaction Processing Second Edition 4章 5~9節
- 3. 4.5 キューマネージャ
キューストアのストレージを抽象化したもの。
キューの属性(所有者権, 最⼤大容量, キュー名, ユーザ
権限)の作成・破棄・変更に対応する。
まあ、⾃自分でキューマネージャを作らなくてもいい
よ、という物と理解してください。
おまけ
キューは⽇日本語で「待ち⾏行行列」と訳される事がある。
メールサーバがとてもいい例になるので、時間があれば
事例を織り交ぜて説明します。
3
Yuichiro Saito
- 4. 4.5 キューメッセージの操作
主な操作…”enqueue”(投⼊入)と”dequeue”(取出)。
キューからデータを取り出す事無く、内容を⾛走査す
る操作を⾏行行えなければならない。
キュー内のメッセージへのランダムアクセスを⾏行行え
る必要がある。
例:特定のIDを持つキュー or メッセージの中にある第三
のメッセージを読む・取り出す操作。
Dequeueには、空のキューを扱う2種類のオプショ
ン。
ノンブロッキング: キューが空になるという例外が返る
ブロッキング: キューの読み書きが完了するまで他のス
レッドは読み書きできない。
4
Yuichiro Saito
- 5. 4.5 キューメッセージの操作
おまけ
ノンブロッキングは並列性が極めて⾼高い。スレッドセー
フなのはキューに対し⼀一意に振る追番管理のみでいい。
メールサーバやソーシャルアプリはこちらが主流。
だから、 dequeue が起きた時の追番管理のことを考えて
システムを組まないと、dequeue前後のqueueに不整合
が起こってトラブルの元になる。
ブロッキングはデータの排他処理が単純、かつシングル
スレッドで出来るので⼿手軽。
See also
http://www.ibm.com/developerworks/jp/java/
library/j-jtp04186/
http://itpro.nikkeibp.co.jp/article/COLUMN/
20070831/280869/
5
Yuichiro Saito
- 6. 4.5 汎⽤用的なメッセージング
信頼性の⾼高いqueued messageとは何か？
Enqueue, Dequeue 操作は任意のメッセージの送受
信に使⽤用できる。
対向だけでなく、⼀一致した要求・応答のペアとして
⽤用いる事が出来るアプリケーションで定義された
メッセージパターンである。
揮発性の(即ち障害が起こるとパーになる)キューは、
このシナリオを適⽤用すると、4.1節で説明した次の
観点に対応できる。
負荷分散・優先順位のスケジューリング・利⽤用負荷の
サーバと通信する
6
Yuichiro Saito
- 7. 4.5 タイムアウト
キューに溜まったメッセージが⻑⾧長らく処理されずに
残る時は注意が必要。
補⾜足: 記憶域の容量を逼迫したり、処理能⼒力力低下の原因に
なるから、でしょう。実際、そうです。
これを防ぐためにタイムアウト処理を⼊入れる。
時間内にdequeueされなければ破棄。
時間内に何らかのアクセスがあれば、そのアクセス
の時間からタイムアウトを再勘定。
おまけ
よい例は、これまたメールサーバ、特にPOP3です。
7
Yuichiro Saito
- 8. 4.5 汚染されたメッセージの処理
Dequeueを中⽌止させるようなキューがあったとする。
Dequeueできなかったメッセージはキューに残る
しかしエラーが出続けると永遠に残る…
これを防ぐためにユーザが定義可能な再試⾏行行回数を設定
する。
エラー時の処理は、「エラーキュー」に移動してその後
に⼿手動処理。または、実装に応じてアプリケーション・
キューマネージャ・ディスパッチャが動きの定義を⾏行行え
る。
おまけ
メールサーバだと、何度やってもメールを送れなかったサーバ
があった場合、ユーザにエラーメールを返す。
8
Yuichiro Saito
- 11. 4.6 発⾏行行と購読(を通じた同報送信) 1
キュー通信を⽤用い、各メッセージは単⼀一の受信者(メッ
セージをデキューしたプロセスのこと)がいる。
対照的に、複数の受信者にメッセージを送信する必要が
ある⼀一部のアプリケーションがある。
例えば、株式のシステム。⼤大きな株価変動のアラートを同報送
信する。
同報送信すれば、送信者個別に送信するより便利である。
ブロードキャストのために、発⾏行行と購読(publish-
subscribe)を⽤用いる事が出来る。
発⾏行行時のタグはメッセージの種別を表す。
購読者は、購読したいメッセージの種別を仲介者に登録。
発⾏行行者(キュー登録者)からメッセージを受け取り次第、仲介者
は該当種別を購読した者にメッセージを同報送信。
11
Yuichiro Saito
- 12. 4.6 発⾏行行と購読 2
本パラダイムは、3つの⽅方法でキューイングされる
ような形である。
第⼀一に、送信者・受信者は直接通信しないが、仲介
者と通信する。仲介者がキューマネージャというこ
と。
第⼆二に、メッセージはトランザクションコンテキス
ト内で送受信可能。そのため、中⽌止した場合は送受
信操作は取り消される。
第三に、購読者はプッシュ・プルモデルのいずれか
を使⽤用可能。
プルだと、メッセージをポーリング可能。
プッシュだと、ディスパッチャが受信を管理する。
12
Yuichiro Saito
- 13. 4.6 発⾏行行と購読 3
キューイングと発⾏行行と購読のシステム間での類似点。
多くの場合、共通のキューの管理を⾏行行う実装を⾏行行ってい
る。JMSの開発以来、⼀一般的。
ほかに、CORBAベースの通知サービス、WS-Eventingま
たはWS-Notification。
より⾼高度なバージョンでは、名前空間をグループ化
する事が出来る。
メッセージ内容は、(ここではそう⾔言われていない
が)key-valueのvalue部分で把握できる。
購読者情報を永続的・揮発的にするかを選択できる。
購読者が受信できる状態に無いとき、再送できる。
ただし、揮発的である場合は再送信は⾏行行われない。
13
Yuichiro Saito
- 15. 4.7 その他のメッセージ指向ミドルウェア
多くのTPシステムは、関連する機能を提供する他の
TPシステムと組み合わされる。2.4節でその例を⾒見見
た。そのためにはシステムの統合が必要。
しかし、統合には3つの差異を調整しなければなら
ない。
通信プロトコル
アプリケーションの機能
メッセージ形式
2つのアーキテクチャがそれを両⽴立立させられる。
ブローカーベース
アーキテクチャ
…送り出す時に変換
バスベース
アーキテクチャ
…受け取る時に変換
15
Yuichiro Saito
- 16. 4.7 ブローカーベース
アーキテクチャ
メッセージサーバが異種アプリ(Fig 4.10)間のブ
リッジを提供。翻訳してくれるような感じ。
3つの差異に対して3つの機能を提供する。
必要な通信プロトコルすべてを採⽤用。通史相⼿手毎に通じ
るプロトコルに変換してくれる。
各々が提供する機能の和集合を提供。他の技術に依存し
ない均⼀一なインタフェースを使⽤用し機能を呼び出せる。
メッセージの変換を⾏行行う。計算(⽇日付等)・テーブル(国
コード等)・為替等の外部ソースからのルックアップを⽤用
いてもよい。ここのパラメータではなく構造化⽂文章(XML
等)もサポート。
ルーティング、ロギング、監査、パフォーマンスモ
ニタ、運管等の機能も提供。
16
Yuichiro Saito
- 17. 4.7 バスベース
アーキテクチャ
全TPアプリケーションは同⼀一のプロトコルで呼び出
される。WCFやArtixなど。
Fig 4.11に⽰示すように、共通のプロトコルからシス
テム固有のものに変換する必要がある。
全TPを同⼀一のプロトコルを使って呼び出せる。例え
ば、WSDLを使⽤用して定義され、UDDIを使⽤用して呼
び出す。
おまけ: ただ、最近のWeb系はJSONでやりとりして内部
で変換というのが多いです。
ブローカーがいないためメッセージの変換責任をク
ライアントが負わなければならない。これは翻訳の
共通ライブラリを使⽤用して⾏行行う。
17
Yuichiro Saito
- 18. 4.7 各々の⽐比較
(先にも述べましたが)クライアント側で変換するの
がブローカーベース、サーバ側で変換するのがバス
ベース。
しかしながら、バスベースのアーキテクチャでこの
サブシステムを提供しようとするのは、冴えない
(muddyな)やり⽅方である。
どちらの視点で⾒見見たか、が問題。説明します。
どちらにしても、ディレクトリサービスによってイ
ンタフェース定義を公開する必要がある。
パラメータ変換の点の違いは、機能を実装する場所
の選択の問題である。
18
Yuichiro Saito
- 20. 4.8 製品紹介
これまで解説してきたキューの機能について、各⾃自
のミドルウェアがどのように実装しているのかを解
説している。
IBM Websphere MQ
プラットフォーム間での透過的なメッセージ交換が可能
(Fig 4.12)
Oracle Streams AQ
メッセージの送受信者の不正介⼊入を防⽌止できる。
20
Yuichiro Saito
- 21. 4.8 特徴をまとめると…
メッセージを受信者の明⽰示的なセットでエンキュー
可能。
キュー処理のバッチ処理が可能。
キューを取り出す時に削除せずに、SELECTクエ裏
として実⾏行行可能。即ち、デキューされるメッセージ
のスナップショットを取得している。
メッセージを原始性を保ちながら複雑なグループに
分割してエンキューできる。
メッセージの到着を待って、複数のキューを待ち受
ける(listen)事が出来る。
メッセージの内容を取得する事無く、デキューでき
る。メッセージの⼀一括削除時に便利。
21
Yuichiro Saito
- 22. 4.9 まとめ
pp.118,119
22
Yuichiro Saito
- 23. 4.9 キューの利点
サーバがダウンしていても、リクエストを送る事が
出来る。
サーバは、クライアントがダウンしていても、リク
エストを返す事が出来る。
通信障害が起きても、応答が失われたり、不確実な
結果になる事は無い。
負荷分散が容易。
リクエストと関係がある他のリクエストに対し、優
先順位をつける事が出来る。
23
Yuichiro Saito
- 24. 4.9 基本操作
メッセージに対する「エンキュー」「デキュー」
「キューの⾛走査」「キー指定によるアクセス」
キューの作成と破棄。
キュー属性変更。
キューの開始と停⽌止。
24
Yuichiro Saito
