序文
Githubの：https://github.com/yihonglei/message-middle
RabbitMQの基礎：https://blog.csdn.net/yhl_jxy/category_6979741.html
RocketMQの基礎：https://blog.csdn.net/yhl_jxy/category_6979742.html
カフカの基礎：https://blog.csdn.net/yhl_jxy/category_6979739.html
なぜ、メッセージキューを使用できますか？
3つのコアシナリオ：デカップリング、非同期、クリッピング。
1、デカップリング
インタフェースの呼び出し：
A、B、C、Dの4つのシステムが存在する場合、システムは、重要なデータであり、その異なるデータを、下流B、それぞれC、Dを介してインタフェースを呼び出し、
システムは、過敏性気分曲を持つ人々そのインターフェイスを担当し、他のシステムが存在する場合、この時間はまた、我々はデータを持っている、男、彼に言われました、
私たちは、あなたがハード次の曲を働いてきた、書かれたインタフェースを提供し、誰もが、彼はチューン、システムAの叫びの担当者が、彼は各呼び出しのタイムアウトの異常な状況に対処する必要がありますせありません
ブラザー、あなたは良いを確保します！
メッセージは仕方を切り離さ：
システムの必要性が唯一のニュースや消費にMQ、B、C、Dは、サブスクライブ対応するデータを送信することで、ビジネスや取引を行う、我々はシステムA転送インタフェースを担当して誰かをしたい場合は、
コーヒーをすすりながら、ライン上の喜び、サブスクリプションXXXTopic、自家消費と彼に言います。
2、非同期
インタフェースの呼び出し：
存在する場合、A、B、C、Dシステム、ユーザAトリガがシステムAを調整し、システムを調整+ 30ミリ秒+ 500msの200ミリ秒= 790msの時間B、C、D、ユーザのニーズなど60msの+、
高速1S後の結果を確認するために、データが処理されたデータBを参照するに、システムユーザAによって処理され得る、記録されたデータのC、Dは、内部私達のシステムのいくつかのタイプであってもよいです
ユーザーがリアルタイムデータを見る必要がないか、または、これらのデータは非同期に処理することができ、利用者の忍耐が制限され、あまりにも長い間ユーザーを待たせてはいけない、あまりにも難しく、ユーザーの心を獲得するために、
しかし、確かに失うことは容易です。
非同期メッセージ：
コアデータは、結果が直ちにユーザに戻され、その後、対応するメッセージを送信し、処理された、B、Cは、Dは、プロセスを消費し、同期処理動作に
非同期処理は、応答速度を改善することを目指しています。
3、クリッピング
トラフィックは、直接サービスをヒット：
通常の流れが比較的小さい場合に、システムが、ピークまたはトラフィックが非常に大きい場合、この時間は、データベースがそんなに圧力を買う余裕ができない活動を行います。
一般的にキャッシュまたはMQの方法で解決することができます。
まずトラフィックMQ、処理システムの消費量：
トラフィックは、自分の状況に応じてMQ、MQ責任バッファー、MQデータベースからバッチ処理消費のシステムにヒット。
第2のメッセージキューの長所と短所？
カフカ、ActiveMQの、RabbitMQの、RocketMQは長所と短所を比較しますか？
| プロパティ | 可用性 | メッセージの信頼性 | 即時性 | スタンドアローンのスループット | サポート機能 | アプリケーション |
| RocketMQ | 達成するためのアーキテクチャを分散、ネッティーベースの通信を実現する、非常に高いです | パラメータ最適化設定の後、それが0の損失を行うことができます | ミリ秒レベル | 100,000高スループットをサポート | MQ関数は、より完璧な、または分散、スケーラビリティ | と多くのビジネス |
| RabbitMQの | 主な高可用性アーキテクチャから高に基づいて、 | 基本的に失う、あなたがメッセージの永続性機能を開くことができません | RabbitMQのの大きな特徴であるマイクロ秒、最小の遅延 | 一万、RocketMQ、カフカ大きさの順序よりも低く | アーランの開発に基づいて、同時性が非常に強い、優れた性能、低遅延であります | と多くのビジネス |
| ActiveMQの | 同RabbitMQの | データ損失の低い確率を持っています | ミリ秒レベル | 同RabbitMQの | 完全なのMQ非常に機能領域 | と多くのビジネス |
| カフカ | 非常に高いデータの分散、複数のコピー、 | RocketMQ付き | ミリ秒の遅延段内 | 100 000、ハイスループット | この関数は、主支持シンプルな機能は比較的簡単であるMQ | 大規模な使用の分野でのリアルタイムコンピューティングや大規模データのログ収集があります |
その支出3つのメッセージの冪等を確保するには？
通常の状況下では、それはMQメッセージの生産を使用することで、消費メッセージ、および確認するMQメッセージキューから送信された送達確認情報の種々の異なる形態、
RabbitMQの例、ACK応答メッセージが送信され、RocketMQ CONSUME_SUCCESSは成功フラグ、カフカの事実、オフセットの概念を返します。
これは、完璧に見えますが、多くの場合、支出の重複があるかもしれない、例えば、その理由は、ネットワークフラッシュ、ACKが失敗した場合にその失敗を返す、とされているため、
情報はもはやメッセージキューに転送され、メッセージキューは、彼らがメッセージを持っていた、とのメッセージが再び他の消費者に利用可能であることを消費者のノウハウになりません。
（ため、メッセージの再試行メカニズム、等の消費者が壊れている場合、消費者のクラスタを有するrocketmqの、メッセージは、他の消費者に再配布されます）。
一般的には、繰り返し消費のための消費者側の処理、消費者の最終用途のMQの冪等は行っていない場合、企業は当惑して、ダーティデータの多くを持っています。
このような電力消費のような従来の処理方法：
図1に示すように、データベース・レベル、一意のインデックスの確立、挿入重複例外なしダーティデータ。
2、SETNXのRedisの、分散ロックフォーム、自然支持冪等。
それがすでに存在する場合は3、一意のID、各消費者のレコードを作成Redisのは、それはもはや消費されません。
実際の冪等あなたのビジネスに対処するために、適切な補償機構を実行する必要がある必要があります。
メッセージは、4つを失っていないことを確認するには？
いくつかの非コアシーンを使用してMQは、それが失われたことができますが、MQハンドルは、あなたがあなたのメッセージが失われないことを確認する必要がある場合、いくつかのデータは、非常に重要です。
メッセージは生産終了に失われる可能性があり、また、MQに送信されることがあり、それらが発行されないことがあり、MQは、消費者側にメッセージが引っ張らないことがあり、内部に失われました。
あなたがRocketMQを使用している場合は、いくつかの処理のメッセージが失われていないと、彼は私たちを助けました。
RocketMQ実質的メッセージフロープロセス
プロデューサー（生産者はニュースを生成する） - 「ブローカー（保存されたメッセージ） - 」cunmser（メッセージを消費します）
どのようにプロデューサーのメッセージが失われないことを保証するために：
図1に示すように、デフォルトでは、同期の伝送を阻止する方法により、SendStatusを確認し、ステータスがOKである、特定のブローカへの配信の成功を示すメッセージ、
タイムアウトまたは失敗、デフォルトの2回の再試行がトリガされます。このメソッドの結果を送信し、ブローカーの成功は記憶することができる、または成功しないかもしれません。
、2は、トランザクションメッセージの配信を取るための方法は、メッセージがブローカーに配信さ100％の成功を保証するものではありませんが、メッセージが送信された場合のAckが失敗します
このメッセージは、CommitLogそれらに格納されますが、ConsumerQueueは表示されません。この異常は、ログにメッセージを表示することができます
厳密に言えば、それは完全に失われていません。
メッセージが送信される場合は3、RocketMQサポートインデックスログは、タイムアウト後に、それはまた、クエリブローカストレージの成功かどうかを確認するために、APIをログに記録することができます。
どのようにブローカーのメッセージが失われないことを保証するために：
1、再起動後に、メッセージが消費されていなくてもダウン、Commitlogの内部をサポートするために、メッセージの永続性が出てロードすることができます。
2、ブローカブラシディスク自体は、ローカルメモリに格納されている特定の受信メッセージを確保することができ、同期、非同期ブラシプレート戦略をサポートします。
3、ブローカクラスタでもマスターディスクがクラッシュした場合、メッセージはまだ失われていないことを道同期レプリケーションと非同期レプリケーションをサポートするための主な戦略、同期レプリケーション性を保証からNをサポートしています。
どのようにcunmserメッセージが失われないことを保証するために：
永続的なオフセット（オフセット分内部のメッセージキューに相当）の消費の成功をマークするか、すでに正常ブローカーに送り返されてきた1は、消費者自身が維持します
添字のメッセージ。
2、消費者の消費が失敗した場合は、それはバックが成功し、その後、彼らのオフセットを更新し、ブローカーにこのメッセージのバックを入れます。
3.ブローカーに送り返されたときに消費者の消費が失敗した場合、ブローカーは、消費者が定期的にこの操作を再試行し、ハングアップ。
ブローカーと消費者が一緒にリンクされている場合、消費者は、再起動後、永続的なタイミングオフセットであるため、図4に示すように、メッセージは、失われていません、
ローカルオフセットプルへ前のメッセージを続けます。
メッセージの順序を5人の消費者を確保するには？
時々、私たちは送信メッセージは、消費者によって発行された順序で、我々はまた、障害がデータの異常につながる場合は、消費者を注文する必要があります。
各MQ一般的なアプローチは、複数のキューを構築することです、消費者のニーズを確実にするために送信するときは、同じキューに送信されたメッセージの順序です
FIFO順キュー消費者におけるエンド・消費者のニーズ、消費者がに対処するためのマルチスレッド、複数のワーカーを使用している場合、我々は、注意を払うに必要
あなたは、各スレッドの処理順序を保証することはできません消費者をマルチスレッド、それは特別な注意が必要です。
継続的に完成更新......
