アリの側で、あなたが知っているメッセージミドルウェアのアプリケーションシナリオは何ですか？

1はじめに

再び金、銀、銀になると、誰もが心の落ち着きに耐えられないので、前回のインタビューで出会った知識ポイント（MQの応用シナリオ）を紹介します。欠点は、大物を歓迎しますポイントツーポイント。

メッセージミドルウェアアプリケーションの背景

システムパフォーマンスを向上させるための最初の考慮事項はデータベースの最適化ですが、歴史的な理由から、データベースの水平方向の拡張は非常に複雑なプロジェクトであるため、通常、データベースの前でトラフィックをブロックしようとします。無限のスケールアウトサーバーであろうと、データベースに到達するトラフィックの垂直ブロッキングであろうと、これがアイデアです。データベースへのトラフィックを直接ブロックするために、キャッシュコンポーネントとメッセージコンポーネントが2つの主要なキラーです。

2.MQの概要

MQ：メッセージキュー（メッセージキュー）は、メッセージを保存するコンテナーを指します。

現在、一般的に使用されているMQコンポーネントは、activeMQ、rabbitMQ、rocketMQ、およびkafkaです。異なるMQには独自の特性と利点がありますが、どのMQであっても、MQ自体にいくつかの機能があります。

一般的なメッセージキューの比較

特性	ActiveMQ	RabbitMQ	RocketMQ	カフカ
生産者/消費者モデル	サポート	サポート	サポート	サポート
パブリッシュ/サブスクライブモデル	サポート	サポート	サポート	サポート
要求応答モード	サポート	サポート	サポートしません	サポートしません
APIの完全性	高い	高い	高い	高い
多言語サポート	サポート	サポート	java	サポート
単一マシンのスループット	10,000クラス	10,000クラス	10,000クラス	10万
メッセージの遅延	それなし	マイクロ秒	ミリ秒	ミリ秒
可用性	高（マスタースレーブ）	高（マスタースレーブ）	非常に高い（分散）	非常に高い（分散）
メッセージが失われました	低い	低い	理論的には失われていません	理論的には失われていません
ドキュメントの完全性	高い	高い	高く教える	高い
クイックスタートを提供します	持ってる	持ってる	持ってる	持ってる
コミュニティ活動	高い	高い	真ん中	高い
ビジネス支援	それなし	それなし	ビジネスクラウド	ビジネスクラウド

3.MQの機能

先入先出

先入れ先出しは、キューの最も明白な機能です。メッセージキューの順序は、基本的にキューに入るときに決定され、通常は手動による介入は必要ありません。そして、最も重要なことは、データは使用中の1つのデータにすぎないということです。これが、MQが多くのシナリオで使用される理由です。

パブリッシュサブスクライブ

パブリッシュとサブスクライブは非常に効率的な処理方法であり、ブロッキングがない場合は、基本的に同期操作と見なすことができます。この処理方法はサーバーの使用率を効果的に向上させることができ、そのようなアプリケーションシナリオは非常に広範囲です。

持久化

永続性により、MQの使用が一部のシナリオの補助ツールであるだけでなく、MQがデータベースのようなコアデータを格納してMQの信頼性を確保できるようになります。

配布

大量のトラフィックとビッグデータの現在の使用シナリオでは、単一のアプリケーションのみをサポートするサーバーソフトウェアは基本的に使用できず、分散展開をサポートする場合にのみ広く使用できます。さらに、MQは高性能ミドルウェアとして位置付けられています。

4.アプリケーションシナリオ

メッセージキューミドルウェアは、分散システムの重要なコンポーネントです。主に、アプリケーションの分離、非同期メッセージ、トラフィックカット、大量のログデータの同期、分散トランザクションなどの問題を解決して、高性能、高可用性、スケーラビリティ、および結果整合性を実現します。一貫性。アーキテクチャ。

4.1アプリケーションのデカップリング

シナリオの説明：一般的なショッピングシナリオでは、ユーザーが注文した後、注文システムは通常、以前はインターフェース呼び出しを通じて通知されていた在庫システムに通知する必要があります。

インターフェースを介して呼び出すことのデメリット：注文システムは在庫システムと高度に結合されており、雪崩事故が発生しやすいです。在庫システムにアクセスできない場合、注文は在庫を減らすことができず、注文が失敗します。ボリュームが一定レベルに達すると、注文システムにつながります。クラスターアクセス時間が長くなります。

アプリケーションメッセージキューを導入した後のスキーム：

注文システム：ユーザーが注文すると、注文システムはローカル永続性処理を完了し、メッセージをメッセージキューに書き込みます。書き込みが成功すると、ユーザーの注文成功が返されます。
在庫システム：MQで注文情報をサブスクライブして注文情報を取得すると、在庫システムは注文情報に従って在庫を増減します。
プログラムの主な手順：

注文時に在庫システムが正常に使用できない場合でも、注文後、注文システムはメッセージキューに書き込み、他の後続の操作を気にしないため、通常の注文には影響しません。最終的な一貫性が達成されます。注文システムと在庫システムのアプリケーションの分離を実現します。

4.2非同期メッセージ

シナリオの説明：一般ユーザーが登録した後、登録メールとSMSをユーザーに送信する必要があります。前の手順は、シリアルモード、パラレルモードに分けることができます。

1. シリアルモード：ユーザー登録情報をデータベースに書き込みます。書き込みが成功したら、最初に登録メールを送信してから、登録SMSを送信します。上記の3つのタスクがすべて完了した後でのみ、成功情報がクライアントに返されます。

2. パラレルモード：ユーザー登録情報をデータベースに書き込み、書き込みが成功したら登録メールと登録SMSを送信します。上記の3つのタスクが完了すると、成功情報がクライアントに返されます。シリアル方式と比較して、パラレル方式は処理時間を短縮できます。

問題分析：

ネットワークなどの他のオーバーヘッドを考慮せずに、3つのビジネスノードのそれぞれが50ミリ秒を使用すると仮定すると、シリアル時間は150ミリ秒であり、パラレル時間は100ミリ秒である可能性があります。
単位時間あたりにCPUが処理する要求の数は固定されているため、CPUスループットは1秒あたり100回であると想定されます。その場合、CPUがシリアルモードで1秒間に処理できる要求の数は7倍（1000/150）です。並行して処理されるリクエストの数は10倍（1000/100）です。
上記の場合のように、従来のシステムのパフォーマンス（同時実行性、スループット、応答時間）にはボトルネックがあります。

メッセージキューを介して登録メールと登録SMSを送信する手順を切り離します。

上記のアーキテクチャからわかるように、ユーザーの応答時間は、登録情報がデータベースに書き込まれる時間（50ミリ秒）に相当します。電子メールを登録し、短いメッセージを送信してメッセージキューに書き込んだ後、直接返されるため、メッセージキューへの書き込み速度は非常に速く、基本的に無視できます。したがって、ユーザーの応答時間は50ミリ秒になる場合があります。そのため、アーキテクチャの変更後、システムのスループットは1秒あたり20QPSに増加しました。シリアルの3倍、パラレルの2倍優れています。

4.3トラフィックカット

トラフィックカットはメッセージキューでも広く使用されており、一般的にスパイクまたはグループグラブアクティビティで広く使用されています。

シナリオの説明：Seckillアクティビティは通常、過剰なトラフィックによるトラフィックの急増につながり、アプリケーションまたはデータベースがハングします。この問題を解決するには、通常、アプリケーションのフロントエンドでメッセージキューに参加する必要があります。

アーキテクチャは次のとおりです。

メッセージキューに参加する利点：

1. 活動をコントロールできる人数
2. 短時間で高流量の適用を軽減することができます

サーバーがユーザーの要求を受信すると、最初にメッセージキューに書き込まれます。メッセージキューの長さが最大数を超えると、ユーザーリクエストが直接破棄されるか、エラーページがジャンプします。
seckillサービスは、メッセージキュー内の要求情報に従って後続の処理を実行します。

4.4大規模なログデータの同期

シナリオの説明：マイクロサービスシステムでは、プロジェクトはクラスターにデプロイされることが多いため、各インスタンスのログをクエリするには統合ログプラットフォームが必要ですが、クラスター内のログ情報は大量のデータであることが多く、単一のログ収集ツールでは対応できません。したがって、大量のログ送信の問題を解決するには、Kafkaのアプリケーションなどのログ処理でメッセージキューを使用する必要があります。

アーキテクチャは次のように簡略化されています。

アーキテクチャの説明：

1. ログ収集クライアントはログデータ収集を担当し、Kafkaキューに定期的に書き込みます。
2. ログデータの受信、保存、転送を担当するKafkaメッセージキュー
3. ログ処理アプリケーション：kafkaキューのログデータをサブスクライブして消費します

4.5分散物

分散トランザクションは、強一貫性、弱一貫性、および結果整合性に分けられます

1. 強一貫性：

   更新操作が完了すると、後続の複数のプロセスまたはスレッドによるアクセスは、最新の更新された値を返します。これは最もユーザーフレンドリーです。つまり、ユーザーが前回書いたものは、次回も読み取られることが保証されています。CAP理論によると、この実装では可用性を犠牲にする必要があります。

2. 弱一貫性：

   システムは、後続のプロセスまたはスレッドアクセスが最新の更新された値を返すことを保証しません。データが正常に書き込まれた後、システムは新しく書き込まれた値をすぐに読み取ることを約束せず、最新の値を読み取ることも約束しません。

3. 結果整合性：

   弱一貫性の特定の形式。システムは、システムが最終的に、後続の更新なしで最後の更新操作の値を返すことを保証します。障害が発生しないことを前提として、不整合ウィンドウの時間は、主に通信遅延、システム負荷、およびレプリカの数の影響を受けます。DNSは、典型的な結果整合性システムです。

分散システムでは、一貫性、可用性、およびパーティション許容度の「CAP法則」を同時に満たすことはほとんど不可能です。インターネット分野の大多数のシナリオでは、システムの高可用性と引き換えに強整合性を犠牲にする必要があります。システムは、最終時間がユーザーの許容範囲内にある限り、「結果整合性」を確保するだけでよいことがよくあります。場合によっては、必要な効果を達成するために、短期間のデータ整合性のみを使用する必要があります。

シナリオの説明：たとえば、注文と在庫の2つのデータがあり、注文を追加するプロセスと在庫を削除するプロセスが簡略化されています。また、注文と在庫は独立したサービスであるため、データの一貫性を確保する方法。

リモート呼び出しで最も苛立たしいのは、成功、失敗、タイムアウトの3種類の結果があることです。タイムアウトした場合、成功または失敗する可能性があります。一般的な解決策は、ほとんどの場合、mqを使用して結果整合性を実現することです。

結果整合性を実現するには：

これらの質問は、上記のアーキテクチャを通じて頭に浮かぶかもしれません。

トランザクションは最初にローカルで実行され、実行が成功するとメッセージが送信され、コンシューマーはメッセージを取得して独自のトランザクションを実行します。
たとえば、aとbは2つのサービスであり、サービスaはサービスbを非同期に呼び出します。サービスbが失敗、成功、またはタイムアウトした場合、mqを使用して結果整合性を持たせるにはどうすればよいですか。

ローカルトランザクションの概念を参照すると、このシナリオは3つの状況に分けることができます。

1. 最初のケース：aとbの両方が正常に実行されると仮定すると、ビジネス全体が正常に終了します。
2. 2番目のケース：bがタイムアウトしたとすると、MQはメッセージをbに再送信する必要があります（bサービスはべき等である必要があります）。再送信が失敗した場合、サービスを中断するか、再送信を続行するかは、状況によって異なります。または人間の介入さえ。
3. 3番目のケース：aとbのいずれかが失敗したとすると、失敗したサービスはMQを使用して他のサービスにメッセージを送信し、他のサービスはメッセージを受信し、ローカルトランザクションログを照会し、ローカルが失敗した場合は受信したメッセージを削除します（メッセージの消費が成功した場合）、ローカルが成功した場合は、報酬のために報酬インターフェースを呼び出す必要があります（各サービスはビジネス報酬インターフェースを提供する必要があります）。

特別な注意が必要です：

MQには落とし穴があります。これは通常、最初の操作のみが失敗するシナリオにのみ適用できます。つまり、最初の操作が成功した後、後続の操作にビジネス上の障害がないことを確認する必要があります。後者が失敗した場合にロールバックし、許可する場合のみシステムに異常が発生した場合、ビジネス障害は許可されません。通常、ビジネス障害後に成功する可能性は低くなります。障害の原因がネットワークまたはダウンタイムである場合は、次の方法で解決できます。再試行します。ビジネスが異常な場合は、サービスaにメッセージを送信し、補償を依頼することしかできません。補償は通常、サードパーティによって実行され、各サービスは補償インターフェイスを提供する必要があります。設計パラダイムでは、通常、ダウンストリームサービスの消費の失敗は許可されません。

5.まとめ

MQは分散システム開発のシナリオでますます使用されており、処理のビジネス能力はますます強力になっているため、MQの使用シナリオを習得する必要があります。MQを習得することで、ほとんどのビジネスシナリオを解決できます。また、面接にポイントを追加して、コアコンピタンスを向上させることもできます。

最後に、出勤するのは簡単ではありません。すべての兄弟が自分の好きな仕事を見つけて、虎の年がいっぱいになることを願っています！

また、兄弟たちが波をフォロー、収集、コメント、サポートしてくれることを願っています。ありがとうございました！