2023 年の最新の PHP 面接の質問 28 件を共有します (回答付き)-PHPチュートリアル-php.cn

この記事は、基礎知識を整理するために、PHP 面接の質問 28 問 (回答付き) をまとめて共有しています。一定の参考価値があります。困っている友人は参考にしてください。皆様のお役に立てれば幸いです。

2023 年の最新の PHP 面接の質問 28 件を共有します (回答付き)

関連する推奨事項: 2023 PHP 面接の質問の概要 (コレクション)

新年後の計画新しい仕事の機会を探すために、多くの基本的な面接についての理解と勉強がこれまで十分に深まっていなかったことがわかり、前進を続けるために、最近、フォーラムや検索エンジンで関連する知識を学び、まとめ始めました。質問の一部はフォーラムからのものです。先輩方が共有した質問や回答、そして最近のインタビューで私が遭遇した質問も含まれています。私自身の理解と先輩方の共有に基づいて、その一部をアーカイブしたので共有します。他の友人にも役立つことを願っています。また、誤解について専門家から指導を受けることができれば幸いです。また、近い将来更新し続ける予定です。

1. 基本的な実装原則PHP 配列

#1 の場合、基礎となる実装はハッシュテーブル (ハッシュテーブル) の二重リンクリスト (ハッシュの競合の解決) を介して行われます。

hashtable: マッピング関数 Value (Bucket->h) を通じてさまざまなキーワード (キー) のハッシュを計算し、対応する Bucket に直接インデックス付けします
ハッシュテーブルはポインターを保存します現在のループの処理を行うため、foreach は for
よりも高速です。
Bucket: 配列要素のキーと値、およびハッシュ値 h

#2. 順序性を確保する方法

1. ハッシュ関数と要素の間に記憶要素配列と同じサイズのマッピングテーブルを追加します。配列（バケット）。
2. 実際のストレージ配列に要素を格納するために使用される添え字
3. 要素は、実際のストレージ配列に挿入されます。配列内のマッピングテーブル
の順序 4. マッピングテーブルは単なる理論上のアイデアです。実際には、実際のマッピングテーブルはありません。代わりに、バケットメモリが割り当てられるときに、初期化では、uint32_t のサイズと同じスペースの量を指定し、arData を要素の配列が格納されている場所にオフセットします。

3. ハッシュの重複を解決する (PHP で使用されるリンクリスト方式):

1. リンクリスト方式:異なるキー単語が同じ単位を指している場合、リンクリストを使用してキーワードを保存します (リンクリストをたどってキーを照合します)
2. オープンアドレッシング方法: キーワードがデータがすでに存在するユニットを指している場合は、使用可能なユニットが見つかるまで他のユニットの検索を続行します (他のユニットの位置を占有し、ハッシュ競合が発生しやすくなり、パフォーマンスが低下します)

#4. 基礎知識

## リンクリスト: ポインタ次の要素を指す要素の
#双方向リンクリスト: 前の要素へのポインタ次の要素へのポインタ複雑さと空間の複雑さ

1. コード実装

         $arr = [2, 4, 1, 5, 3, 6];
         for ($i = 0; $i < (count($arr)); $i++) {
             for ($j = $i + 1; $j < (count($arr)); $j++) {
                 if ($arr[$i] <= $arr[$j]) {
                     $temp = $arr[$i];
                     $arr[$i] = $arr[$j];
                     $arr[$j] = $temp;
                 }
             }
         }
     result : [6,5,4,3,2,1]

ログイン後にコピー

2. 計算原理

第 1 ラウンド: 配列の最初の要素を他のすべての要素と比較し、大きい方の要素を選択し、順序を変更して、最初に大きい (最大の) 要素をバブルアップします。

最初のラウンド: 配列の 2 番目の要素と他のすべての要素を組み合わせて比較します (最初に大きい要素はフィルターで除外されているため、比較を続ける必要はありません)、大きい方の要素の順序を変更します。 2 番目に大きい要素

... など、大きいものから小さいものまでバブルによって並べ替えられた配列

平均時間計算量:
O(n^2)
最適な時間計算量程度:
O(n)
空間複雑度:
O(1)

最適な空間複雑度: O(1) 、ソート済み、位置を入れ替える必要なし

3. 時間計算量と空間計算量

時間計算量: プロセス全体は漸近的な時間計算量であり、使用量を推定します。プロセッサの効率 (アルゴリズムの効率の傾向を説明します。アルゴリズム時間の特定の使用法には言及しません。異なるマシンのパフォーマンスには一貫性がないため、これは単なる一般的な効率計算方法です) 表現メソッド: Big O 表記法

複雑さのメトリックレベル:

定数次数 O(1)

線形次数 O(n)

平方次数 O(n²)

三次次数 O(n³ )

K 乗次数 O(n^k)

指数次数 (2^n)

対数次数 O(logN)

線形対数次数 O(nlogN)

時間レプリケーションタイプ:

最高の時間複雑さ

最悪の時間複雑さ

平均時間複雑さ

償却時間計算量

空間計算量: プロセス全体の漸近的な空間計算量。コンピューターメモリの使用量を推定します (実際の占有空間ではなく、アルゴリズムトレンドによって占有される記憶域空間を記述します)。同上)

参考:

この記事では、アルゴリズムの時間計算量と空間計算量について説明します

3. 7 層のネットワークプロトコルと TCP および TCP

アプリケーション層、プレゼンテーション層、セッション層、トランスポート層、ネットワーク層、(データ) リンク層、物理層

記憶ルーチン:

最初の単語: フォームと転送への応答 (Things Chain Network)

最初の単語: アプリケーション層 (何度も出てくるので覚えやすい)

最初の 4 つの順方向: 表現する必要がある - 送信される

最後の 3 つの逆方向: モノのインターネットの同音異義語は、モノのインターネットよりも覚えやすい

4 . TCP と UDP の特徴と違い

1. これらはすべてトランスポート層プロトコルに属します

2.TCP

接続指向であるため、1 対 1 のみ可能です

バイトストリーム送信を指向しています

#データは信頼性が高く、失われることはありません

全二重通信

3. UDP (規定によると逆) TCP の特性)

接続なし、1 対 1、1 対多、多対多をサポート

#絶縁重視の伝送

ヘッダーのオーバーヘッドが小さく、データの信頼性は必ずしも高くありませんが、高速です

5. TCP の 3 つ-way ハンドシェイクと 4-way wave

1. 3-way ハンドシェイク:

##1) 初回: クライアントが SYN を送信= 1,seq = client_isn

関数:

クライアント: なし

サーバー: 自身の受信関数とクライアントの送信関数を確認

#2) 2 回目: サーバーは SYN = 1、seq = server_isn、ACK =client_isn 1 を送信します。

機能:
クライアント: 自身の送受信が正常であることを確認し、サーバーの送受信は正常です
サーバー：自身の送受信が正常であることを確認、サーバーの送受信が正常であることを確認送信は正常です（この時点ではサーバーはクライアントが正常かどうか確認できません）正常に受信)

3) 3 回目: クライアントは SYN = 0、ACK = server_isn 1、seq =client_isn 1 を送信します

機能: 双方がそれぞれを確認します。相手の受信と送信は正常であり、接続が確立されます

#2. 4 回振る

1) 初回: クライアントは FIN

を送信します。機能: 送信するデータがないことをサーバーに伝えます (ただし、データは受信できます)

2 ) 2 回目: サーバーsends ACK

機能: リクエストが受信されたことをクライアントに伝えます。サーバーにはまだ送信するデータがある可能性があるため、クライアントは受信時に FIN_WAIT 状態に入り、サーバーのデータ送信が完了するのを待ちます。その後、FIN を送信します。

##3) 3 回目: サーバーは FIN

を送信します。機能: サーバーはクライアントに、送信が完了したので接続を閉じてもよいことを伝えます。

4) 4 回目: クライアントは ACK を送信します。

機能: FIN を受信した後、クライアントはサーバーが閉じることを知らないのではないかと心配するため、 ACK を送信します。TIME_WAIT を入力して 2MSL 待ちます。応答が受信されない場合は、サーバーが閉じられたことがわかります。このとき、クライアントも接続を閉じます。

注:

相手の FIN メッセージを受信した場合、相手はデータを送信しなくなったが、引き続きデータを受信できることを意味します。

ネットワークの信頼性が低いため、最終的には 2MSL を待つ必要があります。サーバーが最後の ACK を受信しない場合、サーバーは FIN パケットを再生し、クライアントからの応答を待ちます。 ACK パケットを再度送信してから閉じます (したがって、クライアントは最後の ACK を送信した直後に接続を閉じることはできません)

6. HTTP ステータスコード

1. ステータスコード分類

#- 1xx: 情報、サーバーはリクエストを受信したため、リクエスターは操作を続行する必要があります

#- 2xx: 成功
- 3xx: リダイレクト

##- 4xx: クライアントエラー

- 5xx: サーバーエラー

2. 一般的なステータスコード

200: リクエスト成功しました
301: 永続的なリダイレクト

302: 一時的な移動

#400 不正なリクエスト: クライアントのリクエスト構文エラー＃＃＃

#401 無許可: クライアントに権限がありません

#403 禁止: サーバーがクライアントの要求を拒否しました

##404見つかりません: クライアントによって要求されたリソースは存在しません

500 内部サーバーエラー: サーバー内部エラー

502 不正なゲートウェイ: として動作していますゲートウェイまたはプロキシサーバーはリクエストの実行中に上流サーバーから無効な応答を受け取りました

#503 サービスを利用できません過負荷またはシステムメンテナンス

#504 ゲートウェイタイムアウト: ゲートウェイタイムアウト

3. 502

の理由と解決策原因: nginx がゲートウェイにリクエストを送信します (php- fpm) 例外を処理します
1) fastcgi バッファーの設定が小さすぎます

fastcgi_buffers 8 16k;

fastcgi_buffer_size 32k;
2) php-cgi プロセスの数が少なすぎます。
FastCgi プロセスの数を確認します: netstat -anpo | grep "php-cgi"| wc - l

パラメータの調整子プロセスの最大数:
max_children
通常、設定する必要がある子プロセスの数は、単一のプロセスに基づいて計算されます。 20M の
3) max_requests (メモリオーバーフローまたは頻繁な再起動)
このパラメーターは、各子が処理できるリクエストの最大数を指定します。最大値に達すると、子は再起動されます。
設定が小さすぎると、子の頻繁な再起動が発生する可能性があります:
PHP は各子にリクエストをポーリングします。大規模なトラフィックシナリオでは、各子が最大値に達するまでの時間はほぼ設定した場合小さすぎると複数の子が同時に閉じられる可能性があり、nginx が php-fpm にリクエストを転送できず、CPU が減って負荷が高くなります。
設定が大きすぎるとメモリリークが発生する可能性があります
4) PHP の実行時間が nginx の待機時間を超えます

fastcgi_connect_timeout

fastcgi_send_timeout

fastcgi_read_timeout
5) fastcgi 実行時間
max_execution_time

参考:

php php-fom nginx 設定パラメータを最適化する方法の詳細についてはこちらをご覧ください

nginx がエラー 502 を報告した場合はどうすればよいですか?ソリューションの共有

7. http と HTTPS

の違い 1. ポート: http 80; https: 443
2. http はステートレス、https は暗号化通信が可能な http ssl で構築されたプロトコルです
3. http 平文通信、https 暗号化通信
4. http は 3 つあり、高速です-way ハンドシェイクパッケージ、https には 12 のパッケージが必要 (3 つの tcp パッケージと 9 つの ssl ハンドシェイクパッケージ)

8. Redis 分散ロックと問題

1. 実装：
ロック: setnx
ロック解除: del
ロックタイムアウト: 期限切れ

2. 考えられる問題

1) setnx と期限切れの非アトミック性の問題 (ロック後にタイムアウトを設定できる前にハングします)
解決策:

Redis 2.6 .12 以降では、set 命令にオプションのパラメータが追加されます。疑似コードは次のとおりです: set (key, 1, 30, NX)。setnx 命令

2) を置き換えることができます。タイムアウト後に他のプロセスロックが誤って削除されます。 (プロセスAの実行がタイムアウトとなり、ロックが解除されます。このとき、プロセスBがロックを取得し、リクエストの処理を開始します。プロセスAが処理を完了すると、プロセスBのロックが誤って削除されてしまいます)
解決策: 削除できるのは自分のプロセスロックのロックのみです (lua スクリプトは、プロセス B が期限切れのロックを取得した後にプロセス A のロックを誤って削除するのを防ぎます)

3) 同時実行シナリオ。プロセス A の実行タイムアウトによりロックが解放され、この時点でプロセス B がロックを取得します。
解決策: デーモンプロセスを開始し、現在のプロセスのロックが期限切れになるのを遅らせます。

#4) シングルポイントインスタンスのセキュリティ問題

1 台のマシンがクラッシュすると、すべてのクライアントがロックを取得できなくなります

解決策:

マスター/スレーブのレプリケーションは非同期で完了するため完全には解決できません

参考:

Redis は分散ロックを実装するときに注意が必要です何？ [メモの概要]

Redis の分散ロックについて詳しく理解しましょう

9. Redis が単一である理由ネジ式？なぜ速いのでしょうか？

推奨書籍: //m.sbmmt.com/redis/475918.html
10. Redis のデータ型とアプリケーションシナリオ
1. 文字列:
通常のキー/値ストレージ

2. ハッシュ:

ハッシュマップ: キーと値のチームコレクション、オブジェクト情報の保存

3、リスト:

二重リンクリスト: メッセージキュー

4 、セット:

値が常に null である hashMap: 順序付けされていないセットおよび非繰り返し: 交差、和集合、差分セット、重複排除値を計算します

5、zset ：

重複のない順序付きコレクション：hashMap（重複削除）スキップリストジャンプテーブル（順序保証）：ランキングリスト

参考：

Redis の 5 つのデータ型と適用シナリオ

11. 永続化を実現する Redis の手法、原理、特徴

1. RDB 永続性 (スナップショット): 指定された時間間隔内のメモリデータセットのスナップショットがディスク (dump.rdb) に書き込まれ、子プロセスがスナップショットの内容を書き込むと、新しいファイルが古いファイルを置き換えます。

2) Redis データベース全体には 1 つのバックアップファイルのみが含まれます

3) パフォーマンスを最大化します。永続化作業を完了し、ディスク IO を削減するにはフォーク子プロセスのみが必要です

4) 永続化前のダウンタイムによりデータ損失が発生する可能性があります

2. AOF 永続化: ログの形式でサーバーのすべての書き込みおよび削除操作を記録します
1) 毎回書き込みコマンドを受信したら、書き込み関数を使用してファイル appendonly.aof

2) に追加します。永続ファイルは長くなるので、冗長なログが大量に発生します (100 から 0 が増加します)。 100 倍にすると、100 個のログレコードが生成されます)
##3) さまざまな fsync ポリシーを設定できます

appendfsync Everysec: 1 秒ごとに、最大 1 秒のデータが生成されます失われます (デフォルト)

appendfsync always : すべての変更が 1 回実行されます

appendfsync no : 処理されません

4) AOF ファイルが大きすぎる場合は書き換えられます。AOF ファイルのサイズを圧縮します。

子プロセスと Redis をフォークします。メインランドデータオブジェクトの最新ステータスAOF 一時ファイル (rdb スナップショットと同様) に書き込まれます。

メインプロセスによって受け取られた変更は、まずメモリに書き込まれ、次に古い AOF ファイルに同期されます (データの整合性)書き換えが失敗した後でも保証できます)

#子プロセスが書き換えを完了すると、メモリ内の新しい変更が AOF
## の一時ファイルに同期的に追加されます。

#親プロセスは、一時 AOF ファイルを新しい AOF ファイルに置き換え、名前を変更します。後で受信した新しいコマンドは新しいファイルに書き込まれます

参考:

Redis の詳細な学習の永続化原理の詳細な説明

RDB と AOF の永続性の簡単な分析、利点と欠点は何ですか?選び方は？

#12. フラッシュセールの設計プロセスと困難さ

#1. 静的キャッシュ
2. nginx ロードバランシング
# 3 つのメソッド: DNS ポーリング、IP デットバランシング、CDN

3、電流制限メカニズム

メソッド: IP 電流制限、インターフェイストークン電流制限、ユーザー電流制限、ヘッダー動的トークン (フロントエンド暗号化、バックエンド復号化)

#4、分散ロック #メソッド:

setnxexpired (非アトミック、set は redis2.6 以降アトミック性を保証します)

ロックタイムアウトの解放 (デーモンプロセスの開始、自動更新)時間)

期限切れのロックにより他のスレッドが誤って削除されました (検索と削除のアトミック性を確保するための requestId 検証または lua スクリプト)

5. データのキャッシュ

方法:

キャッシュの内訳: キャッシュデータの予熱ブルームフィルター/キャッシュを空にする

キャッシュなだれ: キャッシュはランダムな有効期限を設定して、同時に有効期限が切れることを防ぎます

#6. 在庫と注文

#在庫の差し引き

redis は在庫を自動的に減らします。これにより、同時シナリオでは負の数値が発生し、在庫の返品に影響を与える可能性があります。アトミック性を確保するには、lua スクリプトを使用してください。

Redis が在庫を保留した後、非同期メッセージを使用して注文を作成し、在庫の変更を更新します

データベースはオプティミスティックロックを使用して在庫を更新します: ここで、stock_num - sell_num > 0

非同期メッセージの損失を防ぐために、メッセージ送信レコードテーブルと再試行メカニズムを追加します

#注文を作成します

#フロントエンドは WebSocket 接続を確立するか、ポーリングして注文ステータスを監視します

繰り返し消費を防ぐための消費検証レコードのステータス

倉庫への返品

注文の作成後に遅延メッセージを送信して、注文の支払い状況と在庫を倉庫に返品する必要があるかどうかを確認します

##13. SQL インジェクションの防止

1. 特殊文字のフィルター
2. データベースキーワードのフィルター

3. データ型と形式の確認

4. プリコンパイルモードの使用と変数のバインド

14. トランザクション分離レベル

1. 標準 SQL 分離レベル実装原則

非コミット読み取り: 他のトランザクションは直接非コミット読み取り可能: ダーティ読み取り

トランザクション現在読み取られているデータをロックしません

#更新時に行レベルの共有ロックを追加し、トランザクションの終了時に解放します

##コミットされた読み取り: トランザクションの開始と終了の間に読み取られたデータは矛盾している可能性があります。トランザクション内の他のトランザクションがデータを変更しました: 反復性はありません

トランザクションは、トランザクションに悪影響を及ぼします。現在読み取られているデータ (読み取り時) 行レベルの共有ロック、読み取り後に解放

#更新時に行レベルの排他ロックを追加し、トランザクションの終了時に解放

反復可能な読み取り: トランザクションの開始前と終了前に読み取られたデータは一貫しています。トランザクション内の他のトランザクションはデータを変更できません: 反復可能な読み取り

トランザクションは現在のデータを読み取ります。トランザクションの開始時から受信データに行レベルの共有ロックが追加されます。

##行レベルの排他ロックが追加されます。更新の瞬間にトランザクションの終了時に解放されます

他のトランザクションはトランザクションプロセス中に新しいデータを追加する可能性があり、その結果ファントム読み取りが発生します

シリアル化

トランザクション読み取りデータフェッチ時にテーブルレベルの共有ロックを追加

テーブルレベルの排他ロックを追加トランザクションがデータを更新するとき

## 2. Innodb のトランザクション分離レベルと実装原則 (!! 上記とは異なり、1 つは分離レベルであり、もう 1 つは分離レベルであることを理解してください) !! トランザクション!! 分離レベル)

1) 基本概念

mvcc: マルチバージョン同時実行制御: UNDO ログと読み取りに依存します。 view

#データをロックせずにデータを読み取れるようにします。データベースの同時処理能力を向上させます

書き込み操作はロックされます

1 つのデータには複数のバージョンがあり、トランザクションがデータを更新するたびに、新しいデータバージョンが生成され、古いデータが元に戻すログに保持されます

#トランザクションが開始されると、送信されたすべてのトランザクション結果のみが表示されます

#現在の読み取り: 最新バージョンを読み取ります

スナップショット読み取り: 過去のバージョンを読み取ります
ギャップロック: ギャップロックは、範囲内のインデックスをロックします
範囲内に存在するかどうかに関係なく、10 から 20 までの ID を更新します。

# データは範囲全体をロックします: ID = 15 を挿入すると、阻止されます

リピート可能な読み取り分離レベルのみギャップロックがあります

ネクストキーロック:

レコードロックインデックスレコードのギャップロック (インデックス値と前のインデックス値の間のギャップロック)

前に開き、後ろに閉じる

ファントム読み取りの防止

##2) トランザクション分離レベル

非コミット読み取り

##トランザクションは現在読み取られているデータをロックしません。すべてが現在の読み取りです。

#更新時に行レベルの共有ロックを追加し、更新の最後に解放します。トランザクション

#コミット読み取り

トランザクションは現在読み取られているデータをロックせず、すべてスナップショット読み取りです

更新時に行レベルの排他ロックを追加し、トランザクションの終了時に解放します

反復可能な読み取り

##トランザクションは現在読み取られているデータをロックしません。すべてスナップショット読み取りです

トランザクションが特定のデータを更新すると、行-レベル排他ロック (レコードレコードロック、ギャップギャップロック、ネクストキーロック) を追加する必要があり、トランザクション終了後にトランザクションは解放されます。

#ギャップロックはファントムリードの問題を解決します

マスタースレーブレプリケーションの場合、ギャップロックがない場合、マスターライブラリのAプロセスとBプロセス

#Aプロセスdelete id

B プロセス挿入 ID = 3、コミット

プロセスがコミットを送信します

このシナリオでは、マスターライブラリに ID =3 のレコードが存在しますが、それが最初に削除されてからバイナリに追加されると、スレーブライブラリにはデータがなくなり、その結果、マスターとスレーブの間でデータの不整合が発生します。

MVCC のスナップショットは、反復不可能な読み取りの問題を解決します。

シリアル化

トランザクションがデータを読み取るときにテーブルレベルのロックを追加し、現在の読み取り時にテーブルレベルの排他ロックを追加します

トランザクション更新データ

#参考:
#MySQL におけるトランザクション分離レベルの実装原理

この記事では、MySQL のトランザクションと MVCC の原則について説明します

#MVCC ではスナップショットはどのように機能しますか?

MVCC とは何ですか?なぜギャップロックを設計する必要があるのですか?

15. インデックスの原則

インデックスは、データベースがデータを効率的に検索できるようにするストレージ構造です。ディスクに保存する場合は、ディスク IO

が必要です。 1. ストレージエンジン

myisam はテーブルロックをサポートし、インデックスとデータは個別に保存され、サーバー間の移行に適しています

innodb行ロック、インデックス、データストレージをサポート別のファイル

##2. インデックスタイプ

##ハッシュインデックス

正確なクエリと高効率に適しています
ソートできないため、範囲クエリには適していません
ハッシュ競合の場合、リンクされたリストを走査する必要があります (php 配列の実装原理と redis zset の実装原理は似ています)

b-tree, bツリー

b ツリーと b ツリーを区別するには

b ツリーのデータはすべてリーフノードに格納され、キーは内部ノードに保存されます。1 つのディスク IO でより多くのノードを取得できます
B ツリーの内部ノードとリーフノードの両方にキーとデータが保存されます。データの検索には検索は必要ありませんリーフノード。内部ノードはデータを直接返すことができます。
b ツリーが追加されました。リターンクエリのトラバーサルを容易にするために、リーフノードから隣接するノードへのポインタが追加されました。

クラスター化インデックスと非クラスター化インデックス

コンセプト

クラスター化インデックス: インデックスとデータ

#非クラスター化インデックス: インデックスとデータは別々に保存され、実際にデータが保存されているアドレスはインデックスを通じて見つけることができます

##詳細な説明:

innodb によって使用されるクラスター化インデックス、およびデフォルトの主キーインデックスは次のとおりです。クラスター化インデックス (主キーインデックスがない場合は、空でないインデックスを選択します。そうでない場合、主キーインデックスは暗黙的です)、補助インデックスはクラスター化インデックスの場所を指し、実際のストレージアドレスを見つけた後

myisam は非クラスター化インデックスを使用します。データを見つけるためにすべてのインデックスを 1 回クエリするだけで済みます。

クラスター化インデックスの利点と可能性
1. インデックスとデータは一緒で、同じページのデータは（バッファ）メモリにキャッシュされるので、同じページのデータを参照する場合は、インデックスからデータを取り出すだけで済みます。

2. データが更新された後は、主キーインデックスのみを維持する必要があり、補助インデックスは影響を受けません
3. 補助インデックスには、次の値が格納されます。主キーインデックスは、より多くの物理スペースを必要とします。したがって、影響を受けます。
4. ランダムな UUID を使用すると、データの分散が不均一になり、クラスター化インデックスがテーブル全体をスキャンして効率が低下するため、自動インクリメントされる主キー ID
を使用するようにしてください。

16. サブテーブル (サブデータベース) の戦略

1. プロセス

# # サブテーブルの容量と数を評価 -> ビジネスに応じてテーブルシャーディングキーを選択 -> テーブルシャーディングルール (ハッシュ、剰余、範囲) -> 実行 -> 拡張の問題を検討
#2. 水平方向の分割

フィールドに基づいて複数のテーブルに水平方向に分割します

各テーブルの構造は次のとおりです。同じ
#すべてのサブテーブルのコレクションが完全な量です
##3. 垂直分割

##フィールドに基づいて垂直に分割

#テーブルの構造が異なります。サブテーブル内の同じ関連する行は完全なデータです

拡張テーブル、ホットフィールド、および非ホットフィールドの分割 (リストと詳細の分割)

データを取得するときは、結合の使用を避け、結合するようにしてください。 2 つのクエリの結果

#4. 問題

##クロスデータベース結合の問題

##グローバルテーブル: 一部のシステムテーブルを関連付ける必要があるシナリオ

冗長性メソッド: 冗長共通フィールド

アセンブリメソッド:複数のクエリの結果を組み立てる

クロスノードのページング、並べ替え、および機能の問題
トランザクションの一貫性
グローバル主キー ID

uuid を使用すると、クラスター化インデックスの効率が低下します

分散自動インクリメント ID を使用します

#拡張の問題

##スレーブデータベースのアップグレード

##スレーブデータベースはマスターデータベースにアップグレードされます。データは一貫しているため、削除する必要があるのは冗長データベースのみです。残りのデータは可能です。

2 倍の拡張が必要です。スレーブライブラリを 2 倍にします。

二重書き込み移行:

新しいデータを古いデータベースと新しいデータベースに二重に書き込みます。同時に

#古いデータを新しいデータベースにコピーします

#古いデータベースを元に、データの整合性を確認した後、冗長なデータを削除します

17. 選択と更新処理の実行

1、mysql 構成

サーバー層: コネクタ -> キャッシュ -> アナライザー (プリプロセッサ) -> オプティマイザー -> エグゼキューター

#エンジン層: クエリとストアデータ

##2. 実行プロセスの選択

##クライアントはリクエストを送信し、接続を確立します
サーバー層はキャッシュを検索し、ヒットした場合は直接返します。そうでない場合は続行します。
分析 7 SQL ステートメントと前処理の分析 (フィールドの正当性や型などを検証)

#オプティマイザは実行計画を生成します

エグゼキュータはエンジン API クエリ結果を呼び出します

クエリ結果を返す

3. 更新実行プロセス

##基本概念

バッファプール (キャッシュプール)、メモリ内で、次回同じページのデータが読み取られるときに、バッファプール (innodb クラスター化インデックス) から直接返すことができます

更新データを更新するときは、最初にバッファプールを更新し、次にディスクを更新します。

#ダーティページ: メモリ内のキャッシュプールは更新されますが、ディスクは更新されません

ブラシダーティ: inndb には、バッファプールデータをディスクに書き込み、複数の変更を時々一度にディスクに書き込むための特別なプロセスがあります

redo ログと binlog

redo ログ (redo ログ)、innodb 固有のログ、物理ログ、レコード変更

redo ログ

#binlog は、サーバー層で共有されるログ、論理ログ、およびレコードです。ステートメントの元のロジック
binlog は、特定のサイズまでの書き込みを追加し、前のログを上書きせずに次のログに切り替えます。
REDO ログは主にクラッシュから回復するために使用され、bin ログはアーカイブされたバイナリログを記録するために使用されます

REDO ログは短期間のデータのみを回復できますが、binlog はより大規模なデータを回復できます

WAL (write -ahead-logging) の設定によるデータ。最初にログスキームを書き込みます。

ログはシーケンシャル IO# です。

##ディスクへの直接書き込み (フラッシュ) はランダム IO です。データはランダムであり、異なるセクターに分散される可能性があるためです。

シーケンシャル IO はさらに多くのことを意味します。最初に変更ログを書き込むと、フラッシュの機会が遅れ、スループットが向上します

#REDO ログフラッシュメカニズム、チェックポイント

#REDO ログサイズは固定、循環書き込み

# REDO ログは円のような形で、前にチェックポイント (この時点で古いログの上書きが開始されます) と、その後ろの書き込みポイント (現在書き込まれている位置)

書き込みポイントとチェックポイントが重なっている場合は、REDO ログがいっぱいであることを示しており、REDO ログの同期を開始する必要があります。

#ステップの実行 (2 フェーズコミット - 分散トランザクション、2 つのログの一貫性を確保)

更新条件を分析し、更新が必要なデータを見つける (キャッシュが使用されます)

サーバーはエンジン層の API、Innodb を呼び出します。データをメモリに更新し、REDO ログを書き込み、prepare を入力します

##エンジンはサーバー層にデータの送信を開始するように通知します

サーバー層はbinlogログを書き込み、innodbインターフェースを呼び出してコミットリクエストを発行します

#エンジン層はリクエストを受信した後にコミットを送信します

ダウンタイム後のデータクラッシュ回復ルール

##REDO ログのステータスがコミットの場合は、直接送信してください

##If REDO ログのステータスが準備中である場合は、バイナリログ内のトランザクションがコミットされているかどうかを確認します。コミットされている場合はコミットし、そうでない場合はロールバックします。 2 つのエラーケースを 2 回送信します (table_x の設定値 = 10、値 = 9 を更新)

最初に REDO ログを作成し、次に binlog に書き込みます

1. REDO ログの後バイナリログが完了していないため、この時点でマシンがダウンしていました。
2. 再起動後、REDO ログが完了するため、リカバリデータの値 = 10

3. bin ログにはレコードがありません。データをリカバリする必要がある場合は、値= 9

最初にバイナリログを書き込み、次にリドゥログを書き込みます
1. バイナリログの書き込みは完了しましたが、リドゥログは完了していません

2.再起動後の REDO ログのため、値はまだ 9

3. データを復元する必要がある場合、binlog ログは完了し、値は 10

に更新されます。

#undo ログ

更新がバッファプールに書き込まれる前の記録

#更新中にエラーが発生した場合

18. binlog の関数と 3 つの形式

Function:

1. データ復旧

# 2. マスター/スレーブレプリケーション

##形式 (バイナリファイル):

1) ステートメント
1. 各 SQL ステートメントの元のテキストを記録します

2. テーブルを削除するには、1 つの SQL ステートメントを記録するだけでよく、各行の変更を記録する必要はありません。これにより、IO が節約され、パフォーマンスが向上し、データ量が削減されます。ログ

3. マスターとスレーブの不一致が発生する可能性があります (ストアドプロシージャ、関数など)

#4. RC 分離レベル (読み取りコミット) )、バイナリログの記録順序はトランザクションのコミット順序に記録されるため、マスター/スレーブレプリケーションの不整合が発生する可能性があります。これは、反復読み取りレベルでギャップロックを導入することで解決できます。

2) 行

1. 各レコードの変更を記録します。SQL ステートメントのコンテキストレコードを記録する必要はありません

2. 大量の binlog ログが生成される

3. テーブルの削除: 削除される各レコードの状況を記録する

3) 混合

##1. 最初の 2 つの形式の混合バージョン

##2. 自動的に選択ステートメントに基づいてどれを使用するか：

一般的な SQL ステートメントの変更はステートメントを使用します
テーブル構造、関数、ストアドプロシージャなどを変更するには操作、行の選択

更新と削除では、記録されたすべての変更が記録されます

##19. マスターの原則・スレーブ同期（マスター・スレーブレプリケーション）問題と読み書きの分離

1. 解決した問題

#データ配布

ロードバランシング

データバックアップ、高可用性、単一障害点の回避
#
##読み取りと読み取りを実現書き込みの分離、データベースのプレッシャーの軽減

アップグレードテスト (スレーブライブラリとして上位バージョンの mysql を使用)

2. サポートされています。レプリケーションタイプ (3 つの形式の binlog)

SQL ステートメントベースのレプリケーション

行ベースのレプリケーション

ハイブリッドレプリケーション

3. 原理

#1) 基本概念

#ライブラリから 2 つのスレッドを生成

I/O スレッド

SQL スレッド

メインライブラリ生成スレッド

ログデュモスレッド

##2) プロセス (マスターノードは次のことを行う必要があります) bin ログ機能を有効にします,)

1. スレーブノードからスレーブ開始コマンドを開始した後、マスターノードに接続するための IO プロセスを作成します

#2. 接続が成功すると、マスターノードはログダンプスレッドを作成します (マスターノードはスレーブノードごとにログダンプスレッドを作成します)
3. binlog が変更されると、マスターノードのダンプログスレッドが bin-log の内容を読み取り、それをスレーブノードに送信します。
4. マスターノードのダンプログスレッドが内容を読み取ると、 bin-log を削除すると、マスターノードの bin-log がロックされます。読み取りはスレーブノードに送信する前に完了します。ロックを解除します。
5. IO スレッドスレーブノードのスレーブノードは、マスターノードから送信された binlog コンテンツを受信し、それをローカルリレーログファイルに書き込みます
6. マスター/スレーブノードは、次の方法でマスター/スレーブ同期の位置を特定します。 binlog ファイルの位置オフセット。スレーブノードは受信した位置オフセットを保存します。スレーブノードがクラッシュして再起動した場合、位置位置
#7 から自動的に同期を開始します。スレーブノードの SQL スレッドは、ローカルリレーログの内容をコピーして読み取り、それを特定の操作に解析して実行して、マスターとスレーブのデータの一貫性を確保します

4. マスター-スレーブレプリケーションモード

1) 非同期モード (デフォルトモード)

1. マスターとスレーブの不一致が発生する可能性があります (マスターとスレーブの遅延が発生する場合)

2. クライアントによって送信されたトランザクションを受信した後、マスターノードはトランザクションを直接送信し、クライアントに返します
3。マスターノードがノードトランザクションを送信した後、ログダンプが書き込まれる前にクラッシュし、マスターデータとスレーブデータの間で不整合が発生します。
4。マスターとスレーブの同期動作を気にする必要がなく、パフォーマンスは最高です。

2) 完全同期モード

1. より信頼性が高くなります。ただし、メインデータベースの応答時間に影響します

2. クライアントによって送信されたトランザクションを受信した後、マスターノードはバイナリログがスレーブライブラリに送信されるまで待機する必要があります。すべてのスレーブライブラリは、トランザクションをクライアントに返す前にトランザクションを完了する必要があります

##3) 半同期モード

1. 信頼性の一部を向上させます。メインライブラリの応答時間の一部を増加させます

2. メインノードはクライアントによって送信されたリクエストを受け取りますトランザクション後、バイナリログが少なくとも 1 つのノードに送信されるまで待ちますスレーブライブラリが作成され、ローカルリレーログに正常に保存されました。この時点で、マスターライブラリはトランザクションを送信し、クライアントに返します。

4) サーバー ID とサーバー UUID の構成

#1.server-id は、チェーンされたマスター/スレーブ、マルチマスター、およびマルチスレーブトポロジにおける SQL ステートメントの無限ループを防ぐためにデータベースインスタンスを識別するために使用されます

2.server-id のデフォルト値は 0 です。ホストのバイナリログは引き続き記録されますが、すべてのスレーブ接続は拒否されます。

2.server-id = 0 は、スレーブマシンの他のインスタンスへの接続を拒否します

3.server-id はグローバルです

#4. メインライブラリとスレーブライブラリのserver-idが重複している場合

#デフォルトのreplicate-same-server-id = 0、スレーブライブラリはすべてのマスター/スレーブ同期データをスキップし、結果としてマスター/スレーブデータの不整合が発生します

# #replicate -same-server-id = 1、sql のワイヤレスループ実行が発生する可能性があります。

2 つのスレーブライブラリ (B、C) のサーバー ID が重複すると、マスターとスレーブの接続異常、断続的な接続の原因

#メインライブラリ (A) が同じサーバー ID を見つけると、以前の接続を切断し、新しい接続を再登録します

スレーブライブラリ B および C への接続は何度も再接続されます

MySQL サービスは自動的に作成され、サーバー UUID 設定の生成

マスター/スレーブの同期が発生したときに、マスター/スレーブインスタンスのサーバー UUID が同じ場合、エラーが報告されて終了します。このエラーは、replicate-same-server-id=1 を設定することで回避できます (非推奨)

5. 読み取りと書き込みの分離

1) コード実装に基づく、ハードウェア費用の削減
2) 中間プロキシ実装に基づく
3) マスター/スレーブ遅延

スレーブライブラリのパフォーマンスはメインライブラリよりも劣ります

大量のクエリによりスレーブライブラリに負荷がかかりますサイズが大きく、多くの CPU リソースを消費し、影響を受けます同期速度: 1 つのマスター、複数のスレーブ

大規模なトランザクションの実行: トランザクションが実行されるまでバイナリログは書き込まれず、スレーブライブラリの読み取り遅延

メインライブラリ ddl (alter、drop、create)

Twenty、デッドロック

1. 生成された 4 つの必要な条件

1. 相互に排他的な条件

2. リクエストおよびホールド条件: すべてのリソースを一度に割り当て、それ以外の場合は 1 つが割り当てられません

3. 非剥奪条件: プロセスがいくつかのリソースを取得し、他のリソースを待機するとき、占有されていたリソースを解放します

4. ループ待機条件:

理解: リソースは 1 つのプロセスによってのみ占有できます。プロセスはリソースを取得した後に新しいリソースを申請することもでき、取得したリソースを奪うことはできません。同時に複数のプロセスが待機しています。リソース

#2. デッドロックを解放します

#1. プロセスを終了します (すべて殺してください)

2. 1 つずつ植えます (安心するかどうかを確認するために 1 つ殺してください)

21. 大規模な MySQL の最適化ページングクエリ制限 100000 (オフセット)、10 (page_sie )

1. 理由

mysql がページングデータをクエリするとき、オフセット (100000) を直接スキップしませんが、 offset page_size = 100000 10 = 100010 個のデータを取得し、最初の 100,000 個のデータを破棄するため、効率が低下します

#2. 最適化計画

##遅延関連付け: カバリングインデックスを使用します

主キーしきい値方式: 主キーが自動インクリメントされる場合、条件を満たす主キーの最大値と最小値条件は条件によって計算されます (カバリングインデックスを使用)

前のページの結果の位置を記録し、OFFSET

22 の使用を避けます。キャッシュと mysql データの一貫性

方法:

1. まず redis を更新し、次にデータベースを更新しますシナリオ: 設定値を更新 = 10 (値は 10) = 9

1) Redis 更新成功: redis 値 = 10

2) データベース更新失敗: mysql 値 = 9

3) データの不整合
# 2. 最初にデータベースを更新し、次に redis を更新します。
シナリオ: A プロセス更新設定値 = 10 where value = 9; B プロセス更新設定値 = 11 where value = 9;
1) A プロセスが最初にデータベースを更新し、まだキャッシュに書き込んでいません: mysql value = 10; redis value = 9
2) プロセス B がデータベースを更新してトランザクションを送信し、キャッシュに書き込みます: mysql value = 11 ; redis 値 = 11;
3) プロセス A はリクエストを完了し、トランザクションを送信し、キャッシュを書き込みます: redis 値 = 10;
4) 最終的な mysql 値 = 11; redis 値 = 10
3. 最初にキャッシュを削除してからデータベースを更新します
シナリオ: プロセス A が設定値 = 10 を更新し、値 = 9; プロセス B が値をクエリします;
1 ) プロセス A が最初にキャッシュを削除し、データを変更する時間がなかったか、トランザクションが送信されていません。
2) プロセス B がクエリを開始しますが、キャッシュにヒットしないため、データベースをチェックして、キャッシュ redis 値 = 9
3) プロセス A がデータベースを更新して mysql 値 = 10
4) 最終的な mysql 値 = 10; redis 値 = 9

解決策:

1. 遅延二重削除
シナリオ: A プロセス更新設定値 = 10 (値 = 9)、B プロセスクエリ値;
1)プロセス A は最初にキャッシュを削除しますが、データを変更する時間がなかったか、トランザクションが送信されていません
2) プロセス B はクエリを開始しますが、キャッシュにヒットしないため、データベースをチェックして、キャッシュ redis 値 = 9

3) プロセス A はデータベースを更新し、mysql を完了します。値 = 10
4) プロセス A は遅延時間を見積もり、スリープ後に再度キャッシュを削除します
5) 最終的な mysql 値 = 10;redis 値は空です (次回データベースを直接確認してください)

6) 遅延の理由は、プロセス A がキャッシュを更新した後にプロセス B がキャッシュに書き込むのを防ぐためです。

2. リクエストのシリアル化

1) 2 つのキューを作成します: updateキューとクエリキュー

2) キャッシュが存在せず、データベースをチェックする必要がある場合は、キーを更新キューに格納します

3) クエリの前に新しいリクエストが来た場合更新キューにキーがまだ存在することが判明した場合は、キーをクエリキューに入れて待機します。キーが存在しない場合は、2 番目の手順を繰り返します。

4) クエリされたデータが存在する場合クエリキューがすでに存在することがわかり、再度キューに書き込む必要はありません

5) データの更新が完了した後、rpop はキューを更新します。同時に、rpop はキューにクエリを実行し、キューを解放します。

6) クエリリクエストは、スリープ中にキャッシュをクエリし、最大遅延時間を設定するために使用できます。完了していない場合は、空の

Twenty-three が返されます。接続してください。 redis で pconnect を実行します

1. connect : スクリプト終了後に接続を解放します

1. close : 接続を解放します

2 . pconnect (長い接続): スクリプトが終了しても接続は解放されません。接続は php-fpm プロセスに残り、ライフサイクルは php-fpm プロセスのライフサイクルに従います

#1. close は接続を解放しません

現在の php-cgi プロセスでは redis を再度リクエストできないだけです

現在、php-fpm のライフサイクルが終了するまで、php-cgi の後続の接続は引き続き再利用できます

2. Redis を確立するコストを削減します。 connection

3. 複数の接続を確立するには 1 つの php-fpm を削減します

#4. より多くのメモリを消費し、接続数は増加し続けます

5. 同じ php-fpm ワーカーサブプロセス (php-cgi) の以前のリクエストは、次のリクエストに影響を与える可能性があります

3、pconnect 接続の再利用の問題
##変数 A select db 1; 変数 B select db 2; は変数 A

# の db に影響します。
# #解決策: 各 db の接続インスタンスを作成します

24. redis zset の順序付きコレクションにスキップリストを使用する原則

1. 基本概念

1. スキップリストは、階層リンクリスト内の要素を順序立てて保存するランダムデータです (要素が順序付けされている場合にのみ使用できます) 2. スキップリストは順序付きリンクリストと多層リンクリストに基づいて進化した実数
# 3. 重複した値が許可されるため、比較チェックではキーだけでなく値も比較する必要があります
4. 各ノードには高さ 1 の逆方向ポインタがあり、先頭方向から末尾方向への反復に使用されます。
5. 時間計算量 O(logn)、空間計算量 O(n)

2. スキップテーブルとバランスツリーの比較

#1) 範囲クエリの効率
#スキップテーブル範囲クエリの方が効率的です最小値を見つけた後は、最大値未満になるまで最初のレベルのリンクリストのみをトラバースするためです。

バランスの取れたツリー範囲クエリが最小値を見つけた後、順番に実行されます。最大値を超えない他のノードを見つけるためにトラバーサルが実行されます

2) メモリ使用量

skiplist 各ノードのポインターの数は 1/(1-p)

平衡ツリーの各ノードのポインタの数は 2

3) 挿入と削除操作

#skiplist は隣接するノードポインターを変更するだけで済みます

#バランスの取れたツリーを変更すると、サブツリーが調整されます

25. Redis の有効期限切れの削除と排除メカニズム

1. 従来の期限切れ削除戦略

1) スケジュールされた削除

タイマーにより期限切れになったらすぐに削除します

メモリは時間内に解放されますが、より多くの CPU を消費します。同時実行性が高いと CPU リソースが消費され、処理速度に影響します。リクエスト

メモリには優しく、CPU には優しくない

2) 遅延削除

キーの有効期限が切れているかどうかを確認し、次回削除する必要があるときに削除してください

使用されない期限切れのキーが大量に存在し、メモリオーバーフローが発生する可能性があります

#メモリには優しくない、CPU には優しい

3) 定期的に削除

##毎回チェックするwhile と期限切れのキーの削除

削除する量と確認する量はアルゴリズムによって決定されます

2. 遅延削除Redis によって採用されたキーは定期的に削除されます。

有効期限が設定されたキーを定期的にランダムにテストしてチェックします。有効期限が切れたら削除します。

各クリーンアップの時間は CPU の 25% を超えてはなりません。時間に達すると、チェックは終了します。

定期的に削除されないキーと削除されないキー今後使用するデータはメモリ内に残りますので、消去法と連携する必要があります

3. 消去法（メモリが足りなくて書き込みできない場合に実行）新しいデータ)

volatile-lru : 有効期限が設定されており、最近使用されていないものほど優先度が削除されます

volatile-ttl : 有効期限が設定されています有効期限が早いほど優先度が高くなります。

volatile-random: 有効期限をランダムに削除するように設定します

##allkeys-lru : すべてのキーの有効期限が早いほど、削除を優先します

allkeys-random: 期限切れのすべてのキーをランダムに削除します

no- enviction: 削除は許可されません、メモリ不足エラー

26. Redis の一般的な問題と解決策

1. キャッシュなだれ: 大量のキャッシュ障害が発生します。同時に、リクエストがデータベースに直接クエリするようになり、データベースメモリと CPU に負荷がかかり、ダウンタイムが増加したり、さらにはダウンタイムが発生したりします。
解決策:

ホットスポットデータは期限切れになりません。複数のインスタンスに分散され、単一マシンの障害の問題が軽減されます

多数のキャッシュが同時に無効化されないようにキャッシュ時間に乱数を追加します

二次キャッシュまたは二重キャッシュを実行します。A は短期間のオリジナルキャッシュ、B は長期間有効なバックアップキャッシュです。更新時の二重書き込みキャッシュ

#2. キャッシュの侵入: キャッシュとデータベースにデータが存在しないため、リクエストが多数ある場合、すべてのリクエストがデータベースに直接侵入しますダウンタイムの原因となります。
解決策:

ブルームフィルター: 長さ m のビットベクトルまたはビットリストで構成されます (0 または 1 ビット値を含むリストのみ)

未使用の複数のハッシュ関数を使用して複数のインデックス値を生成し、複数の位置に対応する値を 1

ブルームフィルターとして埋め込みます。値が「集合に含まれる可能性がある」か「絶対に集合に含まれない」かを確認できる

誤判定の可能性はあるが、基本的なフィルタリング効率は高い

極端な場合、ブルームフィルターに空き領域がない場合、各クエリは true を返します。

空のキャッシュ (短期)

ビジネス層パラメータフィルタリング

##3. キャッシュの内訳: データベース内にデータはありますが、キャッシュ後に突然大量のリクエストが発生します。失敗すると、データベースの負荷が増大したり、ダウンタイムが発生したりする可能性があります
解決策:

##ホットスポットデータは期限切れになりません

Mutex ロック: ロック取得後は成功失敗問わずロックを解除する必要があります

#27. php-fpm
#の詳細説明とライフサイクル
##1. 基本知識
1) CGI プロトコル

動的言語コードファイルがサーバーに認識されるには、対応するパーサーを渡す必要があります。

CGI プロトコルサーバーとインタープリターが相互に通信できるようにするために使用されます
サーバーには、PHP インタープリターと対応するPHP ファイルを解析するための CGI プロトコル
2 ) CGI プログラム = php-cgi
#php-cgi は、CGI に準拠した CGI プログラムです。プロトコル

PHPインタープリタでもあります
標準CGIの各リクエストは、php.iniの解析、実行環境の初期化などを行います。パフォーマンスが低下します。

#php-cgi を再実行する必要があります。php.ini を有効にすることができます。

指定された数のみワーカーを動的にスケジュールできません。

##3) FastCGI プロトコル

CGI と同様のプロトコル/標準ですが、以下に基づいて最適化されています。

CGI プログラムのパフォーマンスを向上させるために使用されます

CGI プロセスの管理を実現します

4) FastCGI プログラム = php-fpm

php-fpm は、FastCGI プロトコルに準拠した FastCGI プログラムです。
#FastCGI プログラムの CGI プログラム管理モード

マスタープロセスを開始し、設定ファイルを解析し、環境を初期化します

複数のプロセスを開始しますワーカーサブプロセス

リクエストを受信したら、実行のためにワーカープロセスに渡します

問題を解決するphp.ini 変更後のスムーズな再起動の速度

#process_control_timeout: 子プロセスがメインプロセス多重化信号を受け入れるためのタイムアウト (指定された時間内にリクエストを処理し、放置します)完了できない場合)
fastcgi プロセスが再起動信号に応答するまでに php-fpm が残す時間を設定します

process_control_timeout = 0つまり、有効にならず、スムーズな再起動は保証されません。

process_control_timeout の設定が大きすぎると、システムリクエストがブロックされる可能性があります。

process_control_timeout = 10 この場合、コードロジックに 11 秒かかる場合、古いロジックを再起動するとコード実行部分が終了する可能性があります。

# 推奨値: request_terminate_timeout

再起動の種類

グレースフルリスタート

強制再起動

2. php-fpm ライフサイクル: 更新予定

PHP-FPM ライフサイクル: https://www.abelzhou.com/php/php-fpm-lifespan/

#参考:

チャットコミュニケーションPHP-FPM と Nginx の間のメカニズム

PHP 設定ファイル内のいくつかのタイムアウト設定の簡単な分析

nginx のスムーズな再起動とFPM Smooth restart

28、Nginx と php

1 間の通信。通信メソッド: fastcgi_pass

1 ) tcp ソケット

クロスサーバー、nginx と php が同じマシン上にない場合、この方法のみを使用できます

接続指向通信の正確性と整合性を確保するためのプロトコルの方が良いです。

2) unix ソケット

ネットワークプロトコルスタック、パッケージ化、解凍が不要です。 etc.

tcp オーバーヘッドを削減し、tcp ソケットよりも効率的です

高同時実行時や、数が急激に増加すると不安定になります。接続数が多いと、大量の長期キャッシュとビッグデータが生成されます。パッケージは直接例外を返す場合があります。

参考:

次について話しましょう。 PHP-FPM と Nginx 間の通信メカニズム

Nginx と php-fpm 間の通信メカニズムの簡単な分析

29. Web の脆弱性問題と問題

##1. SQL インジェクション

2. XSS 攻撃を防ぐには? ](https://tech.meituan.com/2018/09/27/fe-security.html)
3. CSRF 攻撃:

推奨読書: 【フロントエンドセキュリティシリーズ(2)：CSRF攻撃を防ぐには？ ](https://tech.meituan.com/2018/10/11/fe-security-csrf.html)
4. ファイルアップロードの脆弱性

推奨読書: [ファイルアップロードの脆弱性の簡単な分析](https://xz.aliyun.com/t/7365)#5. クロスドメインの問題:

# 1) jsonp

2) cors 3) nginx エージェント

推奨学習: 「
PHP ビデオチュートリアル
」

以上が2023 年の最新の PHP 面接の質問 28 件を共有します (回答付き)の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。