いままで、キューについていろいろ書いてきた。また、先日は RubyとdRubyからマルチスレッド対応Queueの使い方 について、記載した。
ネットワーク間、プロセス間通信用のキュー
RubyとdRubyからマルチスレッド対応Queueの使い方 等を用いると、バックグラウンド処理をし続ける処理と表層の処理間で通信が出来る事が分かる。
データ変換処理
たとえ話となるが、以前自宅にある録画データ(MPEG2)を外出先の携帯から見ようと思い、以下のようなシステムを作った。
この図は Hokuriku.rb 第1回のLT資料より引用している。
この図の CGI 変換の間はプロセスが分離している。変換作業は非常に時間がかかるため、 CGIから変換プロセスに委託し、CGIは受理したことをHTMLを応答する。
複数の要求を受理するために、CGIと変換プロセス間はキューで結ぶことにした。
永続化が必要
しかし、この変換処理中に、異常終了したり、マシンリブートが発生する事がある。これを踏まえると
- キューの内容が保存されていないといけない
- 中断された処理中の要求を再度実行しないといけない
これが必須となる。このため、上記のシステムは、
- キューにenqueue した時点でキュー永続化。
- キューからdequeue した時点でキューの永続化
- dequeueしたメッセージを処理中のメッセージとして永続化
した。
これを考えると、メッセージキューは、上記特性が必要かと考える
最近のシステム
Google App Engine / Windows Azure のキューも上記要素が組み込まれているように感じる。
ただ
- キューにenqueueした時点で永続化
- キューからdequeue してもキュー上にのこってる
- 処理が完了したら dequeue され、永続化
のように感じられる
さいごに
プロセス/ネットワークを超えたメッセージキューは、以前記載した「 マルチスレッド対応のキュー 」の定義
-
FIFO
先入れ先だし(最初に入れたアイテムが最初に取出される - キューにアイテムを入れる操作を enqueue
- キューからアイテムを取り出す操作を dequeue
だけではなく、
- キューの内容の永続化
- 処理完了時まで、メッセージの保持
が必要になるかと考える。



コメントする