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

この記事は、基礎知識を整理するために、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. 基礎知識

リンク リスト: キュー、スタック、双方向リンク リスト、

• ## リンク リスト: ポインタ次の要素を指す要素の

• #双方向リンク リスト: 前の要素へのポインタ 次の要素へのポインタ 複雑さと空間の複雑さ
#2. バブルソートの時間計算量と空間計算量

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 が単一である理由ネジ式？なぜ速いのでしょうか？

推奨書籍: https://www.php.cn/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 サイトの他の関連記事を参照してください。