#関連おすすめ: 「

2022 PHP 面接質(zhì)問(wèn)まとめ (集)」

1. 自己紹介をお願(yuàn)いします?

答え: 私の名前は xxx です。北京出身で、20xx 年に xx 大學(xué)のコンピュータ學(xué)科を卒業(yè)し、その後武漢で PHP 開(kāi)発に従事しました。 x 年。會(huì)社はアウトソーシング會(huì)社で、主に WeChat の開(kāi)発、パブリック アカウントのプロモーション、モール、フォーラムの開(kāi)発に従事しています。

#2 社內(nèi)でどのようなプロジェクトを擔(dān)當(dāng)していますか?

回答 : 當(dāng)社はアウトソーシング會(huì)社なので、1 つのプロジェクトだけを行うことは不可能です。フォーラム、WeChat、ショッピング モールをすべて実行しています。

3. なぜ深センに來(lái)たのですか?

答え: 私の兄がここにいるので、両親もお互いを大切にしたいと思っています。そして深センは初めてです。層都市であり、テクノロジーは広西チワン族自治區(qū)よりも最先端です。

4 武漢ではどのようなフロントエンドとバックエンドのフレームワークが使用されていますか?

回答: 回答お住まいの地域に応じて

#5.どのようなモジュールを?qū)g行しましたか?

回答: ログイン登録、商品管理、ショッピング カート モジュール、注文管理

6. あなたの會(huì)社ではどのようなフレームワークを使用していますか?

回答: 弊社では、mysql apache php を使用して開(kāi)発された TP フレームワークを採(cǎi)用しています。これは、TP フレームワークが無(wú)料のオープンソースであるためです。軽量の php 開(kāi)発フレームワークで、中國(guó)人自身が開(kāi)発したもので、國(guó)內(nèi)でもよく使われています。各種資料も比較的充実しています。

7.mvc とは何ですか?

回答: mvc は主に 3 つの部分に分かれています。m(モデル) はモデルであり、v (ビュー) はデータの操作を擔(dān)當(dāng)します。ビューはフロントエンドとバックエンドの表示を擔(dān)當(dāng)し、コントローラーである c (コントローラー) はビジネス ロジックを擔(dān)當(dāng)します。クライアント リクエスト プロジェクト コントローラー。実行中にデータが必要な場(chǎng)合、コントローラーはモデルからデータを取得し、ビューを通じて取得したデータを表示します。

8. oop とは何ですか?

答え: oop はオブジェクト指向プログラミングです。 OOP の基本原理は、コンピュータ プログラムがサブルーチンとして機(jī)能できる?yún)g一のユニットまたはオブジェクトで構(gòu)成されることです。

OOP具有三大特點(diǎn)

1. カプセル化: 情報(bào)隠蔽とも呼ばれ、クラスの使用と実裝を分離し、一部のインターフェイスとメソッドのみを外部と接続するか、開(kāi)発者が使用できるように一部のメソッドのみを公開(kāi)することを意味します。 。したがって、開(kāi)発者は、その特定の実裝プロセスではなく、このクラスがどのように使用されるかにのみ注意する必要があります。これにより、MVC の分業(yè)と連攜が実現(xiàn)され、プログラム間の相互依存が効果的に回避され、コード モジュール間の疎結(jié)合が実現(xiàn)されます。

2. 継承: サブクラスは親クラスのプロパティとメソッドを自動(dòng)的に継承し、新しいプロパティとメソッドを追加したり、一部のプロパティとメソッドを書(shū)き換えたりできます。継承によりコードの再利用性が向上します。 PHP は単一継承のみをサポートします。つまり、サブクラスは親クラスを 1 つだけ持つことができます。

3. ポリモーフィズム: サブクラスは親クラスからプロパティとメソッドを継承し、一部のメソッドを書(shū)き換えます。したがって、複數(shù)のサブクラスが同じメソッドを持っていても、これらのサブクラスによってインスタンス化されたオブジェクトは、これらの同じメソッドを呼び出した後にまったく異なる結(jié)果を取得する可能性があります。このテクノロジはポリモーフィズムです。ポリモーフィズムによりソフトウェアの柔軟性が向上します。

1. 保守が容易

オブジェクト指向の考え方で設(shè)計(jì)された可読性の高い構(gòu)造のため、要件が変わっても保守はローカルのみで済みます。モジュール化されているため、メンテナンスが非常に便利でコストも低くなります。

2. 高品質(zhì)

設(shè)計(jì)時(shí)には、以前のプロジェクトの現(xiàn)場(chǎng)でテストされた既存のクラスを再利用できるため、システムはビジネス ニーズを満たし、高品質(zhì)になります。

3. 高効率

ソフトウェア開(kāi)発では、現(xiàn)実世界のものが抽象化され、設(shè)計(jì)のニーズに応じてクラスが生成されます。この方法を使って問(wèn)題を解決することは、日常生活や自然な考え方に近いものであり、必然的にソフトウェア開(kāi)発の効率と品質(zhì)が向上します。

4. 拡張が容易

継承、カプセル化、ポリモーフィズムの特性により、結(jié)合度が高く、結(jié)合度が低いシステム構(gòu)造が自然に設(shè)計(jì)され、システムがより柔軟になり、拡張が容易になります。拡張性があり、コスト効率が低くなります。

9. Smarty とは何ですか?またその機(jī)能は何ですか?

回答 1: Smarty は PHP で書(shū)かれたテンプレート エンジンで、現(xiàn)在最も有名な PHP テンプレート エンジンです。 1 つ目は業(yè)界です。ロジック コードと外部ディスプレイを分離し、混合した PHP ロジック コードを HTML コードから分離するための管理と使用が簡(jiǎn)単な方法を提供します。

回答 2: Smarty は、PHP で最も有名なエンジン フレームワークの 1 つです。當(dāng)社では、Smarty テンプレートをカプセル化した TP フレームワークを使用しているため、単獨(dú)では使用されていません。

回答 3: Smarty はテンプレート エンジンです。最も明らかなのは、テンプレートをキャッシュすることです。一般的に、テンプレートは靜的なページを作成し、その中のいくつかの動(dòng)的部分を區(qū)切り文字で切り取り、PHP でテンプレート ファイルを開(kāi)き、區(qū)切り文字內(nèi)の値を置き換えて出力することで、 PHPLib のテンプレート部分を見(jiàn)てください。

而smarty設(shè)定了緩存參數(shù)以后，第一次運(yùn)行時(shí)候會(huì)把模板打開(kāi)，在php替換里面值的時(shí)候把讀取的html和php部分重新生成一個(gè)臨時(shí)的php文件，這樣就省去了每次打開(kāi)都重新讀取html了。如果修改了模板，只要重新刷下就行了。

10.TP框架有哪些優(yōu)點(diǎn)?

答:TP框架是我們中國(guó)人自己開(kāi)發(fā)的框架,各種資料比較齊全,國(guó)內(nèi)用的比較多,比較簡(jiǎn)單和方便,而且是免費(fèi)開(kāi)源的

11.TP的特性有哪些?

1.多表查詢非常方便,在model中幾句代碼就可以完成對(duì)多表的關(guān)聯(lián)操作
2.融合了smarty模板,使前后臺(tái)分離
3.支持多種緩存技術(shù),尤其對(duì)memcache技術(shù)支持非常好
4.命名規(guī)范,模型,視圖,控制器嚴(yán)格遵循命名規(guī)則,通過(guò)命名一一對(duì)應(yīng)
5.支持多種url模式
6.內(nèi)置ajax返回方法,包括xml,json,html等
7.支持應(yīng)用擴(kuò)展,類庫(kù)擴(kuò)展,驅(qū)動(dòng)擴(kuò)展等

12.TP框架中的大字母函數(shù)?

U:對(duì)url的組裝
A:內(nèi)部實(shí)例化控制器
S:緩存處理
R:調(diào)用某個(gè)控制器的操作方法
D:實(shí)例化自定義模型類
M:實(shí)例化基礎(chǔ)模型類
I:獲取參數(shù)
L:設(shè)置或者獲取當(dāng)前語(yǔ)言
C:設(shè)置或獲取,保存配置

13.請(qǐng)介紹一下laravel框架?

答: laravel框架的設(shè)計(jì)思想比較先進(jìn),非常適合應(yīng)用各種開(kāi)發(fā)模式,作為一個(gè)框架,它為你準(zhǔn)備好了一切,composer是php的未來(lái),沒(méi)有composer,php肯定要走向沒(méi)落

laravel框架最大的特點(diǎn)和優(yōu)秀之處就是集合了php比較新的特點(diǎn),以及各種各樣的設(shè)計(jì)模式,Ioc模式,依賴注入等

14.laravel有那些特點(diǎn)?

回答一:

1.強(qiáng)大的rest router:用簡(jiǎn)單的回調(diào)函數(shù)就可以調(diào)用,快速綁定controller和router
2.artisan:命令行工具,很多手動(dòng)的工作都自動(dòng)化
3.可繼承的模板,簡(jiǎn)化view的開(kāi)發(fā)和管理
4.blade模板:渲染速度更快
5.ORM操作數(shù)據(jù)庫(kù)
6.migration:管理數(shù)據(jù)庫(kù)和版本控制
7.測(cè)試功能也很強(qiáng)大
8.composer也是亮點(diǎn)

回答二: laravel框架引入了門(mén)面,依賴注入,Ioc模式,以及各種各樣的設(shè)計(jì)模式等

15.請(qǐng)簡(jiǎn)述一下數(shù)據(jù)庫(kù)的優(yōu)化?

答:數(shù)據(jù)庫(kù)的優(yōu)化可以從四個(gè)方面來(lái)優(yōu)化:

1.從結(jié)構(gòu)層: web服務(wù)器采用負(fù)載均衡服務(wù)器,mysql服務(wù)器采用主從復(fù)制,讀寫(xiě)分離
2.從儲(chǔ)存層: 采用合適的存儲(chǔ)引擎,采用三范式
3.從設(shè)計(jì)層: 采用分區(qū)分表,索引,表的字段采用合適的字段屬性,適當(dāng)?shù)牟捎媚娣妒?開(kāi)啟mysql緩存
4.sql語(yǔ)句層:結(jié)果一樣的情況下,采用效率高,速度快節(jié)省資源的sql語(yǔ)句執(zhí)行

16.如何解決異常處理?

答: 拋出異常:使用try…catch，異常的代碼放在try代碼塊內(nèi)，如果沒(méi)有觸發(fā)異常，則代碼繼續(xù)執(zhí)行，如果異常被觸發(fā)，就會(huì) 拋出一個(gè)異常。Catch代碼塊捕獲異常，并創(chuàng)建一個(gè)包含異常信息的對(duì)象。$e->getMessage()，輸出異常的錯(cuò)誤信息。

解決異常:使用set_error_handler函數(shù)獲取異常(也可以使用try()和catch()函數(shù)),然后使用set_exception_handler()函數(shù)設(shè)置默認(rèn)的異常處理程序,register_shutdown_function()函數(shù)來(lái)執(zhí)行,執(zhí)行機(jī)制是,php要把調(diào)入的函數(shù)調(diào)入到內(nèi)存,當(dāng)頁(yè)面所有的php語(yǔ)句都執(zhí)行完成時(shí),再調(diào)用此函數(shù)

17.前端?

答:我在工作中處理前端的功能，一般就是用ajax向后臺(tái)請(qǐng)求數(shù)據(jù)，然后返回?cái)?shù)據(jù)在前臺(tái)頁(yè)面中顯示出來(lái)。我從來(lái)沒(méi)有獨(dú)立的完整的將html和css樣式都一個(gè)人完成，如果公司實(shí)在有這樣的需求的話，我可能會(huì)找一些前臺(tái)的模板或者說(shuō)是前端的框架，比如說(shuō)h—ui等等

18.權(quán)限管理(RBAC)的實(shí)現(xiàn)?

1.首先創(chuàng)建一張用戶表:id name auto(保存格式為:控制器-方法)

2.然后在后臺(tái)中創(chuàng)建一個(gè)基類控制器,控制器里封裝一個(gè)構(gòu)造方法,當(dāng)用戶登陸成功后,使用TP框架中封裝好的session函數(shù)獲取保存在服務(wù)器中的session id,然后實(shí)例化模型,通過(guò)用戶id獲取保存在數(shù)據(jù)表中的auth數(shù)據(jù),使用explode函數(shù)分割獲取到的數(shù)據(jù),并使用一個(gè)數(shù)組保存起來(lái),然后使用TP框架中封裝好的常量獲取當(dāng)前控制器和方法,然后把他們組裝成字符串,使用in_array函數(shù)進(jìn)行判斷該數(shù)組中是否含有當(dāng)前獲取到的控制器和方法,如果沒(méi)有,就提示該用戶沒(méi)有權(quán)限,如果有就進(jìn)行下一步操作

19.支付功能的實(shí)現(xiàn)?

答:

20.怎么保證促銷商品不會(huì)超賣?

答:這個(gè)問(wèn)題是我們當(dāng)時(shí)開(kāi)發(fā)時(shí)遇到的一個(gè)難點(diǎn)，超賣的原因主要是下的訂單的數(shù)目和我們要促銷的商品的數(shù)目不一致導(dǎo)致的，每次總是訂單的數(shù)比我們的促銷商品的數(shù)目要多，當(dāng)時(shí)我們的小組討論了好久，給出了好幾個(gè)方案來(lái)實(shí)現(xiàn)：

第一種方案：在每次下訂單前我們判斷促銷商品的數(shù)量夠不夠，不夠不允許下訂單，更改庫(kù)存量時(shí)加上一個(gè)條件，只更改商品庫(kù)存大于0的商品的庫(kù)存，當(dāng)時(shí)我們使用ab進(jìn)行壓力測(cè)試，當(dāng)并發(fā)超過(guò)500，訪問(wèn)量超過(guò)2000時(shí)，還是會(huì)出現(xiàn)超賣現(xiàn)象。所以被我們否定了。

第二種方案：使用mysql的事務(wù)加排他鎖來(lái)解決，首先我們選擇數(shù)據(jù)庫(kù)的存儲(chǔ)引擎為innoDB，使用的是排他鎖實(shí)現(xiàn)的，剛開(kāi)始的時(shí)候我們測(cè)試了下共享鎖，發(fā)現(xiàn)還是會(huì)出現(xiàn)超賣的現(xiàn)象。有個(gè)問(wèn)題是，當(dāng)我們進(jìn)行高并發(fā)測(cè)試時(shí)，對(duì)數(shù)據(jù)庫(kù)的性能影響很大，導(dǎo)致數(shù)據(jù)庫(kù)的壓力很大，最終也被我們否定了。

第三種方案：使用文件鎖實(shí)現(xiàn)。當(dāng)用戶搶到一件促銷商品后先觸發(fā)文件鎖，防止其他用戶進(jìn)入，該用戶搶到促銷品后再解開(kāi)文件鎖，放其他用戶進(jìn)行操作。這樣可以解決超賣的問(wèn)題，但是會(huì)導(dǎo)致文件得I/O開(kāi)銷很大。

最后我們使用了redis的隊(duì)列來(lái)實(shí)現(xiàn)。將要促銷的商品數(shù)量以隊(duì)列的方式存入redis中，每當(dāng)用戶搶到一件促銷商品則從隊(duì)列中刪除一個(gè)數(shù)據(jù)，確保商品不會(huì)超賣。這個(gè)操作起來(lái)很方便，而且效率極高，最終我們采取這種方式來(lái)實(shí)現(xiàn)

21.商城秒殺的實(shí)現(xiàn)?

答:搶購(gòu)、秒殺是如今很常見(jiàn)的一個(gè)應(yīng)用場(chǎng)景，主要需要解決的問(wèn)題有兩個(gè)：

1 高并發(fā)對(duì)數(shù)據(jù)庫(kù)產(chǎn)生的壓力
2 競(jìng)爭(zhēng)狀態(tài)下如何解決庫(kù)存的正確減少（"超賣"問(wèn)題）

對(duì)于第一個(gè)問(wèn)題，已經(jīng)很容易想到用緩存來(lái)處理?yè)屬?gòu)，避免直接操作數(shù)據(jù)庫(kù)，例如使用Redis。第二個(gè)問(wèn)題，我們可以使用redis隊(duì)列來(lái)完成，把要秒殺的商品放入到隊(duì)列中，因?yàn)閜op操作是原子的，即使有很多用戶同時(shí)到達(dá)，也是依次執(zhí)行，文件鎖和事務(wù)在高并發(fā)下性能下降很快，當(dāng)然還要考慮其他方面的東西，比如搶購(gòu)頁(yè)面做成靜態(tài)的，通過(guò)ajax調(diào)用接口，其中也可能會(huì)出現(xiàn)一個(gè)用戶搶多次的情況，這時(shí)候需要再加上一個(gè)排隊(duì)隊(duì)列和搶購(gòu)結(jié)果隊(duì)列及庫(kù)存隊(duì)列。高并發(fā)情況下，將用戶進(jìn)入排隊(duì)隊(duì)列，用一個(gè)線程循環(huán)處理從排隊(duì)隊(duì)列取出一個(gè)用戶，判斷用戶是否已在搶購(gòu)結(jié)果隊(duì)列，如果在，則已搶購(gòu)，否則未搶購(gòu)，庫(kù)存減1，寫(xiě)數(shù)據(jù)庫(kù)，將用戶入結(jié)果隊(duì)列。

22.購(gòu)物車的原理?

答:購(gòu)物車相當(dāng)于現(xiàn)實(shí)中超市的購(gòu)物車，不同的是一個(gè)是實(shí)體車，一個(gè)是虛擬車而已。用戶可以在購(gòu)物網(wǎng)站的不同頁(yè)面之間跳轉(zhuǎn)，以選購(gòu)自己喜愛(ài)的商品，點(diǎn)擊購(gòu)買(mǎi)時(shí)，該商品就自動(dòng)保存到你的購(gòu)物車中，重復(fù)選購(gòu)后，最后將選中的所有商品放在購(gòu)物車中統(tǒng)一到付款臺(tái)結(jié)賬，這也是盡量讓客戶體驗(yàn)到現(xiàn)實(shí)生活中購(gòu)物的感覺(jué)。服務(wù)器通過(guò)追蹤每個(gè)用戶的行動(dòng)，以保證在結(jié)賬時(shí)每件商品都物有其主。

主要涉及以下幾點(diǎn):

    1、把商品添加到購(gòu)物車，即訂購(gòu)
    2、刪除購(gòu)物車中已定購(gòu)的商品
    3、修改購(gòu)物車中某一本圖書(shū)的訂購(gòu)數(shù)量
    4、清空購(gòu)物車
    5、顯示購(gòu)物車中商品清單及數(shù)量、價(jià)格

實(shí)現(xiàn)購(gòu)物車的關(guān)鍵在于服務(wù)器識(shí)別每一個(gè)用戶并維持與他們的聯(lián)系。但是HTTP協(xié)議是一種“無(wú)狀態(tài)(Stateless)”的協(xié)議，因而服務(wù)器不能記住是誰(shuí)在購(gòu)買(mǎi)商品，當(dāng)把商品加入購(gòu)物車時(shí)，服務(wù)器也不知道購(gòu)物車?yán)镌扔行┦裁?，使得用戶在不同?yè)面間跳轉(zhuǎn)時(shí)購(gòu)物車無(wú)法“隨身攜帶”，這都給購(gòu)物車的實(shí)現(xiàn)造成了一定的困難。

目前購(gòu)物車的實(shí)現(xiàn)主要是通過(guò)cookie、session或結(jié)合數(shù)據(jù)庫(kù)的方式。下面分析一下它們的機(jī)制及作用。

cookie

cookie是由服務(wù)器產(chǎn)生，存儲(chǔ)在客戶端的一段信息。它定義了一種Web服務(wù)器在客戶端存儲(chǔ)和返回信息的機(jī)制，cookie文件它包含域、路徑、生存期、和由服務(wù)器設(shè)置的變量值等內(nèi)容。當(dāng)用戶以后訪問(wèn)同一個(gè)Web服務(wù)器時(shí)，瀏覽器會(huì)把cookie原樣發(fā)送給服務(wù)器。通過(guò)讓服務(wù)器讀取原先保存到客戶端的信息，網(wǎng)站能夠?yàn)闉g覽者提供一系列的方便，例如在線交易過(guò)程中標(biāo)識(shí)用戶身份、安全要求不高的場(chǎng)合避免用戶重復(fù)輸入名字和密碼、門(mén)戶網(wǎng)站的主頁(yè)定制、有針對(duì)性地投放廣告等等。利用cookie的特性，大大擴(kuò)展了WEB應(yīng)用程序的功能，不僅可以建立服務(wù)器與客戶機(jī)的聯(lián)系，因?yàn)閏ookie可以由服務(wù)器定制，因此還可以將購(gòu)物信息生成cookie值存放在客戶端，從而實(shí)現(xiàn)購(gòu)物車的功能。用基于cookie的方式實(shí)現(xiàn)服務(wù)器與瀏覽器之間的會(huì)話或購(gòu)物車，有以下特點(diǎn)：

1、cookie存儲(chǔ)在客戶端，且占用很少的資源，瀏覽器允許存放300個(gè)cookie，每個(gè)cookie的大小為4KB，足以滿足購(gòu)物車的要求，同時(shí)也減輕了服務(wù)器的負(fù)荷；
2、cookie為瀏覽器所內(nèi)置，使用方便。即使用戶不小心關(guān)閉了瀏覽器窗口，只要在cookie定義的有效期內(nèi)，購(gòu)物車中的信息也不會(huì)丟失；
3、cookie不是可執(zhí)行文件，所以不會(huì)以任何方式執(zhí)行，因此也不會(huì)帶來(lái)病毒或攻擊用戶的系統(tǒng)；
4、基于cookie的購(gòu)物車要求用戶瀏覽器必須支持并設(shè)置為啟用cookie，否則購(gòu)物車則失效；
5、存在著關(guān)于cookie侵犯訪問(wèn)者隱私權(quán)的爭(zhēng)論，因此有些用戶會(huì)禁止本機(jī)的cookie功能。

session

session是實(shí)現(xiàn)購(gòu)物車的另一種方法。session提供了可以保存和跟蹤用戶的狀態(tài)信息的功能，使當(dāng)前用戶在session中定義的變量和對(duì)象能在頁(yè)面之間共享，但是不能為應(yīng)用中其他用戶所訪問(wèn)，它與cookie最重大的區(qū)別是，session將用戶在會(huì)話期間的私有信息存儲(chǔ)在服務(wù)器端，提高了安全性。在服務(wù)器生成session后，客戶端會(huì)生成一個(gè)sessionid識(shí)別號(hào)保存在客戶端，以保持和服務(wù)器的同步。這個(gè)sessionid是只讀的，如果客戶端禁止cookie功能，session會(huì)通過(guò)在URL中附加參數(shù)，或隱含在表單中提交等其他方式在頁(yè)面間傳送。因此利用session實(shí)施對(duì)用戶的管理則更為安全、有效。

同樣，利用session也能實(shí)現(xiàn)購(gòu)物車，這種方式的特點(diǎn)是：

1、session用新的機(jī)制保持與客戶端的同步，不依賴于客戶端設(shè)置；
2、與cookie相比，session是存儲(chǔ)在服務(wù)器端的信息，因此顯得更為安全，因此可將身份標(biāo)示，購(gòu)物等信息存儲(chǔ)在session中；
3、session會(huì)占用服務(wù)器資源，加大服務(wù)器端的負(fù)載，尤其當(dāng)并發(fā)用戶很多時(shí)，會(huì)生成大量的session，影響服務(wù)器的性能；
4、因?yàn)閟ession存儲(chǔ)的信息更敏感，而且是以文件形式保存在服務(wù)器中，因此仍然存在著安全隱患。

結(jié)合數(shù)據(jù)庫(kù)的方式

這也是目前較普遍的模式，在這種方式中，數(shù)據(jù)庫(kù)承擔(dān)著存儲(chǔ)購(gòu)物信息的作用，session或cookie則用來(lái)跟蹤用戶。這種方式具有以下特點(diǎn)：

1、數(shù)據(jù)庫(kù)與cookie分別負(fù)責(zé)記錄數(shù)據(jù)和維持會(huì)話，能發(fā)揮各自的優(yōu)勢(shì)，使安全性和服務(wù)器性能都得到了提高；
2、每一個(gè)購(gòu)物的行為，都要直接建立與數(shù)據(jù)庫(kù)的連接，直至對(duì)表的操作完成后，連接才釋放。當(dāng)并發(fā)用戶很多時(shí)，會(huì)影響數(shù)據(jù)庫(kù)的性能，因此，這對(duì)數(shù)據(jù)庫(kù)的性能提出了更高的要求；
3、使cookie維持會(huì)話有賴客戶端的支持。

各種方式的選擇：

雖然cookie可用來(lái)實(shí)現(xiàn)購(gòu)物車，但必須獲得瀏覽器的支持，再加上它是存儲(chǔ)在客戶端的信息，極易被獲取，所以這也限制了它存儲(chǔ)更多，更重要的信息。所以一般cookie只用來(lái)維持與服務(wù)器的會(huì)話，例如國(guó)內(nèi)最大的當(dāng)當(dāng)網(wǎng)絡(luò)書(shū)店就是用cookie保持與客戶的聯(lián)系，但是這種方式最大的缺點(diǎn)是如果客戶端不支持cookie就會(huì)使購(gòu)物車失效。

Session能很好地與交易雙方保持會(huì)話，可以忽視客戶端的設(shè)置。在購(gòu)物車技術(shù)中得到了廣泛的應(yīng)用。但session的文件屬性使其仍然留有安全隱患。

結(jié)合數(shù)據(jù)庫(kù)的方式雖然在一定程度上解決了上述的問(wèn)題，但從上面的例子可以看出：在這種購(gòu)物流程中涉及到對(duì)數(shù)據(jù)庫(kù)表的頻繁操作，尤其是用戶每選購(gòu)一次商品，都要與數(shù)據(jù)庫(kù)進(jìn)行連接，當(dāng)用戶很多的時(shí)候就加大了服務(wù)器與數(shù)據(jù)庫(kù)的負(fù)荷。

23.redis消息隊(duì)列先進(jìn)先出需要注意什么?

答:通常使用一個(gè)list來(lái)實(shí)現(xiàn)隊(duì)列操作，這樣有一個(gè)小限制，所以的任務(wù)統(tǒng)一都是先進(jìn)先出，如果想優(yōu)先處理某個(gè)任務(wù)就不太好處理了，這就需要讓隊(duì)列有優(yōu)先級(jí)的概念，我們就可以優(yōu)先處理高級(jí)別的任務(wù)，實(shí)現(xiàn)方式有以下幾種方式：

1）單一列表實(shí)現(xiàn)：隊(duì)列正常的操作是 左進(jìn)右出（lpush,rpop）為了先處理高優(yōu)先級(jí)任務(wù)，在遇到高級(jí)別任務(wù)時(shí)，可以直接插隊(duì)，直接放入隊(duì)列頭部（rpush），這樣，從隊(duì)列頭部（右側(cè)）獲取任務(wù)時(shí)，取到的就是高優(yōu)先級(jí)的任務(wù)（rpop）

2）使用兩個(gè)隊(duì)列，一個(gè)普通隊(duì)列，一個(gè)高級(jí)隊(duì)列，針對(duì)任務(wù)的級(jí)別放入不同的隊(duì)列，獲取任務(wù)時(shí)也很簡(jiǎn)單，redis的BRPOP命令可以按順序從多個(gè)隊(duì)列中取值，BRPOP會(huì)按照給出的 key 順序查看，并在找到的第一個(gè)非空 list 的尾部彈出一個(gè)元素，redis> BRPOP list1 list2 0

list1 做為高優(yōu)先級(jí)任務(wù)隊(duì)列
list2 做為普通任務(wù)隊(duì)列

這樣就實(shí)現(xiàn)了先處理高優(yōu)先級(jí)任務(wù)，當(dāng)沒(méi)有高優(yōu)先級(jí)任務(wù)時(shí)，就去獲取普通任務(wù)

方式1最簡(jiǎn)單，但實(shí)際應(yīng)用比較局限，方式3可以實(shí)現(xiàn)復(fù)雜優(yōu)先級(jí)，但實(shí)現(xiàn)比較復(fù)雜，不利于維護(hù)

方式2是推薦用法，實(shí)際應(yīng)用最為合適

24.你負(fù)責(zé)的模塊有哪些難題?

答:在我負(fù)責(zé)的B2B電商項(xiàng)目中，當(dāng)時(shí)我負(fù)責(zé)的是訂單模塊，由于客戶一次選擇了多家商戶的商品，最終生成了一個(gè)訂單，這樣我們平臺(tái)在給商戶結(jié)算時(shí)出現(xiàn)了不知道這比費(fèi)用應(yīng)該給哪個(gè)商戶，這時(shí)候我們小組經(jīng)過(guò)討論，需要涉及到訂單拆分，也就是說(shuō)用戶點(diǎn)擊支付后,如果有多件商品,并且不是同一家店鋪那么 就要用到訂單的拆分,比如如果有兩件商品,并且不是同一店鋪 就在原來(lái)的訂單號(hào)下 在生成兩個(gè)子訂單號(hào) 并修改訂單表中兩件商品的訂單號(hào)。最終實(shí)現(xiàn)了商品的分配管理，解決了我們的難題。

我覺(jué)得在開(kāi)發(fā)過(guò)程中，遇到的難題無(wú)非是兩個(gè)，一個(gè)是技術(shù)層次的，我認(rèn)為，只要你有恒心，有熱心，沒(méi)有覺(jué)得不了的難題。另一個(gè)就是溝通問(wèn)題，在任何地方任何時(shí)候溝通都是最重要的，尤其是我們做開(kāi)發(fā)的，不溝通好，會(huì)影響整個(gè)項(xiàng)目的進(jìn)度，我本人是個(gè)非常還溝通的人，所以這點(diǎn)上也沒(méi)多大問(wèn)題。

25.用戶下單是怎么處理的?

答:判斷用戶有沒(méi)有登錄，在沒(méi)有登錄的情況下，不允許下單。登陸后，可進(jìn)行下單,并生成唯一的訂單號(hào)，此時(shí)訂單的狀態(tài)為未支付。

26.電商的登錄是怎么實(shí)現(xiàn)的?

答:分為普通登錄和第三方登錄 這邊主要說(shuō)一下第三方登錄吧，第三方登陸主要使用的是author協(xié)議，我就以QQ的第三方登陸為例來(lái)進(jìn)行說(shuō)明：當(dāng)用戶在我們的站點(diǎn)請(qǐng)求QQ的第三方登陸時(shí)，我們站點(diǎn)會(huì)引導(dǎo)用戶跳轉(zhuǎn)到QQ的登陸授權(quán)界面， 當(dāng)用戶輸入QQ和密碼成功登錄以后會(huì)自動(dòng)跳回到我們站點(diǎn)設(shè)置好的回調(diào)頁(yè)面，并附帶一個(gè)code參數(shù)，接著你使用code再次去請(qǐng)求QQ的授權(quán)頁(yè)面，就可以從中獲取到一個(gè)access token（訪問(wèn)令牌），通過(guò)這個(gè)access_token，我們可以調(diào)用QQ提供給我們的接口，比如獲取open_id，可以獲取用戶的基本信息。獲取到之后，我們需要拿用戶的授權(quán)信息和open_id和我們平臺(tái)的普通用戶進(jìn)行綁定。這樣不管是普通用戶登陸還是第三方登陸用戶，都可以實(shí)現(xiàn)登陸。

27.接口安全方面是怎么處理的?

答:我們當(dāng)時(shí)是這么做的，使用HTTP的POST方式,對(duì)固定參數(shù)+附加參數(shù)進(jìn)行數(shù)字簽名,使用的是md5加密,比如:我想通過(guò)標(biāo)題獲取一個(gè)信息,在客戶端使用 信息標(biāo)題+日期+雙方約定好的一個(gè)key通過(guò)md5加密生成一個(gè)簽名(sign),然后作為參數(shù)傳遞到服務(wù)器端,服務(wù)器端使用同樣的方法進(jìn)行校驗(yàn),如何接受過(guò)來(lái)的sign和我們通過(guò)算法算的值相同，證明是一個(gè)正常的接口請(qǐng)求，我們才會(huì)返回相應(yīng)的接口數(shù)據(jù)。

28.用的什么技術(shù)實(shí)現(xiàn)短信發(fā)送，在哪調(diào)用?

答:我主要用的第三方短信接口，在申請(qǐng)接口時(shí)進(jìn)行相應(yīng)信息的配置，然后在我們站點(diǎn)需要用到短信驗(yàn)證的地方進(jìn)行調(diào)用，我們通常在用戶注冊(cè)時(shí)使用到。

29.在工作中遇到什么困難?

答:總體來(lái)說(shuō)：在工作我主要遇到這幾個(gè)問(wèn)題比較難處理：

① 以前仕事をしていたとき、一時(shí)的な必要が生じて計(jì)畫(huà)が中斷されることがよくあり、結(jié)局のところ、大きな仕事や他の仕事をしなければならないことがよくありました。小さいものはたくさんありますが、それらは後でまとめます。一時(shí)的なニーズが発生した場(chǎng)合は、既存のタスクと一時(shí)的なタスクを優(yōu)先順位に従って再配置します。指定された時(shí)間內(nèi)に優(yōu)先度の高いタスクを効率的に完了します。

②プロジェクトの要件に取り組んでいるときに、理解力の低い人に遭遇すると、コミュニケーション中にすぐに腹を立ててしまい、最終的には要求された結(jié)果を達(dá)成できなくなります。これからは、このようなことが起こったときは、通常は紙ベースの、より視覚的なものを使用して、雙方が同意し、理解できる方法でコミュニケーションをとるようにします。そうすることで、今後の無(wú)用なトラブルを大幅に減らすことができます。プログラマにとって、要件の変更は非常に苦痛な作業(yè)であることは誰(shuí)もが知っているため、早めのコミュニケーションが非常に重要です。

③もう一つ、私の以前のリーダーはテクノロジーについてあまり詳しくなかったので、新しい要件が出るたびに、それを完了できない場(chǎng)合は短期間で完了するように常に要求されていました。そうすれば、私たちは解雇されるでしょう。能力に疑問(wèn)があります。もちろん、すべてのリーダーは、従業(yè)員ができるだけ早くタスクを完了し、コストを削減し、効率を向上させることを望んでいます。この時(shí)點(diǎn)で、私はニーズを絞り込み、重要なポイントと困難をリストアップし、タイムプランを作成し、プロジェクトの各ポイントの重要性と費(fèi)やされる時(shí)間の割合についてリーダーと根気強(qiáng)くコミュニケーションして、この計(jì)畫(huà)が確実に完了するようにします。時(shí)間內(nèi)に質(zhì)と量を備えたタスク。徐々に私はリーダーから認(rèn)められるようになりました。実際、リーダーシップは、物事が適切に計(jì)畫(huà)され、最小のコストで最大の価値が得られる限り、盲目的に不合理なものではありません。

30. ユーザーはログインせずにショッピング カートに直接追加するにはどうすればよいですか?

回答: ユーザーは購(gòu)入する製品の情報(bào) (製品 ID、製品価格など) を追加できます。ログイン時(shí)に、製品の sku_id、購(gòu)入數(shù)量、その他の重要なデータが COOKIE に保存されます。 COOKIE の內(nèi)容をデータベースに保存し、Cookie 內(nèi)のデータをクリアします。

31. インターフェイスを作成したことがありますか? インターフェイスをどのように定義しますか?

答え: はい。インターフェイスには 2 種類あり、1 つはデータ インターフェイス、もう 1 つはアプリケーション インターフェイスです。

データ型インターフェイス: これは、抽象クラスよりも抽象的な特定の「構(gòu)造」です。実際にはクラスではなく、クラスのような特定の文法構(gòu)造です。クラスを定義する形式を標(biāo)準(zhǔn)化する構(gòu)造仕様。これは通常、チームが比較的大きく、多くのブランチがある場(chǎng)合に使用されます。

アプリケーション インターフェイス: API (アプリケーション インターフェイス) はデータへの外部アクセスの入り口です。

私は主に APP 開(kāi)発におけるインターフェイスの作成に攜わっています。データは json/xml 形式で返され、対応するインターフェイス ドキュメントが添付されます。

32.Sku削減在庫(kù)?

答え: SKU = Stock Keeping Unit (在庫(kù)管理単位)

つまり、在庫(kù)を計(jì)測(cè)する?yún)g位です。ピース、ボックス、パレットなどに基づいて、出入りできます。 SKU は、単一の製品を區(qū)別する在庫(kù)管理単位です。

は、衣料品や履物製品で最もよく使用されます。たとえば、テキスタイルの SKU は通常、仕様、色、スタイルを表します。

テーブルを設(shè)計(jì)するときは、製品テーブルだけでなく、製品テーブルに合計(jì)在庫(kù)も含める必要があります。SKU テーブルには、毎回 SKU 在庫(kù)フィールドと単価フィールドも含まれます。ユーザーが製品を購(gòu)入すると、実際のオンラインで購(gòu)入した製品はすべて SKU 製品であるため、注文が正常に行われた後、対応する SKU 在庫(kù)は、購(gòu)入した製品の一意の SKU 番號(hào)に基づいて減らされる必要があります。當(dāng)然、製品の総在庫(kù)數(shù)も減ります。が製品マスターテーブルに格納され、在庫(kù)の総量も削減する必要があります。

33. インベントリ設(shè)定?

回答: 在庫(kù)は、商品在庫(kù)合計(jì)と SKU 在庫(kù)に分けられます。多くの場(chǎng)合、商品在庫(kù)合計(jì)は SKU 在庫(kù)の合計(jì)となります。通常、モールのバックエンドで商品の最大在庫(kù)數(shù)と最小在庫(kù)數(shù)を設(shè)定した後、現(xiàn)在の在庫(kù)數(shù)と最大在庫(kù)數(shù)と最小在庫(kù)數(shù)を比較し、在庫(kù)數(shù)がそれを上回ったり、下回ったりした場(chǎng)合に反映されます。在庫(kù)の過(guò)不足や在庫(kù)狀況、數(shù)量を把握しやすいレポート形式です。

34. 注文テーブルと在庫(kù)テーブルのデータの一貫性を確保するにはどうすればよいですか?

回答: 電子商取引システムでは、通常、注文が正常に生成された後、対応する在庫(kù)削減によって 2 つの整合性が確保される必要がありますが、場(chǎng)合によっては次のような理由が考えられます。プログラム ロジックの問(wèn)題、同時(shí)実行性、その他の問(wèn)題により、注文は成功しますが、在庫(kù)は減りません。このような狀況が発生することは許可されません。まず、データベースのストレージ エンジンを InnoDB にすることを選択する必要があります。このトランザクションは、注文が行われた場(chǎng)合にのみ許可されます。在庫(kù)が減ります。トランザクションをコミットします。コミットしないと、データの整合性を確保するためにトランザクションがロールバックされます。

35.O2O ユーザーは c 側(cè)で注文を出します。ba 側(cè)のデータの一貫性を確保するにはどうすればよいですか?

答：O2O為線上和線下模式，O2O模式奉行的是“線上支付+實(shí)體店消費(fèi)”的消費(fèi)模式，即消費(fèi)者在網(wǎng)上下單完成支付后，憑消費(fèi)憑證到實(shí)體店消費(fèi)。 O2O模式是把商家信息和支付程序放在線上進(jìn)行，而把商品和服務(wù)兌現(xiàn)放在線下，也就是說(shuō)O2O模式適用于快遞無(wú)法送達(dá)的有形產(chǎn)品。數(shù)據(jù)一致性的問(wèn)題是O2O行業(yè)中最常見(jiàn)的問(wèn)題，我們可以類似于數(shù)據(jù)庫(kù)的主從復(fù)制的思路來(lái)解決這個(gè)問(wèn)題.O2O有個(gè)供應(yīng)商系統(tǒng)，類似于主服務(wù)器，在?端（從服務(wù)器）下單時(shí)，數(shù)據(jù)同步更新到供應(yīng)商系統(tǒng)端，b，a實(shí)時(shí)從供應(yīng)商系統(tǒng)中拉取數(shù)據(jù)進(jìn)行同步，比如利用定時(shí)任務(wù)，定時(shí)拉取數(shù)據(jù)進(jìn)行同步。

36.Redis如何防止高并發(fā)?

答：其實(shí)redis是不會(huì)存在并發(fā)問(wèn)題的，因?yàn)樗菃芜M(jìn)程的，再多的命令都是一個(gè)接一個(gè)地執(zhí)行的。我們使用的時(shí)候，可能會(huì)出現(xiàn)并發(fā)問(wèn)題，比如獲得和設(shè)定這一對(duì)。Redis的為什么 有高并發(fā)問(wèn)題？Redis的的出身決定

Redis是一種單線程機(jī)制的nosql數(shù)據(jù)庫(kù)，基于key-value，數(shù)據(jù)可持久化落盤(pán)。由于單線程所以redis本身并沒(méi)有鎖的概念，多個(gè)客戶端連接并不存在競(jìng)爭(zhēng)關(guān)系，但是利用jedis等客戶端對(duì)redis進(jìn)行并發(fā)訪問(wèn)時(shí)會(huì)出現(xiàn)問(wèn)題。發(fā)生連接超時(shí)、數(shù)據(jù)轉(zhuǎn)換錯(cuò)誤、阻塞、客戶端關(guān)閉連接等問(wèn)題，這些問(wèn)題均是由于客戶端連接混亂造成。

同時(shí)，單線程的天性決定，高并發(fā)對(duì)同一個(gè)鍵的操作會(huì)排隊(duì)處理，如果并發(fā)量很大，可能造成后來(lái)的請(qǐng)求超時(shí)。

在遠(yuǎn)程訪問(wèn)redis的時(shí)候，因?yàn)榫W(wǎng)絡(luò)等原因造成高并發(fā)訪問(wèn)延遲返回的問(wèn)題。

解決辦法

在客戶端將連接進(jìn)行池化，同時(shí)對(duì)客戶端讀寫(xiě)Redis操作采用內(nèi)部鎖synchronized。

服務(wù)器角度，利用setnx變向?qū)崿F(xiàn)鎖機(jī)制。

37.秒殺當(dāng)中的細(xì)節(jié)你是怎么得出來(lái)的?

答:通過(guò)性能測(cè)試及模擬秒殺場(chǎng)景。每個(gè)問(wèn)題都經(jīng)過(guò)反復(fù)測(cè)試，不斷的發(fā)現(xiàn)問(wèn)題，不斷的解決。

38.做秒殺用什么數(shù)據(jù)庫(kù)，怎么實(shí)現(xiàn)的?

答:因?yàn)槊霘⒌囊凰查g，并發(fā)非常大，如果同時(shí)請(qǐng)求數(shù)據(jù)庫(kù)，會(huì)導(dǎo)致數(shù)據(jù)庫(kù)的壓力非常大，導(dǎo)致數(shù)據(jù)庫(kù)的性能急劇下降，更嚴(yán)重的可能會(huì)導(dǎo)致數(shù)據(jù)庫(kù)服務(wù)器宕機(jī)。這時(shí)候一般采用內(nèi)存高速緩存數(shù)據(jù)庫(kù)redis來(lái)實(shí)現(xiàn)的,redis是非關(guān)系型數(shù)據(jù)庫(kù)，redis是單線程的，通過(guò)redis的隊(duì)列可以完成秒殺過(guò)程。

39.支付寶流程怎么實(shí)現(xiàn)的?

答:首先要有一個(gè)支付寶賬號(hào)，接下來(lái)向支付寶申請(qǐng)?jiān)诰€支付業(yè)務(wù)，簽署協(xié)議。協(xié)議生效后有支付寶一方會(huì)給網(wǎng)站方一個(gè)合作伙伴ID,和安全校驗(yàn)碼，有了這兩樣?xùn)|西就可以按照支付寶接口文檔開(kāi)發(fā)支付寶接口了，中間主要涉及到一個(gè)安全問(wèn)題。整個(gè)流程是這樣的：我們的網(wǎng)站通過(guò)post傳遞相應(yīng)的參數(shù)（如訂單總金額，訂單號(hào)）到支付頁(yè)面，支付頁(yè)面把一系列的參數(shù)經(jīng)過(guò)處理，以post的方式提交給支付寶服務(wù)器，支付寶服務(wù)器進(jìn)行驗(yàn)證，并對(duì)接收的數(shù)據(jù)進(jìn)行處理，把處理后的結(jié)果返回給我們網(wǎng)站設(shè)置的異步和同步回調(diào)地址，通過(guò)相應(yīng)的返回參數(shù)，來(lái)處理相應(yīng)的業(yè)務(wù)邏輯，比如返回的參數(shù)代表支付成功，更改訂單狀態(tài)。

40.什么是單點(diǎn)登錄？

答:單點(diǎn)登錄SSO（Single Sign On）說(shuō)得簡(jiǎn)單點(diǎn)就是在一個(gè)多系統(tǒng)共存的環(huán)境下，用戶在一處登錄后，就不用在其他系統(tǒng)中登錄，也就是用戶的一次登錄能得到其他所有系統(tǒng)的信任。

41.什么情況下使用緩存?

答:當(dāng)用戶第一次訪問(wèn)應(yīng)用系統(tǒng)的時(shí)候，因?yàn)檫€沒(méi)有登錄，會(huì)被引導(dǎo)到認(rèn)證系統(tǒng)中進(jìn)行登錄；根據(jù)用戶提供的登錄信息，認(rèn)證系統(tǒng)進(jìn)行身份校驗(yàn)，如果通過(guò)校驗(yàn)，應(yīng)該返回給用戶一個(gè)認(rèn)證的憑據(jù)－－ticket；用戶再訪問(wèn)別的應(yīng)用的時(shí)候，就會(huì)將這個(gè)ticket帶上，作為自己認(rèn)證的憑據(jù)，應(yīng)用系統(tǒng)接受到請(qǐng)求之后會(huì)把 ticket送到認(rèn)證系統(tǒng)進(jìn)行校驗(yàn)，檢查ticket的合法性。如果通過(guò)校驗(yàn)，用戶就可以在不用再次登錄的情況下訪問(wèn)應(yīng)用系統(tǒng)2和應(yīng)用系統(tǒng)3了。

實(shí)現(xiàn)主要技術(shù)點(diǎn)：

    1、兩個(gè)站點(diǎn)共用一個(gè)數(shù)據(jù)驗(yàn)證系統(tǒng)
    2、主要通過(guò)跨域請(qǐng)求的方式來(lái)實(shí)現(xiàn)驗(yàn)證及session處理。

42.怎么實(shí)現(xiàn)第三方登錄？

答:第三方登陸主要是基于author協(xié)議來(lái)實(shí)現(xiàn)，下面簡(jiǎn)單說(shuō)下實(shí)現(xiàn)流程:

1、首先我們需要以開(kāi)發(fā)者的身份向第三方登陸平臺(tái)申請(qǐng)接入應(yīng)用，申請(qǐng)成功后，我們會(huì)獲得一個(gè)appID和一個(gè)secrectID.
2、當(dāng)我們的網(wǎng)站需接入第三方登陸時(shí)，會(huì)引導(dǎo)用戶跳轉(zhuǎn)到第三方的登陸授權(quán)頁(yè)面，此時(shí)把之前申請(qǐng)的appID和secrectID帶給登陸授權(quán)頁(yè)面。
3、用戶登陸成功后即得到授權(quán)，第三方會(huì)返回一個(gè)臨時(shí)的code給我們的網(wǎng)站。
4、我們的網(wǎng)站接受到code后，再次向我們的第三方發(fā)起請(qǐng)求，并攜帶接收的code,從第三方獲取access_token.
5、第三方處理請(qǐng)求后，會(huì)返回一個(gè)access_token給我們的網(wǎng)站，我們的網(wǎng)站獲取到access_token后就可以調(diào)用第三方提供的接口了，比如獲取用戶信息等。最后把該用戶信息存入到我們站點(diǎn)的數(shù)據(jù)庫(kù)，并把信息保存到session中，實(shí)現(xiàn)用戶的第三方登陸。

43.如何處理負(fù)載、高并發(fā)？(好好看看，經(jīng)常問(wèn)到，能回答到主要的東西即可)?

答:從低成本、高性能和高擴(kuò)張性的角度來(lái)說(shuō)有如下處理方案：

1、HTML靜態(tài)化

実際、最も効率的で消費(fèi)が最も少ないのは純粋に靜的な HTML ページであることは誰(shuí)もが知っているため、Web サイトのページには靜的なページを使用するよう最善を盡くしています。この最も単純な方法が実際には最も効果的です。

2. 個(gè)別の畫(huà)像サーバー

畫(huà)像などの大規(guī)模なトラフィックのオーバーヘッドを最小限に抑えるために、畫(huà)像をブルライディングなどの関連プラットフォームに配置できます。

3. データベース クラスターとデータベース テーブルのハッシュとキャッシュ

データベースの同時(shí)接続は 100 です。1 つのデータベースでは十分ではありません。読み取りと書(shū)き込みの分離、マスターとスレーブの側(cè)面から始めることができます。レプリケーション、データベース クラスター。さらに、データベース アクセスを最小限に抑えるために、memcache や redis などのキャッシュ データベースを使用できます。

4. ミラー:

ダウンロードをできるだけ減らし、さまざまなリクエストを複數(shù)のミラーに分散します。

5. 負(fù)荷分散:

Apache の最大同時(shí)接続數(shù)は 1500 です。追加できるのは F5 サーバーなどのハードウェアのみです。もちろん、ハードウェアのコストは比較的高いため、ソフトウェアから始めることがよくあります。

負(fù)荷分散は、既存のネットワーク構(gòu)造に基づいて構(gòu)築されており、ネットワーク デバイスとサーバーの帯域幅を拡張し、スループットを向上させ、ネットワーク データ処理機(jī)能を強(qiáng)化する、安価で効果的かつ透過(guò)的な方法を提供します?？捎眯浴，F(xiàn)在、最も広く使用されている負(fù)荷分散ソフトウェアは、Nginx、LVS、および HAProxy です。 3 つのタイプのそれぞれの長(zhǎng)所と短所について説明します:

Nginx の利點(diǎn)は次のとおりです:

Nginx はネットワークの 7 層上で動(dòng)作し、次のことができます。ドメイン名やディレクトリ構(gòu)造などの戦略は、HAProxy よりも強(qiáng)力で柔軟であり、これが、Nginx が現(xiàn)在、HAProxy よりもはるかに多くの狀況で広く利用されている主な理由の 1 つです。これだけをベースにしたLVS。

Nginx は、理論上、ネットワークの安定性にほとんど依存しません。これは、逆に、ネットワークの安定性に大きく依存する點(diǎn)でもあります。私も経験があります。

Nginx はインストールと設(shè)定が比較的簡(jiǎn)単で、基本的にエラーをログに出力することができます。 LVS の構(gòu)成とテストには比較的長(zhǎng)い時(shí)間がかかり、LVS はネットワークに大きく依存します。

高い負(fù)荷圧力に耐えることができ、安定しています。ハードウェアが悪くなければ、通常は數(shù)萬(wàn)の同時(shí)実行をサポートでき、負(fù)荷の度合いは LVS よりも比較的小さいです。

Nginx は、Web ページを処理するサーバーから返されるステータス コードやタイムアウトなどの內(nèi)部サーバー障害をポート経由で検出でき、エラーを返すリクエストを別のノードに再送信します。検出する URL をサポートできません。たとえば、ユーザーがファイルをアップロードしていて、アップロード処理中にアップロードを処理するノードが失敗した場(chǎng)合、Nginx は再処理のためにアップロードを別のサーバーに切り替え、大きなファイルがアップロードされると LVS が直接切斷されます。重要なファイルを保存すると、ユーザーが不満を抱く可能性があります。

Nginx は、優(yōu)れたロード バランサー/リバース プロキシ ソフトウェアであるだけでなく、強(qiáng)力な Web アプリケーション サーバーでもあります。 LNMP は近年非常に人気のある Web アーキテクチャでもあり、高トラフィック環(huán)境での安定性も非常に優(yōu)れています。

Nginx は Web リバース アクセラレーション キャッシュとしてますます成熟しており、従來(lái)の Squid サーバーよりも高速になっており、リバース プロキシ アクセラレータとして使用することを検討できます。

Nginx は中間レベルのリバース プロキシとして使用できます。このレベルでは、Nginx に匹敵するのは lighttpd だけです。ただし、lighttpd はまだ完全な機(jī)能を備えていません。 Nginx ですが、構(gòu)成はそれほど良くありません。明瞭で読みやすく、コミュニティ情報(bào)は Nginx よりもはるかに活発ではありません。

Nginx は靜的 Web ページおよび畫(huà)像サーバーとしても使用でき、この分野でのパフォーマンスは比類のありません。 Nginx コミュニティも非常に活発で、多くのサードパーティ モジュールがあります。

Nginx の欠點(diǎn)は次のとおりです。

Nginx は http、https、および電子メール プロトコルのみをサポートするため、適用範(fàn)囲が狹くなります。

バックエンド サーバーのヘルス チェックは、ポートを介した検出のみをサポートし、URL を介した検出はサポートしません。セッションの直接保持はサポートされていませんが、ip_hash を通じて解決できます。

LVS: Linux カーネル クラスターを使用して、優(yōu)れたスケーラビリティ (Scalability)、信頼性 (Reliability)、および管理容易性 (Manageability) を備えた高性能、高可用性の負(fù)荷分散サーバーを?qū)g裝します。

LVS の利點(diǎn)は次のとおりです。

LVS は、強(qiáng)力な負(fù)荷耐性を持ち、配信のみを目的としてネットワークの 4 層上で動(dòng)作します。この機(jī)能にはトラフィックが生成されません。また、これにより、負(fù)荷分散ソフトウェアの中で最も優(yōu)れたパフォーマンスが得られ、メモリと CPU リソースの消費(fèi)量が比較的少ないことが決まります。

設(shè)定可能性が比較的低いことが欠點(diǎn)でもあり、利點(diǎn)でもあります。あまりにも多くの設(shè)定ができるものがないため、あまり多くの連絡(luò)を必要とせず、人的エラーの可能性が大幅に減少します。

負(fù)荷耐性が強(qiáng)く、LVS Keepalived などの完全なデュアルマシン ホット バックアップ ソリューションを備えているため、安定して動(dòng)作します。ただし、プロジェクトの実裝で最もよく使用されるのは LVS/DR Keepalived です。

トラフィックなし。LVS はリクエストを分散するだけで、トラフィックはそれ自體から送信されません。これにより、バランサー IO のパフォーマンスが大量のトラフィックによって影響を受けることはありません。

LVS はレイヤー 4 で動(dòng)作するため、アプリケーションの範(fàn)囲が比較的広く、http、データベース、オンライン チャット ルームなど、ほぼすべてのアプリケーションの負(fù)荷を分散できます。

LVS の欠點(diǎn)は次のとおりです。

ソフトウェア自體は正規(guī)表現(xiàn)処理をサポートしておらず、動(dòng)的と靜的を分離できないため、現(xiàn)在多くの Web サイトでこの點(diǎn)に関する強(qiáng)いニーズがあります。 、これが Nginx/HAProxy Keepalived の利點(diǎn)です。

Web サイト アプリケーションが比較的大規(guī)模な場(chǎng)合、LVS/DR Keepalived の実裝はより複雑になります。特に、その背後に Windows Server マシンがある場(chǎng)合、実裝、構(gòu)成、およびメンテナンスのプロセスはより複雑になります。 、 、Nginx/HAProxy Keepalived ははるかに簡(jiǎn)単です。

HAProxy の特徴は次のとおりです。

HAProxy は仮想ホストもサポートします。

HAProxy の利點(diǎn)は、セッション保持や Cookie ガイダンスのサポートなど、Nginx の欠點(diǎn)の一部を補(bǔ)うことができます。また、指定された URL の取得によるバックエンド サーバーのステータスの検出もサポートします。

HAProxy は LVS に似ていますが、純粋に効率という點(diǎn)ではロード バランシング ソフトウェアです。HAProxy は Nginx よりもロード バランシング速度が高く、同時(shí)処理でも Nginx よりも優(yōu)れています。

HAProxy は、TCP プロトコルのロード バランシング転送をサポートしており、MySQL 読み取りのロード バランシング、バックエンド MySQL ノードの検出とロード バランシングを行うことができます。LVS Keepalived を使用して、MySQL マスターとスレーブのロード バランシングを行うことができます。

HAProxy の負(fù)荷分散戦略には、現(xiàn)在次の 8 種類があります。

① ラウンドロビン、これについては多くは言いません。負(fù)荷分散の基本はすべて

② static-rr で、重みに基づいて注意することが推奨されることを示します。

④ ソースは、Nginx の IP_hash メカニズムと同様に、セッションの問(wèn)題を解決するために使用することをお?jiǎng)幛幛筏蓼埂Ｗ⒁?

⑤ ri、リクエストの URI に基づいて示します;

⑥ rl_param、要求された URl パラメータに応じた URL パラメータ名が必要であることを示します。

#⑦ hdr(name) は、各 HTTP リクエストが HTTP リクエスト ヘッダーに基づいてロックされていることを示します。

⑧ rdp-cookie(name) は、cookie(name) に基づいて各 TCP リクエストをロックおよびハッシュすることを意味します。 。

Nginx と LVS の比較の概要:

Nginx はネットワークのレイヤー 7 で動(dòng)作するため、次のような http アプリケーション自體の迂回戦略を?qū)g裝できます。対照的に、LVS にはそのような機(jī)能がないため、これだけで Nginx は LVS よりもはるかに多くの狀況で使用できますが、Nginx のこれらの便利な機(jī)能により、LVS よりも調(diào)整が容易になります。觸ったり觸ったり觸ったりしなければならないことがよくあります。觸りすぎると、人間の問(wèn)題が発生する可能性が高くなります。

Nginx は、理論的には、ping が成功し、Web ページに正常にアクセスできる限り、ネットワークの安定性への依存度が低くなります。これは、Nginx の大きな利點(diǎn)です。 Nginx は內(nèi)部ネットワークと外部ネットワークを區(qū)別することもできます。內(nèi)部ネットワークと外部ネットワークの両方を持つノードの場(chǎng)合、LVS はネットワーク環(huán)境にさらに依存します。同じネットワークセグメントでは、LVS はオフロードにダイレクトモードを使用します。その効果はより確実です。また、LVS がビジュアル IP として使用するには、ホスティング プロバイダーから少なくとも 1 つの IP を申請(qǐng)する必要があることにも注意してください。獨(dú)自の IP を VIP として使用することはできないようです。優(yōu)れた LVS 管理者になるには、ネットワーク通信について多くの知識(shí)をフォローアップして學(xué)ぶ必要があります。ネットワーク通信はもはや HTTP ほど単純ではありません。

Nginx はインストールと設(shè)定が比較的簡(jiǎn)単で、基本的にエラーをログに出力できるため、テストにも非常に便利です。 LVS のインストール、構(gòu)成、テストには比較的長(zhǎng)い時(shí)間がかかります。LVS はネットワークに大きく依存しており、多くの場(chǎng)合、構(gòu)成に問(wèn)題があるのではなく、ネットワークの問(wèn)題が原因となります。解決するのがさらに面倒です。

Nginx も高負(fù)荷に耐えることができ、安定していますが、負(fù)荷と安定性は LVS よりも劣ります。Nginx はすべてのトラフィックを処理するため、マシンの IO と構(gòu)成によって制限されます。まだ解決は難しい。

Nginx は、Web ページを処理するサーバーから返されるステータス コードやタイムアウトなどの內(nèi)部サーバー障害を検出でき、エラーを返すリクエストを別のノードに再送信します?，F(xiàn)在、LVS の ldirectd はサーバーの內(nèi)部狀態(tài)の監(jiān)視もサポートしていますが、LVS の原理によりリクエストを再送信することはできません。たとえば、ユーザーがファイルをアップロードしていて、アップロード処理中にアップロードを処理するノードが失敗した場(chǎng)合、Nginx は再処理のためにアップロードを別のサーバーに切り替え、大きなファイルがアップロードされると LVS が直接切斷されます。重要なファイルがある場(chǎng)合、ユーザーはこれに煩わされる可能性があります。

Nginx のリクエストの非同期処理は、ノード サーバーの負(fù)荷を軽減するのに役立ちます。Apache を使用して外部サービスに直接サービスを提供する場(chǎng)合、ナローバンド リンクが多數(shù)ある場(chǎng)合、Apache サーバーは大量のメモリを占有してしまうため、ノード サーバーが負(fù)荷を軽減できません。もう 1 つの Nginx を Apache として使用する プロキシを使用すると、これらの狹帯域リンクが Nginx によってブロックされ、大量のリクエストが Apache に蓄積されなくなり、リソースの使用量が大幅に削減されます。この點(diǎn)では、Squid 自體がキャッシュしないように設(shè)定されている場(chǎng)合でも、Squid を使用すると同じ効果が得られますが、Apache にとっては非常に役立ちます。

Nginx能支持http、https和email（email的功能比較少用），LVS所支持的應(yīng)用在這點(diǎn)上會(huì)比Nginx更多。在使用上，一般最前端所采取的策略應(yīng)是LVS，也就是DNS的指向應(yīng)為L(zhǎng)VS均衡器，LVS的優(yōu)點(diǎn)令它非常適合做這個(gè)任務(wù)。重要的ip地址，最好交由LVS托管，比如數(shù)據(jù)庫(kù)的 ip、webservice服務(wù)器的ip等等，這些ip地址隨著時(shí)間推移，使用面會(huì)越來(lái)越大，如果更換ip則故障會(huì)接踵而至。所以將這些重要ip交給 LVS托管是最為穩(wěn)妥的，這樣做的唯一缺點(diǎn)是需要的VIP數(shù)量會(huì)比較多。Nginx可作為L(zhǎng)VS節(jié)點(diǎn)機(jī)器使用，一是可以利用Nginx的功能，二是可以利用Nginx的性能。當(dāng)然這一層面也可以直接使用squid，squid的功能方面就比Nginx弱不少了，性能上也有所遜色于Nginx。Nginx也可作為中層代理使用，這一層面Nginx基本上無(wú)對(duì)手，唯一可以撼動(dòng)Nginx的就只有l(wèi)ighttpd了，不過(guò)lighttpd目前還沒(méi)有能做到 Nginx完全的功能，配置也不那么清晰易讀。另外，中層代理的IP也是重要的，所以中層代理也擁有一個(gè)VIP和LVS是最完美的方案了。具體的應(yīng)用還得具體分析，如果是比較小的網(wǎng)站（日PV小于1000萬(wàn)），用Nginx就完全可以了，如果機(jī)器也不少，可以用DNS輪詢，LVS所耗費(fèi)的機(jī)器還是比較多的；大型網(wǎng)站或者重要的服務(wù)，機(jī)器不發(fā)愁的時(shí)候，要多多考慮利用LVS。

數(shù)據(jù)庫(kù)優(yōu)化

44.做秒殺時(shí)鎖表考慮到?jīng)]有？

答:考慮到了，當(dāng)時(shí)我們做秒殺時(shí)考慮了好幾種方案，其中有一種就是使用事務(wù)加上排他鎖來(lái)實(shí)現(xiàn)。

45.架構(gòu)類的東西接觸過(guò)嗎？

有接觸過(guò)，曾經(jīng)自己在自己的服務(wù)器上配置過(guò)。我以前做過(guò)以下幾個(gè)架構(gòu)方面的配置和測(cè)試;

1、數(shù)據(jù)庫(kù)的讀寫(xiě)分離、主從復(fù)制及集群。
2、Nginx負(fù)載均衡
3、redis集群及主從

46.封裝過(guò)一個(gè)簡(jiǎn)單的框架?

答;封裝過(guò)一個(gè)簡(jiǎn)單的MVC框架,主要分為3層，控制器層和模型層視圖層，以及路由的分配和入口文件，模板引擎，單例模式、工廠模式，第三方類庫(kù)的引入等。

47.談?wù)剬?duì)MVC的認(rèn)識(shí)?

答:核心思想是：視圖和用戶交互通過(guò)事件導(dǎo)致控制器改變 控制器改變導(dǎo)致模型改變 或者控制器同時(shí)改變兩者 模型改變 導(dǎo)致視圖改變 或者視圖改變 潛在的從模型里面獲得參數(shù) 來(lái)改變自己。他的好處是可以將界面和業(yè)務(wù)邏輯分離。

Model（模型），是程序的主體部分，主要包含業(yè)務(wù)數(shù)據(jù)和業(yè)務(wù)邏輯。在模型層，還會(huì)涉及到用戶發(fā)布的服務(wù)，在服務(wù)中會(huì)根據(jù)不同的業(yè)務(wù)需求，更新業(yè)務(wù)模型中的數(shù)據(jù)。
View(視圖），是程序呈現(xiàn)給用戶的部分，是用戶和程序交互的接口，用戶會(huì)根據(jù)具體的業(yè)務(wù)需求，在View視圖層輸入自己特定的業(yè)務(wù)數(shù)據(jù)，并通過(guò)界面的事件交互，將對(duì)應(yīng)的輸入?yún)?shù)提交給后臺(tái)控制器進(jìn)行處理。
Contorller（控制器），Contorller是用來(lái)處理用戶 輸入數(shù)據(jù)，已經(jīng)更新業(yè)務(wù)模型的部分?？刂破髦薪邮樟擞脩襞c界面交互時(shí)傳遞過(guò)來(lái)的數(shù)據(jù)，并根據(jù)數(shù)據(jù)業(yè)務(wù)邏輯來(lái)執(zhí)行服務(wù)的調(diào)用和更新業(yè)務(wù)模型的數(shù)據(jù)和狀態(tài)。

48.session與cookie的區(qū)別?

1、cookie數(shù)據(jù)存放在第三方應(yīng)用的瀏覽器上，session數(shù)據(jù)放在服務(wù)器上。

2、cookie不是很安全，別人可以分析存放在本地的COOKIE，進(jìn)行COOKIE欺騙,考慮到安全應(yīng)當(dāng)使用session。

3、session會(huì)在一定時(shí)間內(nèi)保存在服務(wù)器上。當(dāng)訪問(wèn)增多，會(huì)比較占用你服務(wù)器的性能,考慮到減輕服務(wù)器性能方面，應(yīng)當(dāng)使用COOKIE。

4、單個(gè)cookie保存的數(shù)據(jù)不能超過(guò)4K，很多瀏覽器都限制一個(gè)站點(diǎn)最多保存20個(gè)cookie。

5、所以個(gè)人建議：
    將登陸信息等重要信息存放為SESSION
    其他信息如果需要保留，可以放在COOKIE

49.echo(),print(),print_r()的區(qū)別?

echo可以一次輸出多個(gè)值，多個(gè)值之間用逗號(hào)分隔。echo是語(yǔ)言結(jié)構(gòu)(language construct)，而并不是真正的函數(shù)，因此不能作為表達(dá)式的一部分使用。echo是php的內(nèi)部指令，不是函數(shù)，無(wú)返回值。

print()：函數(shù)print()打印一個(gè)值（它的參數(shù)），如果字符串成功顯示則返回true，否則返回false。只能打印出簡(jiǎn)單類型變量的值(如int,string)，有返回值

printf()：源于C語(yǔ)言中的printf()。該函數(shù)輸出格式化的字符串。

print_r()和var_dump()
print_r()可以把字符串和數(shù)字簡(jiǎn)單地打印出來(lái)，而數(shù)組則以括起來(lái)的鍵和值得列表形式顯示，并以Array開(kāi)頭。但print_r()輸出布爾值和NULL的結(jié)果沒(méi)有意義，因?yàn)槎际谴蛴?quot;\n"。因此用var_dump()函數(shù)更適合調(diào)試。print_r是函數(shù)，可以打印出比較復(fù)雜的變量(如數(shù)組，對(duì)象)，有返回值
var_dump()判斷一個(gè)變量的類型與長(zhǎng)度,并輸出變量的數(shù)值,如果變量有值輸?shù)氖亲兞康闹挡⒒胤禂?shù)據(jù)類型。此函數(shù)顯示關(guān)于一個(gè)或多個(gè)表達(dá)式的結(jié)構(gòu)信息，包括表達(dá)式的類型與值。數(shù)組將遞歸展開(kāi)值，通過(guò)縮進(jìn)顯示其結(jié)構(gòu)。

50.說(shuō)一下單引號(hào)雙引號(hào)？

①單引號(hào)內(nèi)部的變量不會(huì)執(zhí)行， 雙引號(hào)會(huì)執(zhí)行

②單引號(hào)解析速度比雙引號(hào)快。

③單引號(hào)只能解析部分特殊字符，雙引號(hào)可以解析所有特殊字符。

51.索引的優(yōu)缺點(diǎn)?

1、優(yōu)點(diǎn)：

a）可以保證數(shù)據(jù)庫(kù)表中每一行的數(shù)據(jù)的唯一性
b）可以大大加快數(shù)據(jù)的索引速度
c）加速表與表之間的連接，物別是在實(shí)現(xiàn)數(shù)據(jù)的參考完事性方面特別有意義
d）在使用分組和排序子句進(jìn)行數(shù)據(jù)檢索時(shí)，同樣可以顯著減少查詢中分組和排序的時(shí)間
f）通過(guò)使用索引，可以在時(shí)間查詢的過(guò)程中，使用優(yōu)化隱藏器，提高系統(tǒng)的性能

2、 缺點(diǎn)：

a)  創(chuàng)建索引和維護(hù)索引要耗費(fèi)時(shí)間，這種時(shí)間隨著數(shù)據(jù)量的增加而增加
b)  索引需要占物理空間，除了數(shù)據(jù)表占用數(shù)據(jù)空間之外，每一個(gè)索引還要占用一定的物理空間，如果需要建立聚簇索引，那么需要占用的空間會(huì)更大
c)  以表中的數(shù)據(jù)進(jìn)行增、刪、改的時(shí)候，索引也要?jiǎng)討B(tài)的維護(hù)，這就降低了整數(shù)的維護(hù)速度
d)  建立索引的原則
e)  在經(jīng)常需要搜索的列上，可以加快搜索的速度
f)  在作為主鍵的列上，強(qiáng)制該列的唯一性和組織表中數(shù)據(jù)的排列結(jié)構(gòu)
g)  在經(jīng)常用在連接的列上，這些列主要是一外鍵，可以加快連接的速度
h)  在經(jīng)經(jīng)常需要根據(jù)范圍進(jìn)行搜索的列上創(chuàng)建索引，國(guó)為索引已經(jīng)排序，其指定的范圍是連續(xù)的
i)  在經(jīng)常需要排序的列上，國(guó)為索引已經(jīng)排序，這樣井底可以利用索引的排序，加快排序井底時(shí)間
j)  在經(jīng)常使用在where子句中的列上，加快條件的判斷速度

52.get和post的區(qū)別?

1. get是從服務(wù)器上獲取數(shù)據(jù)，post是向服務(wù)器傳送數(shù)據(jù)。
2. get是把參數(shù)數(shù)據(jù)隊(duì)列加到提交表單的ACTION屬性所指的URL中，值和表單內(nèi)各個(gè)字段一一對(duì)應(yīng)，在URL中可以看到。post是通過(guò)HTTP post機(jī)制，將表單內(nèi)各個(gè)字段與其內(nèi)容放置在HTML HEADER內(nèi)一起傳送到ACTION屬性所指的URL地址。用戶看不到這個(gè)過(guò)程。
3. get傳送的數(shù)據(jù)量較小，不能大于2KB。post傳送的數(shù)據(jù)量較大，一般被默認(rèn)為不受限制。
4. get安全性非常低，post安全性較高。但是執(zhí)行效率卻比Post方法好。

53.如何修改會(huì)話的生存時(shí)間？

一：在php.ini中設(shè)置session.gc_maxlifetime = 1440 //默認(rèn)時(shí)間
二：代碼實(shí)現(xiàn)      $ lifeTime = 24 * 3600; //保存一天
    session_set_cookie_params（$ lifeTime）; 
    在session_start（）;

54.Linux基本命令，目錄結(jié)構(gòu)？

arch顯示機(jī)器的處理器架構(gòu)
（1） uname -m顯示機(jī)器的處理器架構(gòu)
（2） uname -r顯示正在使用的內(nèi)核版本 
dmidecode -q顯示硬件系統(tǒng)部件 - （SMBIOS / DMI）   
hdparm -i / dev / hda羅列一個(gè)磁盤(pán)的架構(gòu)特性    
hdparm -tT / dev / sda在磁盤(pán)上執(zhí)行測(cè)試性讀取操作 
cat / porc / cpuinfo顯示CPU信息 
cat / porc / interrupts顯示中斷
cat / porc / meminfo校驗(yàn)內(nèi)存使用  
cat / porc / swaps顯示哪些交換被使用 
cat / porc / verion顯示內(nèi)核的版本
cat /porc/net/dev 顯示網(wǎng)絡(luò)適配器及統(tǒng)計(jì) 
cat /porc/mounts 顯示已加載的文件系統(tǒng) 

date 顯示系統(tǒng)日期 
cal 2007 顯示2007年的日歷表 
date 041217002007.00 設(shè)置日期和時(shí)間 -月日時(shí)分年.秒 
clock -w 將時(shí)間修改保存到 BIOS 

文件搜索 
find / -name file1 從 '/'開(kāi)始進(jìn)入根文件系統(tǒng)搜索文件和目錄 

locate \*.ps 尋找以 '.ps'結(jié)尾的文件 -先運(yùn)行'updatedb'命令 
whereis halt 顯示一個(gè)二進(jìn)制文件、源碼或man的位置 
which halt 顯示一個(gè)二進(jìn)制文件或可執(zhí)行文件的完整路徑 

掛載一個(gè)文件系統(tǒng) 
mount /dev/hda2 /mnt/hda2 掛載一個(gè)叫做hda2的盤(pán)- 確定目錄'/ mnt/hda2' 已經(jīng)存在 
umount /dev/hda2 卸載一個(gè)叫做hda2的盤(pán)- 先從掛載點(diǎn)'/ mnt/hda2' 退出 

追加命令

1,linux里把文件/etc/aaa中的內(nèi)容追加到/usr/bbb中的內(nèi)容的后面
  sudo cat /etc/aaa >>/usr/bbb
2,更改/etc/index.html的文件所有者為apache,文件群組為apache
  sudo chmod apache:apache  /etc/index.html
3,更改/etc/index.html的所有者權(quán)限為讀取、寫(xiě)入、執(zhí)行。群組權(quán)限為讀取。其他權(quán)限為讀取
  sudo chmod 744 /etc/index.html
4，刪除/etc下名為hello的文件
  sudo rm /etc/index.html

當(dāng)然，如果你是以orot用戶執(zhí)行以上操作，可以去掉前邊的sudo！

df -hl 查看磁盤(pán)剩余空間

df -h 查看每個(gè)根路徑的分區(qū)大小

du -sh [目錄名] 返回該目錄的大小

du -sm [文件夾] 返回該文件夾總M數(shù)

關(guān)機(jī) (系統(tǒng)的關(guān)機(jī)、重啟以及登出) 
shutdown -h now 關(guān)閉系統(tǒng)(1) 
init 0 關(guān)閉系統(tǒng)(2) 
telinit 0 關(guān)閉系統(tǒng)(3) 
shutdown -h hour:minutes & 按預(yù)定時(shí)間關(guān)閉系統(tǒng) 
shutdown -c 取消按預(yù)定時(shí)間關(guān)閉系統(tǒng) 
shutdown -r now 重啟(1) 
reboot 重啟(2) 
logout 注銷

文件和目錄 
pwd 顯示工作路徑 
ls 查看目錄中的文件 
ls -F 查看目錄中的文件 
ls -l 顯示文件和目錄的詳細(xì)資料 
ls -a 顯示隱藏文件 
ls *[0-9]* 顯示包含數(shù)字的文件名和目錄名 
tree 顯示文件和目錄由根目錄開(kāi)始的樹(shù)形結(jié)構(gòu)(1) 
lstree 顯示文件和目錄由根目錄開(kāi)始的樹(shù)形結(jié)構(gòu)(2) 
mkdir dir1 創(chuàng)建一個(gè)叫做 'dir1'的目錄' 

磁盤(pán)空間 
df -h 顯示已經(jīng)掛載的分區(qū)列表 
ls -lSr |more 以尺寸大小排列文件和目錄 
du -sh dir1 估算目錄 'dir1'已經(jīng)使用的磁盤(pán)空間' 

下載、解壓

1)對(duì)于.tar結(jié)尾的文件 
　　tar -xf all.tar 

2)對(duì)于.gz結(jié)尾的文件 
　　gzip -d all.gz 
　　gunzip all.gz 

# zip all.zip *.jpg 
　　這條命令是將所有.jpg的文件壓縮成一個(gè)zip包 
# unzip all.zip 
　　這條命令是將all.zip中的所有文件解壓出來(lái)

下載命令

wget + 空格 +要下載文件的url路徑

=====================================

Shell 腳本：

必須以  #!/bin/sh  開(kāi)頭

簡(jiǎn)單例子：判斷這個(gè)目錄下有沒(méi)有文件（File）

#!/bin/bash
Num=`ls -al /opt |grep "^-"|wc -l `
if [ $Num != 0 ]
 then echo "/opt has $Num files"
else
 echo "/opt has none file"
fi

ls -al /opt |grep "^-"|wc -l  這個(gè)命令能夠統(tǒng)計(jì)文件個(gè)數(shù) 為0就是沒(méi)有文件 非零就是有文件

55..memcache緩存什么數(shù)據(jù)?

一、經(jīng)常被讀取并且實(shí)時(shí)性要求不強(qiáng)可以等到自動(dòng)過(guò)期的數(shù)據(jù)。例如網(wǎng)站首頁(yè)最新文章列表、某某排行等數(shù)據(jù)。
二、經(jīng)常被讀取并且實(shí)時(shí)性要求強(qiáng)的數(shù)據(jù)。比如用戶的好友列表，用戶文章列表，用戶閱讀記錄等。
三、統(tǒng)計(jì)類緩存，比如文章瀏覽數(shù)、網(wǎng)站PV等。
四、活躍用戶的基本信息或者某篇熱門(mén)文章。
五、session數(shù)據(jù)

56.魔術(shù)方法、魔術(shù)常量?

1。__construct()
實(shí)例化對(duì)象時(shí)被調(diào)用，當(dāng)__construct和以類名為函數(shù)名的函數(shù)同時(shí)存在時(shí)，__construct將被調(diào)用，另一個(gè)不被調(diào)用。
2。__destruct()
當(dāng)刪除一個(gè)對(duì)象或?qū)ο蟛僮鹘K止時(shí)被調(diào)用。
3。__call()
對(duì)象調(diào)用某個(gè)方法，若方法存在，則直接調(diào)用；若不存在，則會(huì)去調(diào)用__call函數(shù)。
4。__get()
讀取一個(gè)對(duì)象的屬性時(shí)，若屬性存在，則直接返回屬性值；若不存在，則會(huì)調(diào)用__get函數(shù)。
5。__set()
設(shè)置一個(gè)對(duì)象的屬性時(shí)，若屬性存在，則直接賦值；若不存在，則會(huì)調(diào)用__set函數(shù)。
6。__toString()
打印一個(gè)對(duì)象的時(shí)被調(diào)用。如echo $obj;或print $obj;
7。__clone()
克隆對(duì)象時(shí)被調(diào)用。如：$t=new Test();$t1=clone $t;
8。__sleep()
serialize之前被調(diào)用。若對(duì)象比較大，想刪減一點(diǎn)東東再序列化，可考慮一下此函數(shù)。
9。__wakeup()
unserialize時(shí)被調(diào)用，做些對(duì)象的初始化工作。
10。__isset()
檢測(cè)一個(gè)對(duì)象的屬性是否存在時(shí)被調(diào)用。如：isset($c->name)。
11。__unset()
unset一個(gè)對(duì)象的屬性時(shí)被調(diào)用。如：unset($c->name)。
12。__set_state()
調(diào)用var_export時(shí)，被調(diào)用。用__set_state的返回值做為var_export的返回值。
13。__autoload()
實(shí)例化一個(gè)對(duì)象時(shí)，如果對(duì)應(yīng)的類不存在，則該方法被調(diào)用。

魔術(shù)常量:

__LINE__
返回文件中的當(dāng)前行號(hào)。

__FILE__
返回文件的完整路徑和文件名。如果用在包含文件中，則返回包含文件名。自 PHP 4.0.2 起，__FILE__ 總是包含一個(gè)絕對(duì)路徑，而在此之前的版本有時(shí)會(huì)包含一個(gè)相對(duì)路徑。

__FUNCTION__
返回函數(shù)名稱（PHP 4.3.0 新加）。自 PHP 5 起本常量返回該函數(shù)被定義時(shí)的名字（區(qū)分大小寫(xiě)）。在PHP 4 中該值總是小寫(xiě)字母的。

__CLasS__
返回類的名稱（PHP 4.3.0 新加）。自 PHP 5 起本常量返回該類被定義時(shí)的名字（區(qū)分大小寫(xiě)）。在PHP 4 中該值總是小寫(xiě)字母的。

__METHOD__
返回類的方法名（PHP 5.0.0 新加）。返回該方法被定義時(shí)的名字（區(qū)分大小寫(xiě)）。

__set()當(dāng)程序試圖寫(xiě)入一個(gè)不存在或者不可見(jiàn)的成員變量時(shí)，__set()方法包含兩個(gè)參數(shù)，分別表示變量名稱和變量值，兩個(gè)參數(shù)都不可省略

__get()當(dāng)程序試圖調(diào)用一個(gè)未定義或不可見(jiàn)的成員變量時(shí)，__get()方法有一個(gè)參數(shù)，表示要調(diào)用的變量名

__sleep() 常用于提交未提交的數(shù)據(jù)，或類似的清理操作如果有一些很大的對(duì)象，但不需要全部保存，這個(gè)功能就很好用。

__construct()  在類實(shí)例化對(duì)象的同時(shí)執(zhí)行該函數(shù)

__distruct() 在類實(shí)例化的對(duì)象銷毀時(shí)執(zhí)行

__call()對(duì)象調(diào)用某個(gè)方法，若方法存在，則直接調(diào)用；若不存在，則會(huì)去調(diào)用__call函數(shù)。

__clone()克隆對(duì)象時(shí)被調(diào)用。如：$t=new Test();$t1=clone $t;

__toString()打印一個(gè)對(duì)象的時(shí)被調(diào)用。如echo $obj;或print $obj;

__isset()檢測(cè)一個(gè)對(duì)象的屬性是否存在時(shí)被調(diào)用。如：isset($c->name)。

__unset()unset一個(gè)對(duì)象的屬性時(shí)被調(diào)用。如：unset($c->name)。

__autoload()實(shí)例化一個(gè)對(duì)象時(shí)，如果對(duì)應(yīng)的類不存在，則該方法被調(diào)用。

57.接口和抽象類的區(qū)別是什么？

答:抽象類是一種不能被實(shí)例化的類，只能作為其他類的父類來(lái)使用。抽象類是通過(guò)關(guān)鍵字abstract來(lái)聲明的。?

抽象類與普通類相似，都包含成員變量和成員方法，兩者的區(qū)別在于，抽象類中至少要包含一個(gè)抽象方法，抽象方法沒(méi)有方法體，該方法天生就是要被子類重寫(xiě)的。?

抽象方法的格式為：abstract function abstractMethod();

接口是通過(guò) interface 關(guān)鍵字來(lái)聲明的，接口中的成員常量和方法都是 public 的，方法可以不寫(xiě)關(guān)鍵字public，接口中的方法也是沒(méi)有方法體。接口中的方法也天生就是要被子類實(shí)現(xiàn)的。?

抽象類和接口實(shí)現(xiàn)的功能十分相似，最大的不同是接口能實(shí)現(xiàn)多繼承。在應(yīng)用中選擇抽象類還是接口要看具體實(shí)現(xiàn)。?

子類繼承抽象類使用 extends，子類實(shí)現(xiàn)接口使用implements。

58.什么是隊(duì)列？排它鎖，Myisam死鎖如何解決？

答:在默認(rèn)情況下MYisam是表級(jí)鎖，所以同時(shí)操作單張表的多個(gè)動(dòng)作只能以隊(duì)列的方式進(jìn)行；

排它鎖又名寫(xiě)鎖，在SQL執(zhí)行過(guò)程中為排除其它請(qǐng)求而寫(xiě)鎖，在執(zhí)行完畢后會(huì)自動(dòng)釋放；

死鎖解決：先找到死鎖的線程號(hào)，然后殺掉線程ID

59.bootstrap框架有哪些優(yōu)點(diǎn)?

答:bootstrap是一款web開(kāi)發(fā)框架,它由CSS,JavaScript,Html,三部分構(gòu)成,它簡(jiǎn)潔靈活,使得web開(kāi)發(fā)更加的快捷

優(yōu)點(diǎn):?

① 時(shí)間の節(jié)約: ブートストラップ フレームワークを使用すると、プロジェクトの開(kāi)発時(shí)間を大幅に節(jié)約できます。これを使用する必要がある場(chǎng)合は、適切なコードを見(jiàn)つけて適切な位置に挿入するだけです。さらに、CSS が使用され、LESS で書(shū)かれ、多くのスタイルとデザインが設(shè)計(jì)されています

② カスタマイズ: ブートストラップは、獨(dú)自のプロジェクトに応じてフレームワークの必要な部分を保持できます

③合理的なデザイン:

グリッド システム: ブートストラップは 12 グリッド システムを定義します。ページが完成したら、適切なグリッドに従って行數(shù)とレイアウト サイズを変更できます。適切な HTML コードの位置を入力するだけです。

LESS: LESS は、CSS 開(kāi)発をより柔軟かつ強(qiáng)力にすることを目的としています##。

#JavaScript: ブートストラップは、基本的なアーキテクチャとスタイルを超えた JavaScript ライブラリを提供します。これにより、開(kāi)発者は、スクリプトの作成に時(shí)間と労力を費(fèi)やす必要がなくなります。

##4. 一貫性: ブートストラップはインターフェイスの一貫性を保証します。IE、Chrome など、さまざまなプラットフォームの統(tǒng)一性を確保します。

5. ブートストラップは常に改善されており、より定期的で持続可能な

6. 応答性: PC とモバイル端末の両方でインターフェイスの一貫性を維持できる

7. 多くのドキュメント: 多くのブートストラップがあります##。 #