Bigegg Lab

2010年 6月 12日

Q4M に障害が発生し弊社ではどうも解決できそうにないので Q4M の作者の奥一穂さんに相談させてもらいました。
その際は、デッドロックのバグを踏んでいる可能性があるので Q4M を 0.9.1 以上のものしてみてはどうかと返答を頂きました。
弊社では 64bit 環境であった為、0.9.2 は除外され、0.9.3 は新しすぎるので 0.9.1 を採用することにし、バージョンアップ後に障害もなく安定稼働を続けています。

そんな経緯もありまして、先日弊社に奥一穂さんが来社されることになり Q4M について10ページ程のスライドで Q4M の現状とこれからを紹介して頂いたり、弊社からいくつか質問をさせて頂く機会がありましたので今回は弊社からの質問とその回答をご紹介したいと思います。

queue_end() を呼ぶ頻度とデッドロックについて
ウ：（Q4M 0.9.0 の環境で）障害が起きたサービスと一度も障害が起きていないサービスがあります。障害の起きたサービスでは queue_wait() のループ内で毎回 queue_end() を呼んでいますが、他方では queue_wait() のループの外で queue_end() を呼んでいます。障害の起きたサービスでは頻繁に queue_end() を呼んでいることになりますが、queue_end() を頻繁に呼ぶことがデッドロックを誘発する原因になりうるのでしょうか？
奥（敬称略）：まずデッドロックが発生するのは確率的な問題です。
queue_end() を頻繁に呼ぶことがデッドロックの発生率を高める主な要因にはならないと思います。

キューのリトライについて
ウ：キューのリトライの常套手段としてはどのようなものがありますか？
奥：例えば、優先度が高・中・低のテーブルを用意して高で失敗したキューをリトライ用として中のテーブルに入れます。
高が空になった時点でリトライ用の中に入っているキューを処理させる等でしょうか。

ウ：リトライを時間で制御したい場合はどのようにすればよいですか？例えば、キューの処理に失敗したらX秒後に処理するとか。
奥：リトライ用のキューに入れた時間とそのキューを取り出した時点での時刻を比較する。リトライ用のキューを取り出した時点でX秒経っていなかったら任意の時間 sleep する。
というのはどうでしょうか。

Conditional Subscription について
ウ：Conditional Subscription というのがありm
奥：あっ、Conditional Subscription 使ってますか？
ウ：使ってますね。使わないですか？
奥：私自身はあまり使っていないですね。
単純に queue_wait(‘table’) するなら先頭からレコードを取り出せばよいですが、Conditional Subscription を使用すると条件に合致するレコードを走査する必要があるので溜まっているレコードが多ければそれだけコストがかかります。

アプリケーションとのアトミックな処理について
ウ：アプリケーションである処理の成功時に Q4M へ INSERT する、というロジックがあったとして、そのある処理は成功したけど Q4M への INSERT には失敗したという状況がありますが、このような場合はどうすればよいでしょうか？
奥：そうですね、Q4M ではなくて InnoDB でなんちゃってメッセージキューを実装するという解決方法はありますね。現状だとどうしようもないですね。Q4M でもトランザクションを扱えるようにしたいとは思っています。

処理したキューの統計情報について
ウ：例えば、一日に処理したキューの数を知りたいと思ったら SHOW ENGINE QUEUE STATUS; の数字を見ればよいのですか？
奥：そうですね。
ちょっとパースしづらいとは思いますが、その数字を見てください。

ウノウラボ Unoh Labs: 「ちわさん、奥さんが来ましたよ」

奥一穂さんとは何度かお会いしていますが、どんな質問を投げても必ず返せる凄い方でした。

1年前 | 固定リンク | 2010年 6月 12日 |