高い同時実行性に関する PHP 面接の質問 15 件 (概要)-PHPチュートリアル-php.cn

高い同時実行性に関する PHP 面接の質問 15 件 (概要)

おすすめ関連記事: 「「高い同時実行性と大規模なトラフィック」アクセスの解決策と解決策についての詳細な説明」

1. Rabbitmq とは

AMQP 高度なメッセージキュープロトコルを使用したメッセージキューテクノロジーであり、最大の特徴は消費に必要がないことです。プロバイダーが存在することを確認し、サービス間の高度な分離を実現します

2。なぜ Rabbitmq

を使用するのか分散システムには、非同期、ピーククリッピング、ロードバランシングなどの一連の高度な機能があり、
には永続化メカニズムがあり、キュー内のプロセスメッセージや情報も保存できます。保存されました。
消費者と生産者の間のデカップリングを実現します。
高同時実行性のシナリオでは、メッセージキューを使用すると、一定量の電流制限に達するまで同期アクセスをシリアルアクセスに変えることができ、これはデータベース操作にとって有益です。
メッセージキューを使用すると、非同期注文の配置の効果を実現できます。キュー中に、論理的な注文がバックグラウンドで配置されます。

#3. Rabbitmq を使用するシナリオ

#サービス間の非同期通信
##タイミングタスク
##リクエストピークカット
##4. メッセージが RabbitMQ に正しく送信されることを確認するにはどうすればよいですか?メッセージ受信者がメッセージを確実に消費するようにするにはどうすればよいでしょうか?

送信者確認モード

チャネルを確認モード (送信者確認モード) に設定すると、公開されるすべてのメッセージが送信者確認モードに設定されます。チャンネルには一意の ID が割り当てられます。

メッセージが宛先キューに配信されるか、メッセージがディスクに書き込まれると (永続メッセージ)、チャネルはプロデューサーに確認を送信します (一意のメッセージ ID が含まれます)。 RabbitMQ で内部エラーが発生し、メッセージが失われた場合、nack (未確認、未確認) メッセージが送信されます。

送信者確認モードは非同期であり、プロデューサーアプリケーションは確認を待っている間もメッセージの送信を続けることができます。確認メッセージがプロデューサーアプリケーションに到達すると、プロデューサーアプリケーションのコールバックメソッドがトリガーされて、確認メッセージを処理します。

#受信者確認メカニズム

受信者メッセージ確認メカニズム

消費者は各メッセージを受信します。すべてのメッセージは次のとおりです。（メッセージの受信とメッセージの確認は 2 つの異なる操作です）。コンシューマがメッセージを確認した場合にのみ、RabbitMQ はキューからメッセージを安全に削除できます。ここではタイムアウトメカニズムは使用されません。RabbitMQ は、Consumer 接続の中断を通じてメッセージを再送信する必要があるかどうかのみを確認します。言い換えれば、接続が中断されない限り、RabbitMQ はコンシューマにメッセージを処理するのに十分な時間を与えます。データの最終的な一貫性を確保します。

以下はいくつかの特殊なケースです

コンシューマがメッセージを受信し、それを確認する前に切断した場合接続時またはサブスクライブを解除すると、RabbitMQ はメッセージが配布されていないと見なし、次のサブスクライブ済みコンシューマーにメッセージを再配布します。 (メッセージを繰り返し消費する潜在的な危険性があり、重複を削除する必要がある場合があります)

コンシューマーがメッセージを受信してもメッセージを確認せず、接続が切断されない場合、RabbitMQコンシューマがビジーであるとみなされるため、このコンシューマにはこれ以上メッセージが配信されません。

メッセージを消費するときは、メッセージ本文に bizId (支払い ID、注文 ID、投稿 ID など、同じビジネスに対してグローバルに一意) が必要です。、など）を避けるための重複排除の基礎として同じメッセージが繰り返し消費されることを防ぎます。 6. メッセージはどのような根拠に基づいて送信されますか?

TCP 接続の作成と破棄にはコストがかかり、同時実行数はシステムリソースによって制限されるため、パフォーマンスのボトルネックが発生します。 RabbitMQ はチャネルを使用してデータを送信します。チャネルは、実際の TCP 接続内で確立される仮想接続であり、各 TCP 接続のチャネル数に制限はありません。

#7. メッセージを配布するにはどうすればよいですか?

キューに少なくとも 1 つのコンシューマサブスクリプションがある場合、メッセージはラウンドロビン方式でコンシューマに送信されます。各メッセージは、1 つのサブスクライブされたコンシューマにのみ配布されます (コンシューマがメッセージを処理し、正常に確認できる場合)。ルーティングを通じて複数の消費機能を実現できます

#8. メッセージをルーティングするにはどうすればよいですか?

メッセージプロバイダー -> ルーティング -> 1 つから複数のキューメッセージが交換にパブリッシュされると、メッセージにはルーティングキー (ルーティングキー) が含まれます。これは、メッセージの作成時に設定されます。キューは、キュールーティングキーを介してスイッチにバインドできます。

メッセージがエクスチェンジャーに到着すると、RabbitMQ はメッセージのルーティングキーとキューのルーティングキーを照合します (エクスチェンジャーごとに異なるルーティングルールがあります);

一般的に使用されるエクスチェンジャーは次のとおりです。主に 3 つのタイプに分けられます。

fanout: 交換機がメッセージを受信すると、すべてのバインドされたキューにブロードキャストされます
direct: If theルーティングキーが正確に一致すると、メッセージは対応するキューに配信されます。
トピック: 異なるソースからのメッセージが同じキューに到達できるようにします。トピックエクスチェンジャーを使用する場合、ワイルドカード

9 を使用できます。メッセージが失われないようにするにはどうすればよいですか?

メッセージの永続性は、もちろん、キューが永続的であることが前提です。RabbitMQ がサーバーの再起動から永続的なメッセージを確実に回復できるようにする方法は、メッセージを永続的なログファイルに書き込むことです。ディスク上にあるため、永続メッセージを永続交換にパブリッシュする場合、Rabbit はメッセージがログファイルに送信されるまで応答を送信しません。

コンシューマーが永続キューから永続メッセージを消費すると、RabbitMQ は永続ログ内のメッセージにガベージコレクション待ちとしてマークを付けます。永続メッセージが消費される前に RabbitMQ が再起動されると、Rabbit は交換とキュー (およびバインディング) を自動的に再構築し、永続ログファイル内のメッセージを適切なキューに再パブリッシュします。

10. RabbitMQ を使用する利点は何ですか?

1. サービス間の高度な分離

2. 高い非同期通信パフォーマンス

3. トラフィックのピークカット

11、rabbitmq クラスター

ミラークラスターモード

キュー内のメタデータやメッセージに関係なく、作成するキュー。複数のインスタンスに存在し、キューにメッセージを書き込むたびに、メッセージは同期のために複数のインスタンスのキューに自動的に送信されます。

利点は、いずれかのマシンがダウンしても問題なく、他のマシンを使用できることです。欠点は、まずパフォーマンスのオーバーヘッドが高すぎることです。メッセージはすべてのマシンで同期されるため、ネットワーク帯域幅の負荷が大きくなり、ネットワーク帯域幅が大量に消費されます。第 2 に、このようにプレイするとスケーラビリティがありません。キューの負荷が高いときにマシンを追加すると、新しいマシンにはキューのすべてのデータも含まれることになり、キューを線形に拡張する方法はありません

12.mq の欠点

システム可用性の低下

システムに導入される外部依存関係が増えるほど、ハングアップしやすいほうが良いのですが、元々はシステム A が BCD とシステム ABCD の 3 つのシステムを呼び出すためのインターフェイスにすぎません。問題ありません。MQ を追加すると、MQ がハングアップしたらどうなりますか? MQ がハングアップしてシステム全体が崩壊したら、破滅するのではないでしょうか?

システムの複雑さの増加

MQ を突然追加した場合、メッセージが繰り返し消費されないようにするにはどうすればよいでしょうか?メッセージ損失にどう対処するか?メッセージ配信の順序を保証するにはどうすればよいですか?大きな頭、大きな頭、たくさんの問題、終わりのない苦痛

13. 一貫性の問題

システムは処理、成功後に直接戻ります。人々は皆、あなたのリクエストは成功したと思っていますが、問題は、BCD の 3 つのシステムと BD の 2 つのシステムのうち、ライブラリの書き込みに成功したのに、C システムがライブラリの書き込みに失敗した場合、どうすればよいでしょうか?データに一貫性がありません。

つまり、メッセージキューは実際には非常に複雑なアーキテクチャです。メッセージキューを導入すると多くの利点がありますが、それがもたらす欠点を避けるために、さまざまな追加の技術的ソリューションやアーキテクチャを作成する必要もあります。そうするのが最善です。後になって、なんと、システムの複雑さが 1 桁増加し、おそらく 10 倍も複雑になっていることがわかります。しかし、重要な瞬間には、やはりそれを使用する必要があります。

14. 分散トランザクション

分割された送信。アービターが存在し、すべてのノードにメッセージを送信します。すべてのノードが確認された後にのみ成功します。それ以外の場合は、再送信を待つ必要があります。

15. ライブブロードキャストのような突然の大規模なトラフィック状況に備えて設計する方法。