1 JMS
Java Message Service、Java Message Serviceは、Javaプラットフォームのメッセージ指向ミドルウェア（MOM）APIであり、非同期通信のために2つのアプリケーションまたは分散システム間でメッセージを送信するために使用されます。
2 MQアプリケーションシナリオ
1）デカップリング
システムAは他の乱雑なシステムと真剣に結合されており、システムAは主要なデータを生成し、多くのシステムはこのデータを送信するためにシステムAを必要とします。システムが失敗した場合、システムは常にBCDE 4システムを検討する必要がありますか？メッセージを再送信または保存しますか？私の髪は灰色です！
MQを使用する場合、システムAはデータを生成してMQに送信します。MQでデータを使用するには、どのシステムでデータが必要ですか。新しいシステムがデータを必要とする場合は、MQから直接使用するだけで、システムがこのデータを必要としない場合は、MQメッセージの使用をキャンセルしてください。このように、Aシステムはデータの送信先を考慮する必要がなく、このコードを維持する必要もありません。また、呼び出しが成功したかどうか、失敗のタイムアウトなどを考慮する必要もありません。
2）
別のシナリオを非同期で見てみましょう。システムAがリクエストを受信すると、ライブラリをローカルに書き込む必要があり、3つのBCDシステムにライブラリを書き込む必要もあります。ライブラリをローカルに書き込むには3ミリ秒、300ミリ秒、450ミリ秒、 200ms。最終リクエストの合計遅延は3 + 300 + 450 + 200 = 953ミリ秒で、1秒に近く、ユーザーは何かが遅すぎると感じています。ユーザーがブラウザーを介して要求を開始し、1秒間待機します。これはほとんど受け入れられません。
一般に、インターネットベースの企業では、直接のユーザー操作のために、各要求を200ミリ秒以内に完了する必要があります。これは、ユーザーにほとんど気付かれません。
MQを使用する場合、システムは3つのメッセージをMQキューに継続的に送信します。5ミリ秒かかる場合、要求を受信してからユーザーに応答を返すまでの合計時間は3 + 5 = 8ミリ秒です。ユーザーにとっては、ボタンをクリックするだけで、8ms後に直接戻ります。ウェブサイトはとてもよくできていて、とても速いです！
3）ピークシェービング
毎日0:00から12:00まで、システムAは穏やかで、1秒あたりの同時リクエスト数は50です。その結果、12：00から13:00に毎回、1秒あたりの同時リクエスト数が突然5k +に増加します。しかし、システムはMySQLに直接基づいており、多数のリクエストがMySQLにフラッディングし、MySQLで毎秒約5kのSQLが実行されます。
一般に、MySQLは1秒あたり2kのリクエストを処理するのにほぼ十分です。1秒あたりのリクエストが5kに達すると、MySQLが直接強制終了され、システムがクラッシュしてユーザーがシステムを使用できなくなります。
ただし、ピーク期間が終了すると、午後は低いピーク期間になります。1週間のユーザーが同時にWebサイトを操作している可能性があります。1秒あたりのリクエスト数は50リクエストにすぎない場合があり、システム全体ではほとんど何もありません。圧力。
MQを使用すると、1秒あたり5kのリクエストがMQに書き込まれ、MySQLは1秒あたり最大2kのリクエストを処理するため、システムAは1秒あたり最大2kのリクエストを処理できます。システムAはMQからゆっくりと要求をプルし、1秒あたり2kの要求をプルします。1秒あたりに処理できる要求の最大数を超えないでください。これは問題ありません。このようにして、ピーク期間中であっても、システムAはハングアップします。MQ 5kリクエストは1秒ごとに受信されますが、発信されるのは2kリクエストのみです。その結果、正午のピーク期間（1時間）中に、数十万または数百万ものリクエストがMQにバックログされる可能性があります。この短いピーク期間のバックログは問題ありません。ピーク期間の後、毎秒50のリクエストがMQに入力されますが、Aシステムは引き続き毎秒2kのリクエストを処理します。したがって、ピーク期間が終了している限り、Aシステムはメッセージのバックログを迅速に解決します。
3 MQによって引き起こされる問題
1）システムの複雑さが増す
2）一貫性要件が減る
4一般的に使用されるメッセージ用のミドルウェア
1 ActiveMQ
ActiveMQは、Apacheによって生成された強力なオープンソースメッセージバスです。これは、JMS仕様
を完全にサポートするメッセージミドルウェアです。豊富なAPIとさまざまなクラスター構築モードを提供し、業界のベテランになります。
メッセージミドルウェアは、
MQ を測定するために中小企業で広く使用されています。 ：サービスのパフォーマンス、データストレージ、クラスターアーキテクチャ
長所：豊富なAPI
短所：高い並行性やビッグデータなどのアプリケーションシナリオに対応できないパフォーマンス。ActiveMQは無力のようです。
2カフカ
Kafkaは、LinkedInのオープンソースの分散パブリッシュ/サブスクライブメッセージングシステムであり、現在Apacheのトッププロジェクトに属しています。プルモードに基づくメッセージ消費の処理、高いスループットの追求が特徴であり、ログの収集と送信を目的としています。バージョン0.8はレプリケーションのサポートを開始しますが、トランザクションはサポートしません。メッセージの複製、損失、エラーなどに対する厳密な要件はなく、大量のデータを生成するインターネットサービスのデータ収集ビジネスに適しています。
利点：高スループット（数百万/秒）
短所：トランザクションをサポートしていない、データの信頼性がそれほど高くない
3 RocketMQ
RocketMQはAliのオープンソースメッセージングミドルウェアであり、トップレベルのApacheプロジェクトとして導入されており、pure Javaで開発され、高スループット、高可用性を備え、大規模な分散システムアプリケーションに適しています。RocketMQのアイデアは、メッセージの信頼性の高い送信とトランザクションのプロパティを最適化するKafkaに端を発しています。現在、トランザクション、リチャージ、ストリームコンピューティング、メッセージプッシュ、ログストリーミング、binglog配布などのシナリオで広く使用されています。
利点：高性能、トランザクションのサポート、分散型ビッグデータのサポート
短所：メンテナンスには専門家が必要、商用バージョンは
4 RabbitMQを請求
RabbitMQは、Erlang言語を使用して開発され、AMQPプロトコルに基づいて実装されたオープンソースのメッセージキューイングシステムです。AMQPの主な特徴は、メッセージ指向、キュー、ルーティング（ポイントツーポイントおよびパブリッシュ/サブスクライブを含む）、信頼性、およびセキュリティです。AMQPプロトコルは、データの一貫性、安定性、および信頼性が非常に高く、パフォーマンスとスループットの要件が2番目であるエンタープライズシステムでより多く使用されます。
利点：中程度のパフォーマンス、高い安定性と信頼性