この記事は、PHP コア テクノロジに関する 28 の面接の質問をまとめて共有し、PHP コア テクノロジを深く理解できるようにします。面接中の落とし穴をすぐに回避できます。転職には不可欠です。価値があります。集めて学んで、皆さんのお役に立てれば幸いです。
#関連する推奨事項: 「2022 PHP 面接の質問の概要 (コレクション)」
OOP には 3 つの大きな特徴があります
1. カプセル化: 情報隠蔽とも呼ばれ、クラスの使用と実装を分離し、一部のインターフェイスとのみを保持することを意味します。メソッド 外部に連絡するか、開発者が使用できるように一部のメソッドのみを公開します。したがって、開発者は、特定の実装プロセスではなく、このクラスの使用方法にのみ注意を払う必要があり、これにより、MVC の分業と連携が実現され、プログラム間の相互依存を効果的に回避し、コード モジュール間の疎結合が実現されます。 2. 継承: サブクラスは親クラスのプロパティとメソッドを自動的に継承し、新しいプロパティとメソッドを追加したり、一部のプロパティとメソッドを書き換えたりできます。継承によりコードの再利用性が向上します。 PHP は単一継承のみをサポートします。つまり、サブクラスは親クラスを 1 つだけ持つことができます。 3. ポリモーフィズム: サブクラスは親クラスからプロパティとメソッドを継承し、一部のメソッドを書き換えます。したがって、複数のサブクラスが同じメソッドを持っていても、それらのサブクラスによってインスタンス化されたオブジェクトが、同じメソッドを呼び出した後にまったく異なる結果を得ることができる、この技術がポリモーフィズムです。ポリモーフィズムはソフトウェアの柔軟性を高めます。
1. 保守が容易ですオブジェクト指向の考え方で設計された可読性の高い構造となっており、継承があるため要件が変わっても保守が容易です。ローカルモジュール内にのみ存在するため、非常に便利で保守コストが低くなります。 2. 高品質設計時には、以前のプロジェクトの現場でテストされた既存のクラスを再利用できるため、ビジネスニーズを満たし、高品質なシステムを実現できます。 3. 高効率ソフトウェアを開発する際には、現実世界の物事を抽象化し、設計の必要に応じてクラスを生成します。この方法を使って問題を解決することは、日常生活や自然な考え方に近いものであり、必然的にソフトウェア開発の効率と品質が向上します。 4. 拡張が容易継承、カプセル化、ポリモーフィズムの特性により、凝集性が高く結合性が低いシステム構造が自然に設計され、システムがより柔軟になり、拡張が容易になります。拡張性があり、コスト効率が高く、低コストです。方法:
1 、array_merge ()2、' '3、array_merge_recursive類似点と相違点:
array_merge 単純なマージ配列array_merge_recursive は 2 つの配列をマージします。配列内にまったく同じデータがある場合は、それらを再帰的にマージします。array_combine と ' ': 2 つの配列をマージし、前者の値がキーとして使用されます新しい配列の
/**
* Tests for file writability
*
* is_writable() returns TRUE on Windows servers when you really can't write to
* the file, based on the read-only attribute. is_writable() is also unreliable
* on Unix servers if safe_mode is on.
*
* @access private
* @return void
*/
if ( ! function_exists('is_really_writable'))
{
function is_really_writable($file){
// If we're on a Unix server with safe_mode off we call is_writable
if (DIRECTORY_SEPARATOR == '/' AND @ini_get("safe_mode") == FALSE){
return is_writable($file);
}
// For windows servers and safe_mode "on" installations we'll actually
// write a file then read it. Bah...
if (is_dir($file)){
$file = rtrim($file, '/').'/'.md5(mt_rand(1,100).mt_rand(1,100));
if (($fp = @fopen($file, FOPEN_WRITE_CREATE)) === FALSE){
return FALSE;
}
fclose($fp);
@chmod($file, DIR_WRITE_MODE);
@unlink($file);
return TRUE;
} elseif ( ! is_file($file) OR ($fp = @fopen($file, FOPEN_WRITE_CREATE)) === FALSE) {
return FALSE;
}
fclose($fp);
return TRUE;
}
}<?php
// 方案一
function getExt1($url){
$arr = parse_url($url);
//Array ( [scheme] => http [host] => www.startphp.cn [path] => /abc/de/fg.php [query] => id=1 )
$file = basename($arr['path']);
$ext = explode('.', $file);
return $ext[count($ext)-1];
}
// 方案二
function getExt2($url){
$url = basename($url);
$pos1 = strpos($url,'.');
$pos2 = strpos($url,'?');
if (strstr($url,'?')) {
return substr($url,$pos1+1,$pos2-$pos1-1);
} else {
return substr($url,$pos1);
}
}
$path = "http://www.startphp.cn/abc/de/fg.php?id=1";
echo getExt1($path);
echo "<br />";
echo getExt2($path);
?>コードセグメント内の指定されたタグの指定された属性値 (大文字と小文字が区別されない、属性名の値と等号の間にスペースがあるなど、属性値が不規則であることを考慮する必要があります) 。）。ここでは、テスト タグの attr 属性値を抽出する必要があることを前提としています。次のように、タグを含む文字列を自分で構築してください (Tencent)
<?php
header("content-type:text/html;charset=utf-8");
function getAttrValue($str,$tagName,$attrName){
$pattern1="/<".$tagName."(s+w+s*=s*(['"]?)([^'"]*)())*s+".$attrName."s*=s*(['"]?)([^'"]*)()(s+w+s*=s*(['"]?)([^'"]*)(9))*s*>/i";
$arr=array();
$re=preg_match($pattern1,$str,$arr);
if($re){
echo"<br/>$arr[6]={$arr[6]}";
}else{
echo"<br/>没找到。";
}
}
// 示例
$str1="<test attr='ddd'>";
getAttrValue($str1,"test","attr");//找test标签中attr属性的值,结果为ddd
$str2="<test2 attr='ddd'attr2='ddd2't1="t1 value"t2='t2 value'>";
getAttrValue($str2,"test2","t1");//找test2标签中t1属性的值，结果为t1 value
?>上传文件的表单使用post方式，并且要在form中添加enctype='multipart/form-data'。
一般可以加上隐藏域：<input type=hidden name='MAX_FILE_SIZE' value=dddddd>，位置在file域前面。
value的值是上传文件的客户端字节限制。可以避免用户在花时间等待上传大文件之后才发现文件过大上传失败的麻烦。
使用file文件域来选择要上传的文件，当点击提交按钮之后，文件会被上传到服务器中的临时目录，在脚本运行结束时会被销毁，所以应该在脚本结束之前，将其移动到服务器上的某个目录下，可以通过函数move_uploaded_file()来移动临时文件，要获取临时文件的信息，使用$_FILES。
限制上传文件大小的因素有：
客户端的隐藏域MAX_FILE_SIZE的数值（可以被绕开）。
服务器端的upload_max_filesize，post_max_size和memory_limit。这几项不能够用脚本来设置。
自定义文件大小限制逻辑。即使服务器的限制是能自己决定，也会有需要个别考虑的情况。所以这个限制方式经常是必要的。
按值传递：函数范围内对值的任何改变在函数外部都会被忽略
按引用传递：函数范围内对值的任何改变在函数外部也能反映出这些修改
优缺点：按值传递时，php必须复制值。特别是对于大型的字符串和对象来说，这将会是一个代价很大的操作。按引用传递则不需要复制值，对于性能提高很有好处。
Varchar是变长，节省存储空间，char是固定长度。查找效率要char型快，因为varchar是非定长，必须先查找长度，然后进行数据的提取，比char定长类型多了一个步骤，所以效率低一些。
1、 静态化指的是页面静态化，也即生成实实在在的静态文件，也即不需要查询数据库就可以直接从文件中获取数据，指的是真静态。
实现方式主要有两种：一种是我们在添加信息入库的时候就生成的静态文件，也称为模板替换技术。一种是用户在访问我们的页面时先判断是否有对应的缓存文件存在，如果存在就读缓存，不存在就读数据库，同时生成缓存文件。
2、伪静态不是真正意义上的静态化，之所以使用伪静态，主要是为了SEO推广，搜索引擎对动态的文件获取难度大，不利于网站的推广。
实习原理是基于Apache或Nginx的rewrite
主要有两种方式：
一种是直接在配置虚拟机的位置配置伪静态，这个每次修改完成后需要重启web服务器。
另一种采用分布式的，可以在网站的根目录上创建.htaccess的文件，在里面配置相应的重写规则来实现伪静态，这种每次重写时不需要重启web服务器，且结构上比较清晰。
1、HTML静态化
效率最高、消耗最小的就是纯静态化的html页面，所以我们尽可能使我们的 网站上的页面采用静态页面来实现，这个最简单的方法其实也是最有效的方法。
2、图片服务器分离
把图片单独存储，尽量减少图片等大流量的开销，可以放在一些相关的平台上，如七牛等
3、数据库集群和库表散列及缓存
数据库的并发连接为100，一台数据库远远不够，可以从读写分离、主从复制，数据库集群方面来着手。另外尽量减少数据库的访问，可以使用缓存数据库如memcache、redis。
4、镜像：
尽量减少下载，可以把不同的请求分发到多个镜像端。
5、负载均衡：
Apache的最大并发连接为1500，只能增加服务器，可以从硬件上着手，如F5服务器。当然硬件的成本比较高，我们往往从软件方面着手。
标量类型声明：PHP 7 中的函数的形参类型声明可以是标量了。在 PHP 5 中只能是类名、接口、array 或者 callable (PHP 5.4，即可以是函数，包括匿名函数)，现在也可以使用 string、int、float和 bool 了。
戻り値の型宣言: 戻り値の型宣言のサポートが追加されました。パラメーターの型宣言と同様に、戻り値の型宣言では関数の戻り値の型を指定します。使用可能な型は、パラメータ宣言で使用できる型と同じです。
NULL マージ演算子: 日常的には三項式と isset() が同時に使用される状況が多いため、変数が存在し、値が NULL でない場合、NULL マージ演算子は独自の値を返します。 . 、それ以外の場合は 2 番目のオペランドを返します。
use の機能強化: 同じ名前空間からインポートされたクラス、関数、定数を、単一の use ステートメントを通じて一度にインポートできるようになりました。匿名クラス: 新しいクラスによる匿名クラスのインスタンス化をサポートしました
ユーザーは、フォーム フィールドに SQL ステートメントを入力する方法を使用して、通常の SQL 実行に影響を与えます。
防止: mysql_real_escape_string() を使用してデータをフィルタリングします。各データが正しいデータ型であるかどうかを手動で確認します。準備されたステートメントとバインド変数を使用します。パラメータ化された SQL: データベースに接続してデータにアクセスするように設計するときに参照します。値またはデータを入力する必要がある場合は、パラメーター (Parameter) を使用して、@ または? を使用して値を指定します。パラメータを表すために。
XSS 攻撃: クロスサイト スクリプティング攻撃。ユーザーが Web サイトに何らかのデータを入力します。これには、クライアント側のスクリプト (通常は JavaScript) が含まれます。フィルタリングせずに別の Web ページにデータを出力すると、このスクリプトが実行されます。
予防策: XSS 攻撃を防ぐには、PHP の htmlentities() 関数を使用してフィルタリングし、ブラウザに出力します。
CSRF: クロスサイト リクエスト フォージェリとは、Web サイトの信頼できるユーザーのように見えるページによって行われるリクエストを指しますが、偽のリクエストです。
予防策: 一般的に、ユーザーが確実にアクセスできるようにします。フォームから取得し、送信するすべてのフォームと一致します。覚えておくべき 2 つのこと: 各セッションの ID を更新したり、ユーザーに SSL を使用したりするなど、ユーザー セッションに適切なセキュリティ対策を講じます。別のワンタイム トークンを生成してフォームに埋め込み、セッション (セッション変数) に保存し、送信時に確認します。たとえば、laravel での _token
コード インジェクション: コード インジェクションは、無効なデータを処理することによってコンピューターの脆弱性を悪用することによって引き起こされます。問題は、通常はファイルのインクルードを介して、誤って任意のコードを実行したときに発生します。コードの書き方が不十分だと、リモート ファイルが組み込まれて実行される可能性があります。多くの PHP 関数と同様に、require には URL またはファイル名を含めることができます。
コード インジェクションを防止し、ユーザー入力をフィルターします。php.ini で、allow_url_fopen とallow_url_include を無効に設定します。これにより、require/include/fopen のリモート ファイルが無効になります。
主に、カプセル化、継承、ポリモーフィズムが含まれます。 4 つの側面の場合は、抽象化を追加します。
カプセル化:
カプセル化は、ソフトウェア コンポーネントが優れたモジュール性を持つことを保証するための基礎です。カプセル化の目標は、高い凝集性、低い結合性を達成し、影響を防ぐことです。プログラムの相互依存関係によって引き起こされる変更の例。
継承:
クラスを定義して実装するときは、既存のクラスに基づいて構築できます。これで定義された内容を使用してください。既存のクラスを独自のコンテンツとして使用し、新しいコンテンツを追加したり、元のメソッドを変更して特別なニーズに適したものにすることができます。これが継承です。継承は、サブクラスが親クラスのデータとメソッドを自動的に共有するメカニズムであり、ソフトウェアの再利用性と拡張性を向上させるクラス間の関係です。
ポリモーフィズム:
ポリモーフィズムとは、プログラム内で定義された参照変数と、参照変数を通じて発行されるメソッド呼び出しによって指定される特定の型を指します。参照変数がどのクラス インスタンス オブジェクトを指すかはプログラムの実行中に決定され、参照変数によって発行されるメソッド呼び出しはどのクラスに実装されるメソッドであり、プログラムの実行中に決定する必要があります。
抽象化:
抽象化とは、いくつかの物事の類似点や共通点を見つけ出し、それらをクラスに分類することです。このクラスでは、これらの類似点のみを考慮します。現在のトピックや目標に無関係な側面は無視し、現在の目標に関連する側面に焦点を当てます。たとえば、アリとゾウを見て、それらがどのように似ているかを想像できる場合、それは抽象化です。
(1) Where 句内: where テーブル間の接続は、他の Where 条件より前に記述する必要があり、最大レコード数を除外できる条件を記述する必要があります。 Where サブ文の最後にあります。最後にあります。
(2) IN を EXISTS に置き換え、NOT IN を NOT EXISTS に置き換えます。
(3) インデックス列での計算の使用を避ける
(4) インデックス列で IS NULL と IS NOT NULL の使用を避ける
(5) クエリを最適化する。テーブル全体のスキャンを回避するには、まず where と order by に関係する列にインデックスを作成することを検討してください。
(6) where 句内のフィールドで null 値の判定を行わないようにしてください。そうしないと、エンジンはインデックスの使用を断念し、テーブル全体のスキャンを実行します。
(7) 回避してください。 where 句を使用すると、句内のフィールドに対して式操作が実行されます。これにより、エンジンはインデックスの使用を断念し、テーブル全体のスキャンを実行します
(1) 効率を向上させるために、適切に設計されたデータベース構造を設計し、部分的なデータの冗長性を許可し、結合クエリを回避するように努めます。
(2) 適切なテーブル フィールドのデータ型とストレージ エンジンを選択し、インデックスを適切に追加します。
(3) mysql マスター/スレーブ レプリケーションの読み取り/書き込み分離を実行します。
(4) データ テーブルを複数のテーブルに分割して、1 つのテーブル内のデータ量を減らし、クエリ速度を向上させます。
(5) Redis、memcached などのキャッシュ機構を追加します。
(6) 頻繁に変更されないページの場合は、静的ページ (ob キャッシュなど) を生成します。
(7) 効率的な SQL を作成します。たとえば、SELECT * FROM TABEL は SELECT field_1, field_2, field_3 FROM TABLE に変更されます。
(1) サーバーが現在のトラフィックをサポートできるかどうかを確認します。
(2) データベースアクセスを最適化します。
(3) 画像のホットリンクなど、外部からのリンクへのアクセス（ホットリンク）を禁止します。
(4) 制御ファイルのダウンロード。
(5) 負荷分散を行い、別のホストを使用してトラフィックをオフロードします。
(6) 閲覧統計ソフトウェアを使用して訪問数を把握し、ターゲットを絞った最適化を実行します。
InnoDB と MyISAM は、MySQL を使用するときに多くの人が最もよく使用する 2 つのテーブル タイプです。どちらのテーブル タイプにも、特定のアプリケーションに応じて、それぞれ長所と短所があります。基本的な違いは、MyISAM タイプはトランザクション処理などの高度な処理をサポートしないのに対し、InnoDB タイプはサポートするということです。 MyISAM タイプのテーブルはパフォーマンスを重視しており、その実行時間は InnoDB タイプよりも高速ですが、トランザクション サポートは提供されていません。一方、InnoDB はトランザクション サポートと外部キーなどの高度なデータベース機能を提供します。
以下は詳細と具体的な実装の違いです:
MyISAM と InnoDB の違いは何ですか?
1. ストレージ構造
MyISAM: 各 MyISAM はディスク上に 3 つのファイルとして保存されます。最初のファイルの名前はテーブルの名前で始まり、拡張子はファイルの種類を示します。 .frm ファイルにはテーブル定義が保存されます。データ ファイルの拡張子は .MYD (MYData) です。インデックスファイルの拡張子は.MYI（MYIndex）です。
InnoDB: すべてのテーブルは同じデータ ファイル (または複数のファイル、または独立したテーブル スペース ファイル) に保存されます。InnoDB テーブルのサイズは、オペレーティング システム ファイルのサイズによってのみ制限されます。通常は 2GB。
2. ストレージスペース
MyISAM: 圧縮可能で、ストレージスペースが小さくなります。静的テーブル (デフォルトですが、データの末尾にスペースがあってはなりません。スペースは削除されることに注意してください)、動的テーブル、圧縮テーブルの 3 つの異なるストレージ形式をサポートします。
InnoDB: より多くのメモリとストレージが必要です。データとインデックスをキャッシュするためにメイン メモリ内に独自の専用バッファ プールを確立します。
3. 移植性、バックアップ、リカバリ
MyISAM: データはファイルの形式で保存されるため、クロスプラットフォームのデータ転送に非常に便利です。バックアップおよびリカバリ中にテーブルに対して個別に操作を実行できます。
InnoDB: 無料のソリューションには、データ ファイルのコピー、binlog のバックアップ、または mysqldump の使用が含まれますが、データ ボリュームが数十 GB に達すると比較的困難になります。
4. トランザクション サポート
MyISAM: パフォーマンスに重点が置かれており、各クエリはアトミックであり、その実行時間は InnoDB タイプよりも高速ですが、トランザクション サポートは提供されません。
InnoDB: トランザクション サポート、外部キー、その他の高度なデータベース機能を提供します。トランザクション (コミット)、ロールバック (ロールバック)、およびクラッシュ回復機能を備えたトランザクションセーフ (ACID 準拠) テーブル。
5. AUTO_INCREMENT
MyISAM: 他のフィールドとの結合インデックスを作成できます。エンジンの自動拡張列はインデックスである必要があります。結合インデックスの場合、自動拡張列は最初の列である必要はありません。前の列に従って並べ替えてから増分できます。
InnoDB: InnoDB には、このフィールドのみを含むインデックスが含まれている必要があります。エンジンの自動拡張列はインデックスである必要があり、それが複合インデックスの場合は、複合インデックスの最初の列でもある必要があります。
6. テーブル ロックの違い
MyISAM: テーブル レベルのロックのみがサポートされています。ユーザーが myisam テーブルを操作するとき、select、update、delete、insert ステートメントは自動的にテーブルをロックします。ロックされている場合、将来テーブルが挿入同時実行性を満たした場合、テーブルの最後に新しいデータを挿入できます。
InnoDB: トランザクションと行レベルのロックのサポートは、innodb の最大の機能です。行ロックにより、マルチユーザーの同時操作のパフォーマンスが大幅に向上します。ただし、InnoDB の行ロックは WHERE の主キーに対してのみ有効であり、主キー以外の WHERE はテーブル全体をロックします。
7. フルテキスト インデックス
MyISAM: FULLTEXT 型のフルテキスト インデックスをサポートします
InnoDB: FULLTEXT 型のフルテキスト インデックスをサポートしませんが、innodb はサポートできますフルテキスト インデックスをサポートするには sphinx プラグインを使用すると、より適切に機能します。
8. テーブルの主キー
MyISAM: インデックスまたは主キーのないテーブルの存在を許可します。インデックスは行が保存されるアドレスです。
InnoDB: 主キーまたは空でない一意のインデックスが設定されていない場合、6 バイトの主キー (ユーザーには見えません) が自動的に生成されます。データは主インデックスの一部であり、追加のインデックスはプライマリ インデックスの値を保存します。
9. テーブル内の特定の行数
MyISAM: テーブル内の総行数を保存します。table; から count(*) を選択すると、その値が取得されます直接出ます。
InnoDB: テーブル内の総行数は保存されません。select count(*) from table を使用すると、テーブル全体を走査することになり、大量のコストがかかります。ただし、wehre 条件を追加した後、 myisam と innodb は同じ方法で処理します。
10. CURD 操作
MyISAM: 多数の SELECT を実行する場合は、MyISAM の方が良い選択です。
InnoDB: データで大量の INSERT または UPDATE が実行される場合は、パフォーマンス上の理由から InnoDB テーブルを使用する必要があります。パフォーマンスの点では InnoDB より DELETE の方が優れていますが、DELETE FROM テーブルの場合、InnoDB はテーブルを再作成せず、行ごとに削除します。InnoDB 上の大量のデータを含むテーブルをクリアしたい場合は、 truncate table コマンドを使用するのが最善です。
11. 外部キー
MyISAM: サポートされていません
InnoDB: サポートされています
上記の分析を通じて、基本的に MyISAM を置き換えるために InnoDB を使用することを検討できます。その理由は、InnoDB にはトランザクション サポート、ストアド プロシージャ、ビュー、行レベルのロックなど、多くの優れた機能があるためです。多くの同時実行の場合、InnoDB のパフォーマンスは間違いなく MyISAM よりも優れていると思います。また、どのテーブルも万能ではなく、ビジネス タイプに応じて適切なテーブル タイプを選択することによってのみ、MySQL のパフォーマンス上の利点を最大化することができます。非常に複雑な Web アプリケーションや重要ではないアプリケーションの場合でも、MyISAM を検討できます。この特定の状況を自分で検討してください。
概要 1:
1 .データ型
Redis には豊富なデータ型があり、セット リストやその他の型をサポートします
memcache は単純なデータ型をサポートし、クライアントが複雑なオブジェクトを独自に処理する必要があります
2. 永続性
redis はデータ ランディング永続ストレージをサポートします
memcache はデータ永続ストレージをサポートしません
3.分散ストレージ
redis はマスター/スレーブ レプリケーション モードをサポートします
memcache は分散に一貫性のあるハッシュを使用できます
値のサイズは異なります
memcache はメモリ キャッシュです。 key 長さは 250 文字未満であり、単一アイテムのストレージは 1M 未満であるため、仮想マシンには適していません。
4. データの一貫性が異なります
redis はシングルスレッド モデルを使用して、データが順番に送信されることを保証します。
Memcache はデータの一貫性を確保するために cas を使用する必要があります。 CAS (Check and Set) は、同時実行の一貫性を確保するためのメカニズムであり、「楽観的ロック」のカテゴリに属します。原理は非常に単純です: バージョン番号を取得し、操作し、バージョン番号を比較し、一貫性がある場合は操作し、そうでない場合は操作します。操作を放棄しないでください
5.cpu 使用率
Redis シングルスレッド モデルは 1 つの CPU のみを使用し、複数の Redis プロセスを開くことができます
要約 2:
##1. Redis では、すべてのデータが常にメモリに保存されるわけではなく、これが Memcached と比較した最大の違いです。
2.Redis は、単純な k/v 型データをサポートするだけでなく、リスト、セット、ハッシュなどのデータ構造のストレージも提供します。
3.Redis はデータ バックアップ、つまりマスター/スレーブ モードでのデータ バックアップをサポートしています。
4.Redis はデータ永続性をサポートしています。これにより、データをディスク上のメモリに保持し、再起動時に再度ロードして使用できます。
#個人的に最も本質的な違いは、Redis は多くの面でデータベースの特徴を備えている、つまりデータベース システムであるのに対し、Memcached は単なる単純な K/V キャッシュであるということだと思いますまとめ 3:
redis と memecache の違い:1. 保存方法:
memecache はすべてのデータを保存します これはメモリに保存され、停電後にハングアップします。データはメモリ サイズを超えることはできませんredis の一部はハードディスクに保存され、永続性が確保されます。データ。2. データ サポートの種類:
redis は memecache よりも多くのデータ サポートを備えています。3. 基礎となるモデルは異なります:
redis の新しいバージョンは、一般的なシステムがシステム関数を呼び出すため、VM メカニズムを直接構築します。一定時間移動してリクエストしてください。4. さまざまなオペレーティング環境:
redis は現在 Linux のみを正式にサポートしているため、他のシステムをサポートする必要がなく、より適切に管理できるようになります。システム環境を最適化するために使用されましたが、後に Microsoft のチームがそのパッチを作成しました。ただし、トランクには配置されませんmemcacheはキャッシュとしてのみ使用できます。cacheredisの中身はMongoDBと同様に実装できます。その後、redisも使用できますキャッシュとして使用し、マスター/スレーブを設定できます。1）单一列表实现：队列正常的操作是 左进右出（lpush,rpop）为了先处理高优先级任务，在遇到高级别任务时，可以直接插队，直接放入队列头部（rpush），这样，从队列头部（右侧）获取任务时，取到的就是高优先级的任务（rpop）
2）使用两个队列，一个普通队列，一个高级队列，针对任务的级别放入不同的队列，获取任务时也很简单，redis的BRPOP命令可以按顺序从多个队列中取值，BRPOP会按照给出的 key 顺序查看，并在找到的第一个非空 list 的尾部弹出一个元素，redis> BRPOP list1 list2 0
list1 做为高优先级任务队列 list2 做为普通任务队列 这样就实现了先处理高优先级任务，当没有高优先级任务时，就去获取普通任务 方式1 最简单，但实际应用比较局限，方式3可以实现复杂优先级，但实现比较复杂，不利于维护 方式2 是推荐用法，实际应用最为合适
答：其实redis是不会存在并发问题的，因为他是单进程的，再多的命令都是一个接一个地执行的。我们使用的时候，可能会出现并发问题，比如获得和设定这一对。Redis的为什么 有高并发问题？Redis的出身决定等
Redis是一种单线程机制的nosql数据库，基于key-value，数据可持久化落盘。由于单线程所以redis本身并没有锁的概念，多个客户端连接并不存在竞争关系，但是利用jedis等客户端对redis进行并发访问时会出现问题。发生连接超时、数据转换错误、阻塞、客户端关闭连接等问题，这些问题均是由于客户端连接混乱造成。
同时，单线程的天性决定，高并发对同一个键的操作会排队处理，如果并发量很大，可能造成后来的请求超时。
在远程访问redis的时候，因为网络等原因造成高并发访问延迟返回的问题。
解决办法
在客户端将连接进行池化，同时对客户端读写Redis操作采用内部锁synchronized。
服务器角度，利用setnx变向实现锁机制。
答:因为秒杀的一瞬间，并发非常大，如果同时请求数据库，会导致数据库的压力非常大，导致数据库的性能急剧下降，更严重的可能会导致数据库服务器宕机。
这时候一般采用内存高速缓存数据库redis来实现的,redis是非关系型数据库，redis是单线程的，通过redis的队列可以完成秒杀过程。
答:当用户第一次访问应用系统的时候，因为还没有登录，会被引导到认证系统中进行登录；根据用户提供的登录信息，认证系统进行身份校验，如果通过校验，应该返回给用户一个认证的凭据－－ticket；
用户再访问别的应用的时候，就会将这个ticket带上，作为自己认证的凭据，应用系统接受到请求之后会把 ticket送到认证系统进行校验，检查ticket的合法性。如果通过校验，用户就可以在不用再次登录的情况下访问应用系统2和应用系统3了。
实现主要技术点：
1、两个站点共用一个数据验证系统
2、主要通过跨域请求的方式来实现验证及session处理。
答: 抛出异常:使用try…catch，异常的代码放在try代码块内，如果没有触发异常，则代码继续执行，如果异常被触发，就会 抛出一个异常。Catch代码块捕获异常，并创建一个包含异常信息的对象。$e->getMessage()，输出异常的错误信息。
解决异常:使用set_error_handler函数获取异常(也可以使用try()和catch()函数),然后使用set_exception_handler()函数设置默认的异常处理程序,register_shutdown_function()函数来执行,执行机制是,php要把调入的函数调入到内存,当页面所有的php语句都执行完成时,再调用此函数
1.首先创建一张用户表:id name auto(保存格式为:控制器-方法)
2.然后在后台中创建一个基类控制器,控制器里封装一个构造方法,当用户登陆成功后,使用TP框架中封装好的session函数获取保存在服务器中的session id,然后实例化模型,通过用户id获取保存在数据表中的auth数据,使用explode函数分割获取到的数据,并使用一个数组保存起来,然后使用TP框架中封装好的常量获取当前控制器和方法,然后把他们组装成字符串,使用in_array函数进行判断该数组中是否含有当前获取到的控制器和方法,如果没有,就提示该用户没有权限,如果有就进行下一步操作
回答: この問題は、開発中に遭遇した困難でした。売れすぎの主な理由は、注文にありました。
第一案: ご注文前に販促品の数量が足りているか判断し、足りない場合はご注文をお断りさせていただきます。在庫を変更する場合は条件を追加し、その際、ストレステストにはabを使用しますが、同時実行数が500を超え、訪問数が2,000を超えると、やはり売れすぎが発生します。それで私たちはそれを否定しました。
2 番目の解決策: mysql トランザクションと排他ロックを使用して問題を解決します。まず、データベースのストレージ エンジンを innoDB として選択します。これは排他ロックを使用して実装されます。最初に、共有ロックをテストしました。売られ過ぎの状況が依然として発生していることがわかります。 1 つの問題は、高同時実行テストを実行すると、データベースのパフォーマンスに大きな影響を及ぼし、データベースに大きな負荷がかかるため、最終的には拒否されたことです。
3 番目のオプション: ファイル ロックの実装を使用します。ユーザーが販促品を掴むと、最初にファイルロックがかかり他のユーザーの立ち入りが禁止され、販促品を掴んだ後はファイルロックが解除され、他のユーザーが操作できるようになります。これにより、売られすぎの問題は解決できますが、ファイルの I/O オーバーヘッドが大量に発生します。
最後に、redis キューを使用して実装しました。プロモーションされる製品の数はキュー内の Redis に保存され、ユーザーがプロモーション製品を取得するたびに、製品が売れすぎないようにキューからデータが削除されます。これは操作が非常に便利で、非常に効率的であり、最終的にこの方法を採用して、
回答:最近では、急ぎ購入やフラッシュセールが行われています。これは非常に一般的なアプリケーション シナリオであり、解決する必要がある主な問題が 2 つあります。
2 番目の質問は、redis キューを使用して完了し、販売する商品を即座にキューに入れることができます。ポップ操作はアトミックであるため、多くのユーザーが同時に到着した場合でも、それらは実行されます。シーケンス、ファイル ロック トランザクションとトランザクションのパフォーマンスは、同時実行性が高いと急速に低下します。もちろん、スナップアップ ページを静的にすることや、ajax を介してインターフェイスを呼び出すなど、他の側面も考慮する必要があります。ユーザーが複数回スナップアップを行う場合、キューキュー、スナップアップ結果キュー、インベントリキューを追加する必要があります。
回答: 低コスト、高性能、高スケーラビリティの観点からは、次の解決策があります:
実際、最も効率的で消費量が最も少ないのは純粋に静的な HTML ページであることは誰もが知っているため、Web サイトのページには静的ページを使用するよう最善を尽くしています。この最も単純な方法が、実際には最も効果的な方法です。
2. 画像サーバーの分離
画像などの大規模なトラフィックのオーバーヘッドを最小限に抑えるために、画像を個別に保存します。ブルライディングなどの関連プラットフォームに配置できます。
3. データベース クラスターとデータベース テーブルのハッシュとキャッシュ
データベースの同時接続は 100 です。1 つのデータベースでは十分ではありません。レプリケーションとデータベースのクラスタリングから始めましょう。さらに、データベース アクセスを最小限に抑えるために、memcache や redis などのキャッシュ データベースを使用できます。
4. ミラー:
ダウンロードをできるだけ減らし、さまざまなリクエストを複数のミラーに分散します。
5. 負荷分散:
Apache の最大同時接続数は 1500 です。追加できるのはサーバーのみであり、F5 サーバーなどのハードウェアから開始できます。もちろん、ハードウェアのコストは比較的高いため、ソフトウェア側から開始することがよくあります。
負荷分散は、既存のネットワーク構造に基づいて構築されています。ネットワーク デバイスとサーバーの帯域幅を拡張し、スループットを向上させ、ネットワーク データ処理機能を強化するための、安価で効果的かつ透過的な方法を提供します。ネットワークの柔軟性とネットワークの柔軟性を向上させることができます。可用性。現在、最も広く使用されている負荷分散ソフトウェアは、Nginx、LVS、および HAProxy です。
3 つのタイプのそれぞれの長所と短所について説明します:
Nginx の利点は次のとおりです: ネットワークの 7 番目の層で作業すると、ドメイン名やディレクトリ構造などの http アプリケーションの転用戦略を作成できます。その通常のルールは HAProxy よりも強力で柔軟であり、これが主な理由の 1 つです。なぜ現在広く普及しているのか、これだけを見ても Nginx は LVS よりもはるかに多くの状況で使用できます。
Nginx はネットワークの安定性にほとんど依存しません。理論的には、ping が可能である限り、ロード機能を実行できます。これも利点の 1 つです。反対に、LVS はネットワークの安定性に大きく依存しており、私はそれを深く理解しています。
Nginx はインストールと構成が比較的簡単で、テストがより便利で、基本的にエラーをログに出力できます。 LVS の構成とテストには比較的長い時間がかかり、LVS はネットワークに大きく依存します。
高い負荷圧力に耐えることができ、安定しているため、ハードウェアが悪くなければ、一般に数万の同時実行をサポートでき、負荷度は LVS よりも比較的小さいです。
Nginx は、Web ページを処理するサーバーから返されるステータス コードやタイムアウトなどの内部サーバー障害をポート経由で検出でき、エラーを返すリクエストを別のノードに再送信します。検出する URL をサポートできません。たとえば、ユーザーがファイルをアップロードしていて、アップロード処理中にアップロードを処理するノードが失敗した場合、Nginx は再処理のためにアップロードを別のサーバーに切り替え、LVS は直接切断されます。重要なファイルを保存すると、ユーザーが不満を抱く可能性があります。
Nginx は、優れたロード バランサー/リバース プロキシ ソフトウェアであるだけでなく、強力な Web アプリケーション サーバーでもあります。 LNMP は近年非常に人気のある Web アーキテクチャでもあり、高トラフィック環境での安定性も非常に優れています。
Nginx は Web リバース アクセラレーション キャッシュとしてますます成熟しており、従来の Squid サーバーよりも高速なので、リバース プロキシ アクセラレータとして使用することを検討できます。
Nginx は中レベルのリバース プロキシとして使用できます。このレベルでは、Nginx には基本的にライバルがいません。Nginx と比較できるのは lighttpd だけです。ただし、lighttpd はまだ完全な機能を備えていません。 Nginx ですが、構成はそれほど良くありませんが、明確で読みやすく、コミュニティ情報は Nginx よりもはるかに活発ではありません。
Nginx は静的 Web ページおよび画像サーバーとしても使用でき、この分野でのパフォーマンスは比類のありません。 Nginx コミュニティも非常に活発で、多くのサードパーティ モジュールがあります。
Nginx の欠点は次のとおりです:
Nginx は http、https、および電子メール プロトコルのみをサポートできるため、適用範囲が狭くなります。
バックエンド サーバーのヘルス チェックは、ポートを介した検出のみをサポートし、URL を介した検出はサポートしません。セッションの直接保持はサポートされていませんが、ip_hash を通じて解決できます。
LVS: Linux カーネル クラスターを使用して、優れたスケーラビリティ (Scalability)、信頼性 (Reliability)、および管理容易性 (Manageability) を備えた高性能、高可用性の負荷分散サーバーを実装します。
LVS の利点は次のとおりです:
LVS は、強力な負荷耐性があり、ネットワークの第 4 層上で分散のみに動作し、トラフィックの生成はありません。また、これにより、負荷分散ソフトウェアの中で最も優れたパフォーマンスが得られ、メモリと CPU リソースの消費量が比較的少ないことが決まります。
設定可能性が比較的低いことが短所でもあり長所でもありますが、過剰に設定できるものがないため、あまり多くの連絡を必要とせず、人的エラーの可能性が大幅に減少します。
負荷耐性が強く、LVS Keepalived などの完全なデュアルマシン ホット バックアップ ソリューションを備えているため、安定して動作しますが、プロジェクトの実装で最も使用しているのは LVS/DR Keepalived です。
トラフィックなし、LVS はリクエストを分散するだけであり、トラフィックはそれ自体から送信されません。これにより、バランサー IO のパフォーマンスが大量のトラフィックによる影響を受けなくなります。
適用範囲は比較的広く、LVS はレイヤー 4 で動作するため、http、データベース、オンライン チャット ルームなど、ほぼすべてのアプリケーションの負荷分散が可能です。
LVS の欠点は次のとおりです:
ソフトウェア自体は正規表現処理をサポートしておらず、動的と静的を区別できません。現在、多くの Web サイトでこの点に関する強いニーズがあります。 、これが Nginx/HAProxy Keepalived の利点です。
Web サイト アプリケーションが比較的大規模な場合、LVS/DR Keepalived の実装はより複雑になります。特に、その背後に Windows Server マシンがある場合、実装、構成、メンテナンスのプロセスはより複雑になります。 、 、Nginx/HAProxy Keepalived ははるかに簡単です。
HAProxy の特徴は次のとおりです。
HAProxy は仮想ホストもサポートします。
HAProxy の利点は、セッション保持や Cookie ガイダンスのサポートなど、Nginx の欠点の一部を補うことができ、指定された URL を取得することによるバックエンド サーバーのステータスの検出もサポートします。
HAProxy は LVS に似ていますが、単なる負荷分散ソフトウェアです。純粋に効率の観点から見ると、HAProxy は Nginx よりも負荷分散速度が優れており、同時処理においても Nginx よりも優れています。
HAProxy は、TCP プロトコルのロード バランシング転送をサポートしています。MySQL 読み取りのロード バランシング、バックエンド MySQL ノードの検出とロード バランシングが可能です。LVS Keepalived を使用して、MySQL マスターとスレーブのロード バランシングを行うことができます。
HAProxy の負荷分散戦略は多数あります。HAProxy の負荷分散アルゴリズムには現在、次の 8 種類があります:
① ラウンドロビン、これは単純なポーリングを意味します。これについては多くは言いません。これは次のとおりです。ロード バランシングの基本。これらはすべて利用可能です。
② static-rr、重みに基づいて注意することが推奨されることを示します。
③ minimumconn、接続が最も少ないことを示します。 1 つは最初に処理されるため、注意することをお勧めします;
④ ソース, リクエストの送信元 IP に基づいて示します. これは Nginx の IP_hash メカニズムに似ています. セッションの問題を解決する方法として使用されます.注意することをお勧めします;
⑤ ri、リクエストされた URI を表します;
⑥ rl_param、リクエストされた URL パラメータを表します 'balance url_param' には URL パラメータ名が必要です;
⑦ hdr(name)、Lock each を表しますHTTP リクエスト ヘッダーに基づく HTTP リクエスト;
⑧ rdp-cookie(name)、各 TCP リクエストが cookie(name) に基づいてロックおよびハッシュされていることを示します。
Nginx と LVS の比較の概要:
Nginx はネットワークのレイヤー 7 で動作するため、次のような http アプリケーション自体の迂回戦略を実装できます。一方、LVS にはそのような機能がないため、これだけで Nginx は LVS よりもはるかに多くの場面で使用できますが、Nginx のこれらの便利な機能により、LVS よりも調整が容易になります。触ったり触ったり触ったりすることがよくありますが、触りすぎると人間の問題が発生する可能性が高くなります。
Nginx はネットワークの安定性への依存度が低いです。理論上、ping が成功し、Web ページへのアクセスが正常である限り、Nginx は接続できます。これが Nginx の大きな利点です。 Nginx は内部ネットワークと外部ネットワークも区別できます。内部ネットワークと外部ネットワークの両方を持つノードの場合、バックアップ回線を持つ 1 台のマシンと同等ですが、LVS はネットワーク環境により大きく依存します。現在、サーバーは同じネットワークセグメントとLVSはダイレクトモードを使用してオフロードを行うため、効果はより確実です。
また、LVS が Visual IP として使用するには、ホスティング プロバイダーから少なくとも 1 つ以上の IP を申請する必要があることにも注意してください。LVS 自身の IP を VIP として使用することはできないようです。優れた LVS 管理者になるには、ネットワーク通信について多くの知識をフォローアップして学ぶ必要があります。ネットワーク通信はもはや HTTP ほど単純ではありません。
Nginx はインストールと設定が比較的簡単で、基本的にエラーをログに出力できるため、テストにも非常に便利です。 LVS のインストール、構成、およびテストには比較的長い時間がかかります。LVS はネットワークに大きく依存しています。多くの場合、構成が正常に失敗するのは、構成の問題ではなくネットワークの問題が原因です。問題がある場合は、大きな問題が発生します。解決するのはさらに面倒です。
Nginx も高負荷に耐えることができ、安定していますが、負荷と安定性は LVS よりも劣ります。いくつかのレベルがあります: Nginx はすべてのトラフィックを処理するため、マシンの IO と構成によって制限されます。独自のバグは次のとおりです。解決するのはまだ難しいため、回避されました。
Nginx は、Web ページを処理するサーバーから返されるステータス コードやタイムアウトなどの内部サーバー障害を検出でき、エラーを返すリクエストを別のノードに再送信します。現在、LVS の ldirectd はサーバーの内部状態の監視もサポートしていますが、LVS の原理によりリクエストを再送信することはできません。たとえば、ユーザーがファイルをアップロードしていて、アップロード処理中にアップロードを処理するノードが失敗した場合、Nginx は再処理のためにアップロードを別のサーバーに切り替え、LVS は直接切断されます。重要なファイルがある場合、ユーザーはこれに煩わされる可能性があります。
Nginx のリクエストの非同期処理は、ノード サーバーの負荷を軽減するのに役立ちます。Apache を使用して外部サービスに直接サービスを提供する場合、ナローバンド リンクが多数ある場合、Apache サーバーは大量のメモリを占有してしまうため、もう 1 つの Nginx を Apache として使用する プロキシを使用すると、これらの狭帯域リンクが Nginx によってブロックされ、大量のリクエストが Apache に蓄積されなくなり、リソース使用量が大幅に削減されます。この点では Squid を使用しても同じ効果があり、Squid 自体がキャッシュしないように設定されている場合でも、Apache にとっては依然として大きな助けとなります。
Nginx は http、https、および電子メールをサポートできます (電子メール機能はあまり一般的には使用されません)。この点で、LVS は Nginx よりも多くのアプリケーションをサポートします。使用に関しては、一般にフロントエンドで採用される戦略は LVS である必要があり、つまり DNS の方向は LVS イコライザーである必要があり、LVS の利点はこのタスクに非常に適しています。
重要 IP アドレス (データベース IP、Web サービス サーバー IP など) は、LVS によって管理するのが最適です。これらの IP アドレスは、時間の経過とともにますます広く使用されるようになります。IP アドレスを変更すると、誤動作する可能性があります。が続きます。したがって、これらの重要な IP をホスティングのために LVS に引き渡すことが最も安全ですが、そうすることの唯一の欠点は、必要な VIP の数が多くなるということです。
Nginx は LVS ノード マシンとして使用でき、第一に Nginx の機能を活用することができ、第二に Nginx のパフォーマンスを活用することができます。もちろん、このレベルでは Squid を直接使用することもできますが、Squid は Nginx に比べて機能が非常に弱く、パフォーマンスも Nginx に劣ります。
Nginx は中間レベルのプロキシとしても使用できます。このレベルでは、Nginx には基本的にライバルがいません。Nginx を揺るがすことができるのは lighttpd だけです。ただし、lighttpd は現在、Nginx の完全な機能を備えていません。 、構成はそれほど明確ではなく、読みやすいものではありません。さらに、中間レベルのエージェントの IP も重要であるため、中間レベルのエージェントにも VIP と LVS を持たせるのが最も完璧なソリューションです。
特定のアプリケーションを詳細に分析する必要があります。比較的小規模な Web サイト (1 日の PV が 1,000 万未満) であれば、Nginx を使用しても問題ありません。マシンの数が多い場合は、DNS を使用できます。 LVS はまだ多くのマシンを消費しますが、大規模な Web サイトや重要なサービスの場合、マシンが問題にならない場合は、LVS の使用を検討する必要があります。
推奨学習: 「PHP ビデオ チュートリアル 」
以上が【吐血】転職に役立つPHPコア技術に関する面接での質問28選！の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
