MQもちろん、いくつかのビジネスシナリオは、私たちは、消費者の順序を保証する必要がある、とプロデューサー場合、キュー、複数の消費者の場合は、の順序を保証することができません
例えば：
1、ビジネス上の3つのメッセージ、データの増加、すなわち、変更、削除、および消費者が順序を保証するものではありませんならば、その結果は、削除、変更、追加、最終的なデータを削除する必要がありますすることであってもよいです
結果は増加となりました
順序が変更された場合2、または電子ビジネスプラットフォーム、最初の支払いを受けるし、受注を生成して、物流を通知し、（私は電気の供給業者に精通していないよ、これは一例に過ぎず、適切でないかもしれません）
お客様がアップ払っていないが、あなたは、物流の配達に気づきます
したがって、これらのビジネス・シナリオ、順序が重要なニュースの消費があります
ソリューション：
1、キューの消費者に該当するものを、必要が注文メッセージがキュー、近くAUTOACK、prefetchCount = 1、時間消費に送られることを保証するために、
手動処理後にメッセージACK、及びメッセージ受信が、消費者によって処理
ここについて話をする、または複数の消費者は、同期処理、手ACKが十分でない場合、各消費者のための最初の時間はメッセージを（受信する場合、メッセージの数>
消費者の番号）、ACKメッセージを介して送信さ後、彼らはまだ消費の順序を保証することはできませんになるまで待つことになる残りの
2、上記の解決策が唯一のいくつかの簡単な個人的な理解され、実際の生産環境プログラムは複雑で、次のように神のソリューションです
以下を保護する必要があります。
図1は、送信されたメッセージの順序は、同じキューへの送達を確実にしなければならず、消費者の一方のみ（排他的）
2、及び（大きなメッセージは、好ましくは、スプリット、スプリットまたは複数のメッセージをマージすることができる）を提出することに同意し、そしてメッセージのすべてが同じセッションID
図3は、メッセージ・プロパティ追加：配列表と番号を、メッセージのローカルな順序付けのサイズ属性は、落下のための操作を行います
後続の処理のために消費：4、遅延メッセージ（セッションID、SIZEバンドキー属性）を送信するためにそれ自体に平行
図5に示すように、遅延されたメッセージを受信し、プロセスのセッションIDに応じて、サイズデータベースのデータ抽出
図6に示すように、異常のポーリング補償機構のタイミング
注：メッセージの製造端部が完全に成功した配信、または消費者側羅が落下用ポストコンシューマエンドのニュース項目の欠如によって引き起こされる異常を交差されないよう
説明：
バッチが同じである前に、左にステップと話します
右の手順：
図1は、複数のメッセージを受信した後、最初の論理処理は、直接ストレージ、それぞれ、最初のメッセージの記憶は、遅延メッセージを送信している間（例えば5分、ために実行されないが、
（すべてのメッセージが受信されていることを確認し、統一プロセス）、メッセージ遅延を聞いた後、どのように多くの総セッションIDベースのメッセージやサイズを見つけるし、その後に対処するメッセージの順序を根絶
例えば、）処理するためのスレッドから
PS：受信メッセージが遅延した後にメッセージを受信した後、記憶装置に行い、その後、処理されなければなりません
このプログラムのない深い個人的な理解、あなたは自分自身を理解することができます。。。
高速メッセージングモード
1、迅速なメッセージは、信頼性を保証しない、落下のためではないメッセージを意味します
ログデータ、ビジネスの統計分析に適した2、
3、性能及びスループットの利点が最大化されます
凡例：
メッセージではない落ちるため、プロデューサーBrokerは確認する必要はありません。