受け取った時点で消すと1,006件が失われ、終わってから消すと986件が二重処理になりました。
選べるのはどちらの形で出るかだけです。件数そのものは減りません。
消す時点を選べます。ただし選んだ結果として、必ずどちらかの形で同じくらいの件数が出ます。
RabbitMQでは、消す時点を選べます。公式は確認応答を使っている場合、仲介役はその件についての知らせを受け取ったときにだけ、待ち行列から完全に取り除くと述べています。
受け取った時点で消す形と、終わってから消す形。どちらがどれだけ出るのか実際に落として数えました。
100,000 件を処理する。処理の途中で落ちることがある 受け取った時点で消す場合と、終わってから消す場合を比べる 途中で落ちる割合 受け取った時点で消す（失う件数） 終わってから消す（二重処理の件数） 0.01% 12件 7件 0.10% 100件 95件 1.00% 1,006件 986件 5.00% 5,009件 5,303件
1%で落ちる条件では、失うのが1,006件、二重になるのが986件でした。ほぼ同じ数です。
5%まで上げると5,009件と5,303件です。二重のほうが多いのは、やり直しの最中にも落ちるからです。
件数が減らないので、どちらが受け止めやすいかで決めることになります。
二重処理は、受け側で2回目を捨てる作りを入れれば消せます。失った件は後から取り戻せません。
だから多くの場合は終わってから消す形を選び、受け側を整えます。作り方は冪等性の記事で扱いました。
選んでも件数は減らない。形が変わるだけ。
When message acknowledgements are in use, a broker will only completely remove a message from a queue when it receives a notification for that message原文RabbitMQ 公式ドキュメント「AMQP 0-9-1 Model Explained」 この内容の有効期限2027-02-18
投入先は待ち行列ではなく交換所です。そこから何件に増えるかは、結びの数で決まります。
RabbitMQでは、投入先は交換所です。公式は交換所は、メッセージが送られる先にあたる要素であると述べています。
そこから結びの規則で振り分けられます。本数を変えると何件になるのか実際に突き合わせて数えました。
20,000 件を投入する。宛先の名前は「区分.動き.地域」の3段
結びの数を変えて、配送された件数と、照合にかかった回数を数える
結びの数 配送された件数 1件あたり どこにも行かなかった件数 照合した回数
1本 1,012件 0.1件 18,988件 20,000回
10本 25,099件 1.3件 3,228件 200,000回
100本 285,883件 14.3件 0件 2,000,000回
500本 1,432,782件 71.6件 0件 10,000,000回
500本にすると、2万件の投入が143万件の配送になります。1件あたり71.6件です。
照合も1件ごとに全部の結びと突き合わせます。本数に比例して回数が増えます。
結びが1本だと、20,000件のうち18,988件がどこにも行きませんでした。投入しても消えます。
つまり結びの本数は、少なすぎれば消え、多すぎれば増えるという両側の失敗があります。中間を探すことになります。
宛先を条件で選ぶ形の効き方はEventBridgeの記事でも扱っていて、規則の書き方が量を決めます。
Exchanges are AMQP 0-9-1 entities where messages are sent to.原文RabbitMQ 公式ドキュメント「AMQP 0-9-1 Model Explained」 この内容の有効期限2027-02-18
ためる場所なので、取り出しが追いつかないと待ちが伸びます。伸び方は直線ではありません。
RabbitMQの待ち行列は、取り出されるまでためておく場所です。公式はこの模型の待ち行列は、他の仕組みの待ち行列とよく似ており、アプリケーションによって取り出されるメッセージを保持すると述べています。
ためる場所なので、取り出しが追いつかないと伸びます。どこから急に伸びるのか実際に流して数えました。
窓口 4台。1件あたり平均 10分。仕事 40000件を流す 到着と処理はどちらも指数分布。先に来たものから順に空いた窓口へ入れる 狙った使用率 実測の使用率 平均の待ち 95%点の待ち 待ちが処理時間の何倍か 50% 49.6% 0.8分 6.0分 0.08倍 70% 69.5% 3.5分 17.8分 0.35倍 80% 79.4% 7.6分 32.4分 0.76倍 90% 89.3% 20.3分 75.0分 2.03倍 95% 94.3% 43.0分 148.1分 4.30倍 98% 97.3% 87.0分 270.5分 8.70倍
80%までは、待ちは処理時間より短いままです。90%を超えると2.03倍になります。
98%では8.70倍です。使用率は18ポイント上がっただけですが、待ちは11倍以上になりました。
取り出し口をぎりぎりまで詰めると、少しの増加で待ちが跳ねます。8割あたりが落ち着く目安でした。
たまった分は消えるわけではないので、あとから取り戻せます。ただしその間ずっと遅いという状態が続きます。
3つの計測はいずれも手元で書いた模型で、実際のRabbitMQを動かしたものではありません。落ちる割合は置いた値で、実際の故障率とは関係ありません。結びの本数と当たり方も、生成したパターンに依存します。待ちの計測は到着と処理を指数分布と置いており、実際の山谷がある流れではもっと伸びます。ここで見せているのは、消す時点を選んでも件数は変わらないという点と、使用率を上げると待ちが直線では増えないという点の2つです。
Queues in the AMQP 0-9-1 model are very similar to queues in other message- and task-queueing systems: they store messages that are consumed by applications.原文RabbitMQ 公式ドキュメント「AMQP 0-9-1 Model Explained」 この内容の有効期限2027-02-18
同じ課題を持つ会社にとって、動いている設定は「作る時間」を買えるということです。ServiceDockは自作のワークフローやテンプレートを出品できるマーケットプレイスです。手数料や出品の流れは出品者向けページにまとまっています。
出品の仕組みを見る