PHP之面試題總結

　　總結一些面試題,有備無患,走起...

　　1.熟悉的 nosql 和 sql 有什麼區別（優點，劣勢）

?

1 2 3 4

Memcache，Redis 都是內存數據庫 redis是一個開源的支持多種數據類型的key=>value的存儲數據庫。支持字符串、列表、集合、有序集合、哈希五種類型 memcache 只支持簡單的key/value數據結構，不像Redis能夠支持豐富的數據類型。 沒法進行持久化，數據不能備份，只能用於緩存使用，且重啓後數據所有丟失

　　2.實現PHP5中的 var_dump 函數

?

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88

<?php   function mydump() {          $args   = func_num_args();          for ($i = 0;$i < $args; $i ++) {              $param = func_get_arg($i);              switch (gettype($param)) {                  case 'NULL' :                      echo 'NULL' ;                      break ;                  case 'boolean' :                      echo ($param ? 'bool(true)' : 'bool(false)' );                      break ;                  case 'integer' :                      echo "int($param)" ;                      break ;                  case 'double' :                      echo "float($param)" ;                      break ;                  case 'string' :                      dumpString($param);                      break ;                  case 'array' :                      dumpArr($param);                      break ;                  case 'object' :                      dumpObj($param);                      break ;                  case 'resource' :                      echo 'resource' ;                      break ;                  default :                      echo 'UNKNOWN TYPE' ;                      break ;              }          }      }     function dumpString($param) {      $str = sprintf( "string(%d) %s" ,strlen($param),$param);      echo $str; }   function dumpArr($param) {      $len = count($param);      echo "array($len) {\r\n" ;      foreach ($param as $key=>$val) {          if (is_array($val)) {              dumpArr($val);          } else {              echo sprintf( '["%s"] => %s(%s)' ,$key,gettype($val),$val);          }      }      echo "}\r\n" ; }   function dumpObj($param) {      $className = get_class($param);      $reflect = new ReflectionClass($param);      $prop = $reflect->getDefaultProperties();      echo sprintf( "Object %s #1(%d) {\r\n" ,$className,count($prop));      foreach ($prop as $key=>$val) {          echo "[\"$key\"] => " ;          mydump($val);      }      echo "}" ; }   class MyClass {      protected $_name;      function test()      {          echo "hello" ;      } }   $str    = "test" ; mydump( new MyClass(),$str); echo "\r\n" ; $arr2   = array(      "1"     => "Ddaddad" ,      "one"   => array( "two" => "Dddd" ),      "three" => 1 ); mydump($arr2); mydump(1, true , null );

　　3. 獲取上週一和週日的日期

?

1 2 3

echo date( 'Y-m-d' ,strtotime( 'monday last week' )); //上週一<br>echo date('Y-m-d', strtotime('-' . (6+date('w')) . ' days'));   echo date( 'Y-m-d' ,strtotime( 'sunday last week' )); //上週日

　　4. 對數組實現去除空元素 排重 按值從大到小排序 從新創建數字索引

$data = array_unique( array_filter($data) ) ;
rsort($data);
array_values($data);

　　5. 寫一個shell命令 實現找出全部包含 spread的進程，殺死這些進程並記錄日誌，日誌包含殺死進程名稱和殺死進程的時間

 

ps -ef |grep spread |grep -v grep |awk '{print $2}'|xargs kill -9
kill -9 $(ps -ef | grep spread| grep -v grep | awk '{print $2}')

　　6. 寫出你知道的http頭部屬性 注意大小寫 並說明用途

?

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

Accept 指定客戶端可以接收的內容類型 Accept: text/plain, text/html Accept-Charset 瀏覽器能夠接受的字符編碼集。 Accept-Charset: iso-8859-5 Accept-Encoding 指定瀏覽器能夠支持的web服務器返回內容壓縮編碼類型。 Accept-Encoding: compress, gzip Accept-Language 瀏覽器可接受的語言 Accept-Language: en,zh Accept-Ranges 能夠請求網頁實體的一個或者多個子範圍字段 Accept-Ranges: bytes Authorization HTTP受權的受權證書 Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== Cache-Control 指定請求和響應遵循的緩存機制 Cache-Control: no-cache Connection 表示是否須要持久鏈接。（HTTP 1.1默認進行持久鏈接） Connection: close Cookie HTTP請求發送時，會把保存在該請求域名下的全部cookie值一塊兒發送給web服務器。 Cookie: $Version=1; Skin= new ; Content-Length 請求的內容長度 Content-Length: 348 Content-Type 請求的與實體對應的MIME信息 Content-Type: application/x-www-form-urlencoded Date 請求發送的日期和時間 Date: Tue, 15 Nov 2010 08:12:31 GMT Expect 請求的特定的服務器行爲 Expect: 100- continue From 發出請求的用戶的Email From: user@email.com Host 指定請求的服務器的域名和端口號 Host: www.zcmhi.com If-Match 只有請求內容與實體相匹配纔有效 If-Match: 「737060cd8c284d8af7ad3082f209582d」 If-Modified-Since 若是請求的部分在指定時間以後被修改則請求成功，未被修改則返回304代碼 If-Modified-Since: Sat, 29 Oct 2010 19:43:31 GMT If-None-Match 若是內容未改變返回304代碼，參數爲服務器先前發送的Etag，與服務器迴應的Etag比較判斷是否改變 If-None-Match: 「737060cd8c284d8af7ad3082f209582d」 If-Range 若是實體未改變，服務器發送客戶端丟失的部分，不然發送整個實體。參數也爲Etag If-Range: 「737060cd8c284d8af7ad3082f209582d」 If-Unmodified-Since 只在實體在指定時間以後未被修改才請求成功 If-Unmodified-Since: Sat, 29 Oct 2010 19:43:31 GMT Max-Forwards 限制信息經過代理和網關傳送的時間 Max-Forwards: 10 Pragma 用來包含實現特定的指令 Pragma: no-cache Proxy-Authorization 鏈接到代理的受權證書 Proxy-Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== Range 只請求實體的一部分，指定範圍 Range: bytes=500-999 Referer 先前網頁的地址，當前請求網頁緊隨其後,即來路 Referer: http: //www.zcmhi.com/archives... TE 客戶端願意接受的傳輸編碼，並通知服務器接受接受尾加頭信息 TE: trailers,deflate;q=0.5 Upgrade 向服務器指定某種傳輸協議以便服務器進行轉換（若是支持） Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 User-Agent User-Agent的內容包含發出請求的用戶信息 User-Agent: Mozilla/5.0 (Linux; X11) Via 通知中間網關或代理服務器地址，通訊協議 Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1) Warning 關於消息實體的警告信息 Warn: 199 Miscellaneous warning

　　7. 寫出 shell命令 統計 ip出現的次數 結果相似

awk '{arr[$1]++;}END{for(i in arr){print i , arr[i] }}' test.txt

　　8. 如何實現一個數組[1,2,3]連續複製3次變爲[1,2,3,1,2,3,1,2,3]

 　

?

1 2 3 4 5 6 7 8 9 10

$arr=[1,2,3];   1)  print_r(f($arr,3)); function f($arr,$num){      return array_filter(explode( ',' ,str_repeat(implode( ',' ,$arr). ',' ,$num))); }   2) print_r( array_merge($arr,$arr,$arr) );

　　效率對比:

?

1 2 3 4 5 6 7 8 9 10 11 12

$arr1 = [111,222,333]; $t1 =microtime( true ); array_merge($arr1,$arr1,$arr1); //索引數組不會合並,而是追加到後面 $t2 = microtime( true ); array_filter(explode( ',' ,str_repeat(implode( ',' ,$arr1). ',' ,3) ) ); $t3 = microtime( true );   echo '第一種方式耗時:' .number_format($t2-$t1,10).PHP_EOL; echo '第一種方式耗時:' .number_format($t3-$t2,10).PHP_EOL;   第一種方式耗時:0.0000860691 第一種方式耗時:0.0001721382

　　9. 請簡述一下數據庫的優化?

?

1 2 3 4

1.從結構層: web服務器採用負載均衡服務器,mysql服務器採用主從複製,讀寫分離 2.從儲存層: 採用合適的存儲引擎,採用三範式 3.從設計層: 採用分區分表,索引,表的字段採用合適的字段屬性,適當的採用逆範式,開啓mysql緩存 4.sql語句層:結果同樣的狀況下,採用效率高,速度快節省資源的sql語句執行

　　10. 如何解決異常處理?

?

1 2 3

拋出異常:使用 try … catch ，異常的代碼放在 try 代碼塊內，若是沒有觸發異常，則代碼繼續執行，若是異常被觸發，就會 拋出一個異常。Catch代碼塊捕獲異常，並建立一個包含異常信息的對象。$e->getMessage()，輸出異常的錯誤信息。   解決異常:使用set_error_handler函數獲取異常(也可使用 try ()和 catch ()函數),而後使用set_exception_handler()函數設置默認的異常處理程序,register_shutdown_function()函數來執行,執行機制是,php要把調入的函數調入到內存,當頁面全部的php語句都執行完成時,再調用此函數

　　11. 怎麼保證促銷商品不會超賣?

?

1 2 3 4 5 6 7 8 9

這個問題是咱們當時開發時遇到的一個難點，超賣的緣由主要是下的訂單的數目和咱們要促銷的商品的數目不一致致使的，每次老是訂單的數比咱們的促銷商品的數目要多，當時咱們的小組討論了很久，給出了好幾個方案來實現：   第一種方案：在每次下訂單前咱們判斷促銷商品的數量夠不夠，不夠不容許下訂單，更改庫存量時加上一個條件，只更改商品庫存大於0的商品的庫存，當時咱們使用ab進行壓力測試，當併發超過500，訪問量超過2000時，仍是會出現超賣現象。因此被咱們否認了。   第二種方案：使用mysql的事務加排他鎖來解決，首先咱們選擇數據庫的存儲引擎爲innoDB，使用的是排他鎖實現的，剛開始的時候咱們測試了下共享鎖，發現仍是會出現超賣的現象。有個問題是，當咱們進行高併發測試時，對數據庫的性能影響很大，致使數據庫的壓力很大，最終也被咱們否認了。   第三種方案：使用文件鎖實現。當用戶搶到一件促銷商品後先觸發文件鎖，防止其餘用戶進入，該用戶搶到促銷品後再解開文件鎖，放其餘用戶進行操做。這樣能夠解決超賣的問題，可是會致使文件得I/O開銷很大。   最後咱們使用了redis的隊列來實現。將要促銷的商品數量以隊列的方式存入redis中，每當用戶搶到一件促銷商品則從隊列中刪除一個數據，確保商品不會超賣。這個操做起來很方便，並且效率極高，最終咱們採起這種方式來實現

　　12. redis消息隊列先進先出須要注意什麼?

?

1 2 3 4 5 6 7 8 9 10 11 12

一般使用一個list來實現隊列操做，這樣有一個小限制，因此的任務統一都是先進先出，若是想優先處理某個任務就不太好處理了，這就須要讓隊列有優先級的概念，咱們就能夠優先處理高級別的任務，實現方式有如下幾種方式：   1）單一列表實現：隊列正常的操做是 左進右出（lpush,rpop）爲了先處理高優先級任務，在遇到高級別任務時，能夠直接插隊，直接放入隊列頭部（rpush），這樣，從隊列頭部（右側）獲取任務時，取到的就是高優先級的任務（rpop）   2）使用兩個隊列，一個普通隊列，一個高級隊列，針對任務的級別放入不一樣的隊列，獲取任務時也很簡單，redis的BRPOP命令能夠按順序從多個隊列中取值，BRPOP會按照給出的 key 順序查看，並在找到的第一個非空 list 的尾部彈出一個元素，redis> BRPOP list1 list2 0     list1 作爲高優先級任務隊列 list2 作爲普通任務隊列 這樣就實現了先處理高優先級任務，當沒有高優先級任務時，就去獲取普通任務 方式1最簡單，但實際應用比較侷限 方式2是推薦用法，實際應用最爲合適

　　13. 接口安全方面是怎麼處理的?

?

1 2	咱們當時是這麼作的，使用HTTP的POST方式,對固定參數+附加參數進行數字簽名,使用的是md5加密,好比:我想經過標題獲取一個信息,在客戶端使用 信息標題+日期+雙方約定好的一個key經過md5加密生成一個簽名(sign),而後做爲參數傳遞到服務器端,服務器端使用一樣的方法進行校驗,如何接受過來的sign和咱們經過算法算的值相同，證實是一個正常的接口請求，咱們纔會返回相應的接口數據。 也可使用RSA加密

　　14.寫過接口嗎，怎麼定義接口的?

?

1 2 3 4 5 6 7

寫過。接口分爲兩種：一種是數據型接口，一種是應用型接口。   數據型接口：是比抽象類更抽象的某種「結構」——它其實不是類，可是跟類同樣的某種語法結構，是一種結構規範，規範咱們類要以什麼格式進行定義，通常用於團隊比較大，分支比較多的狀況下使用。   應用型接口： API（application interface ） 數據對外訪問的一個入口   我主要是參與的APP開發中接口的編寫，客戶端須要什麼樣的數據，咱們就給他們提供相應的數據，數據以json/xml的格式返回，而且配以相應的接口文檔。

　　15. sku減庫存?

?

1 2 3 4 5

SKU = Stock Keeping Unit (庫存量單位) 即庫存進出計量的單位，能夠是以件，盒，托盤等爲單位。SKU是庫存量單位，區分單品。 在服裝、鞋類商品中使用最多最廣泛。 例如紡織品中一個SKU一般表示：規格、顏色、款式。   在設計表時，不只僅只有商品表，商品表中有個總庫存，咱們還須要涉及一張SKU表，裏面有SKU庫存和單價字段，用戶每購買一件商品，實際上購買的都是SKU商品，這樣在下訂單成功後，應該根據所購買的商品的惟一的SKU號來進行相應的SKU庫存的減小，固然商品的總庫存保存在商品主表中，也須要減小總庫存中的庫存量。

　　16. 庫存設置？

?

1	庫存分爲商品總庫存和SKU庫存，每每商品總庫存的爲SKU庫存的總和。通常在商城的後臺對貨品設置最高庫存及最低庫存後，當前庫存數量與最高、最低二者比較，超出庫存或者低於庫存的，則被統計成報表形式反映，便於用戶掌握貨品庫存超、短缺狀態及數量。

　　17. Redis如何防止高併發

?

1 2 3 4 5 6 7 8 9 10 11 12

其實redis是不會存在併發問題的，由於他是單進程的，再多的命令都是一個接一個地執行的。咱們使用的時候，可能會出現併發問題，好比得到和設定這一對。Redis的爲何 有高併發問題？Redis的的出身決定 Redis是一種單線程機制的nosql數據庫，基於key-value，數據可持久化落盤。因爲單線程因此redis自己並無鎖的概念，多個客戶端鏈接並不存在競爭關係，可是利用jedis等客戶端對redis進行併發訪問時會出現問題。發生鏈接超時、數據轉換錯誤、阻塞、客戶端關閉鏈接等問題，這些問題均是因爲客戶端鏈接混亂形成。   同時，單線程的天性決定，高併發對同一個鍵的操做會排隊處理，若是併發量很大，可能形成後來的請求超時。   在遠程訪問redis的時候，由於網絡等緣由形成高併發訪問延遲返回的問題。   解決辦法   在客戶端將鏈接進行池化，同時對客戶端讀寫Redis操做採用內部鎖synchronized。   服務器角度，利用setnx變向實現鎖機制。

　　18. 支付寶流程怎麼實現的?

?

1	首先要有一個支付寶帳號，接下來向支付寶申請在線支付業務，簽署協議。協議生效後有支付寶一方會給網站方一個合做夥伴ID,和安全校驗碼，有了這兩樣東西就能夠按照支付寶接口文檔開發支付寶接口了，中間主要涉及到一個安全問題。整個流程是這樣的：咱們的網站經過post傳遞相應的參數（如訂單總金額，訂單號）到支付頁面，支付頁面把一系列的參數通過處理，以post的方式提交給支付寶服務器，支付寶服務器進行驗證，並對接收的數據進行處理，把處理後的結果返回給咱們網站設置的異步和同步回調地址，經過相應的返回參數，來處理相應的業務邏輯，好比返回的參數表明支付成功，更改訂單狀態。

　　19. 怎麼實現第三方登陸？

?

1 2 3 4 5 6

第三方登錄主要是基於author協議來實現，下面簡單說下實現流程:      一、首先咱們須要以開發者的身份向第三方登錄平臺申請接入應用，申請成功後，咱們會得到一個appID和一個secrectID.      二、當咱們的網站需接入第三方登錄時，會引導用戶跳轉到第三方的登錄受權頁面，此時把以前申請的appID和secrectID帶給登錄受權頁面。      三、用戶登錄成功後即獲得受權，第三方會返回一個臨時的code給咱們的網站。      四、咱們的網站接受到code後，再次向咱們的第三方發起請求，並攜帶接收的code,從第三方獲取access_token.      五、第三方處理請求後，會返回一個access_token給咱們的網站，咱們的網站獲取到access_token後就能夠調用第三方提供的接口了，好比獲取用戶信息等。最後把該用戶信息存入到咱們站點的數據庫，並把信息保存到session中，實現用戶的第三方登錄

　　20. 如何處理負載、高併發？

?

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96

從低成本、高性能和高擴張性的角度來講有以下處理方案：   一、HTML靜態化   其實你們都知道，效率最高、消耗最小的就是純靜態化的html頁面，因此咱們儘量使咱們的 網站上的頁面採用靜態頁面來實現，這個最簡單的方法其實也是最有效的方法。   二、圖片服務器分離   把圖片單獨存儲，儘可能減小圖片等大流量的開銷，能夠放在一些相關的平臺上，如騎牛等   三、數據庫集羣和庫表散列及緩存   數據庫的併發鏈接爲100，一臺數據庫遠遠不夠，能夠從讀寫分離、主從複製，數據庫集羣方面來着手。另外儘可能減小數據庫的訪問，可使用緩存數據庫如memcache、redis。   四、鏡像：   儘可能減小下載，能夠把不一樣的請求分發到多個鏡像端。   五、負載均衡：   Apache的最大併發鏈接爲1500，只能增長服務器，能夠從硬件上着手，如F5服務器。固然硬件的成本比較高，咱們每每從軟件方面着手。   負載均衡 （Load Balancing） 創建在現有網絡結構之上，它提供了一種廉價有效透明的方法擴展網絡設備和服務器的帶寬、增長吞吐量、增強網絡數據處理能力，同時可以提升網絡的靈活性和可用性。目前使用最爲普遍的負載均衡軟件是Nginx、LVS、HAProxy。我分別來講下三種的優缺點:   Nginx的優勢是：        工做在網絡的7層之上，能夠針對http應用作一些分流的策略，好比針對域名、目錄結構，它的正則規則比HAProxy更爲強大和靈活，這也是它目前普遍流行的主要緣由之一，Nginx單憑這點可利用的場合就遠多於LVS了。        Nginx對網絡穩定性的依賴很是小，理論上能ping通就就能進行負載功能，這個也是它的優點之一；相反LVS對網絡穩定性依賴比較大，這點本人深有體會；        Nginx安裝和配置比較簡單，測試起來比較方便，它基本能把錯誤用日誌打印出來。LVS的配置、測試就要花比較長的時間了，LVS對網絡依賴比較大。        能夠承擔高負載壓力且穩定，在硬件不差的狀況下通常能支撐幾萬次的併發量，負載度比LVS相對小些。        Nginx能夠經過端口檢測到服務器內部的故障，好比根據服務器處理網頁返回的狀態碼、超時等等，而且會把返回錯誤的請求從新提交到另外一個節點，不過其中缺點就是不支持url來檢測。好比用戶正在上傳一個文件，而處理該上傳的節點恰好在上傳過程當中出現故障，Nginx會把上傳切到另外一臺服務器從新處理，而LVS就直接斷掉了，若是是上傳一個很大的文件或者很重要的文件的話，用戶可能會所以而不滿。        Nginx不只僅是一款優秀的負載均衡器/反向代理軟件，它同時也是功能強大的Web應用服務器。LNMP也是近幾年很是流行的web架構，在高流量的環境中穩定性也很好。        Nginx如今做爲Web反向加速緩存愈來愈成熟了，速度比傳統的Squid服務器更快，能夠考慮用其做爲反向代理加速器。        Nginx可做爲中層反向代理使用，這一層面Nginx基本上無對手，惟一能夠對比Nginx的就只有 lighttpd了，不過 lighttpd目前尚未作到Nginx徹底的功能，配置也不那麼清晰易讀，社區資料也遠遠沒Nginx活躍。        Nginx也可做爲靜態網頁和圖片服務器，這方面的性能也無對手。還有Nginx社區很是活躍，第三方模塊也不少。   Nginx的缺點是：        Nginx僅能支持http、https和Email協議，這樣就在適用範圍上面小些，這個是它的缺點。      對後端服務器的健康檢查，只支持經過端口來檢測，不支持經過url來檢測。不支持Session的直接保持，但能經過ip_hash來解決。   LVS：使用Linux內核集羣實現一個高性能、高可用的負載均衡服務器，它具備很好的可伸縮性（Scalability)、可靠性（Reliability)和可管理性（Manageability)。   LVS的優勢是：        抗負載能力強、是工做在網絡4層之上僅做分發之用，沒有流量的產生，這個特色也決定了它在負載均衡軟件裏的性能最強的，對內存和cpu資源消耗比較低。      配置性比較低，這是一個缺點也是一個優勢，由於沒有可太多配置的東西，因此並不須要太多接觸，大大減小了人爲出錯的概率。      工做穩定，由於其自己抗負載能力很強，自身有完整的雙機熱備方案，如LVS+Keepalived，不過咱們在項目實施中用得最多的仍是LVS/DR+Keepalived。      無流量，LVS只分發請求，而流量並不從它自己出去，這點保證了均衡器IO的性能不會受到大流量的影響。      應用範圍比較廣，由於LVS工做在4層，因此它幾乎能夠對全部應用作負載均衡，包括http、數據庫、在線聊天室等等。   LVS的缺點是：        軟件自己不支持正則表達式處理，不能作動靜分離；而如今許多網站在這方面都有較強的需求，這個是Nginx/HAProxy+Keepalived的優點所在。      若是是網站應用比較龐大的話，LVS/DR+Keepalived實施起來就比較複雜了，特別後面有 Windows Server的機器的話，若是實施及配置還有維護過程就比較複雜了，相對而言，Nginx/HAProxy+Keepalived就簡單多了。   HAProxy的特色是：        HAProxy也是支持虛擬主機的。      HAProxy的優勢可以補充Nginx的一些缺點，好比支持Session的保持，Cookie的引導；同時支持經過獲取指定的url來檢測後端服務器的狀態。      HAProxy跟LVS相似，自己就只是一款負載均衡軟件；單純從效率上來說HAProxy會比Nginx有更出色的負載均衡速度，在併發處理上也是優於Nginx的。      HAProxy支持TCP協議的負載均衡轉發，能夠對MySQL讀進行負載均衡，對後端的MySQL節點進行檢測和負載均衡，你們能夠用LVS+Keepalived對MySQL主從作負載均衡。      HAProxy負載均衡策略很是多，HAProxy的負載均衡算法如今具體有以下8種：   ① roundrobin，表示簡單的輪詢，這個很少說，這個是負載均衡基本都具有的； ② static -rr，表示根據權重，建議關注； ③ leastconn，表示最少鏈接者先處理，建議關注； ④ source，表示根據請求源IP，這個跟Nginx的IP_hash機制相似，咱們用其做爲解決session問題的一種方法，建議關注； ⑤ ri，表示根據請求的URI； ⑥ rl_param，表示根據請求的URl參數’balance url_param’ requires an URL parameter name； ⑦ hdr(name)，表示根據HTTP請求頭來鎖定每一次HTTP請求； ⑧ rdp-cookie(name)，表示根據據cookie(name)來鎖定並哈希每一次TCP請求。   Nginx和LVS對比的總結：        Nginx工做在網絡的7層，因此它能夠針對http應用自己來作分流策略，好比針對域名、目錄結構等，相比之下LVS並不具有這樣的功能，因此Nginx單憑這點可利用的場合就遠多於LVS了；但Nginx有用的這些功能使其可調整度要高於LVS，因此常常要去觸碰觸碰，觸碰多了，人爲出問題的概率也就會大。        Nginx對網絡穩定性的依賴較小，理論上只要ping得通，網頁訪問正常，Nginx就能連得通，這是Nginx的一大優點！Nginx同時還能區份內外網，若是是同時擁有內外網的節點，就至關於單機擁有了備份線路；LVS就比較依賴於網絡環境，目前來看服務器在同一網段內而且LVS使用direct方式分流，效果較能獲得保證。另外注意，LVS須要向託管商至少申請多一個ip來作Visual IP，貌似是不能用自己的IP來作VIP的。要作好LVS管理員，確實得跟進學習不少有關網絡通訊方面的知識，就再也不是一個HTTP那麼簡單了。        Nginx安裝和配置比較簡單，測試起來也很方便，由於它基本能把錯誤用日誌打印出來。LVS的安裝和配置、測試就要花比較長的時間了；LVS對網絡依賴比較大，不少時候不能配置成功都是由於網絡問題而不是配置問題，出了問題要解決也相應的會麻煩得多。        Nginx也一樣能承受很高負載且穩定，但負載度和穩定度差LVS還有幾個等級：Nginx處理全部流量因此受限於機器IO和配置；自己的bug也仍是難以免的。        Nginx能夠檢測到服務器內部的故障，好比根據服務器處理網頁返回的狀態碼、超時等等，而且會把返回錯誤的請求從新提交到另外一個節點。目前LVS中 ldirectd也能支持針對服務器內部的狀況來監控，但LVS的原理使其不能重發請求。好比用戶正在上傳一個文件，而處理該上傳的節點恰好在上傳過程當中出現故障，Nginx會把上傳切到另外一臺服務器從新處理，而LVS就直接斷掉了，若是是上傳一個很大的文件或者很重要的文件的話，用戶可能會所以而惱火。        Nginx對請求的異步處理能夠幫助節點服務器減輕負載，假如使用 apache直接對外服務，那麼出現不少的窄帶連接時apache服務器將會佔用大 量內存而不能釋放，使用多一個Nginx作apache代理的話，這些窄帶連接會被Nginx擋住，apache上就不會堆積過多的請求，這樣就減小了至關多的資源佔用。這點使用squid也有相同的做用，即便squid自己配置爲不緩存，對apache仍是有很大幫助的。        Nginx能支持http、https和email（email的功能比較少用），LVS所支持的應用在這點上會比Nginx更多。在使用上，通常最前端所採起的策略應是LVS，也就是DNS的指向應爲LVS均衡器，LVS的優勢令它很是適合作這個任務。重要的ip地址，最好交由LVS託管，好比數據庫的 ip、webservice服務器的ip等等，這些ip地址隨着時間推移，使用面會愈來愈大，若是更換ip則故障會接踵而至。因此將這些重要ip交給 LVS託管是最爲穩妥的，這樣作的惟一缺點是須要的VIP數量會比較多。Nginx可做爲LVS節點機器使用，一是能夠利用Nginx的功能，二是能夠利用Nginx的性能。固然這一層面也能夠直接使用squid，squid的功能方面就比Nginx弱很多了，性能上也有所遜色於Nginx。Nginx也可做爲中層代理使用，這一層面Nginx基本上無對手，惟一能夠撼動Nginx的就只有lighttpd了，不過lighttpd目前尚未能作到 Nginx徹底的功能，配置也不那麼清晰易讀。另外，中層代理的IP也是重要的，因此中層代理也擁有一個VIP和LVS是最完美的方案了。具體的應用還得具體分析，若是是比較小的網站（日PV小於1000萬），用Nginx就徹底能夠了，若是機器也很多，能夠用DNS輪詢，LVS所耗費的機器仍是比較多的；大型網站或者重要的服務，機器不發愁的時候，要多多考慮利用LVS。

 

　　21. 封裝過一個簡單的框架?

?

1	封裝過一個簡單的MVC框架,主要分爲3層，控制器層和模型層視圖層，以及路由的分配和入口文件，模板引擎，單例模式、工廠模式，第三方類庫的引入等。

　　22. 索引的優缺點?

?

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

優勢:      a）能夠保證數據庫表中每一行的數據的惟一性      b）能夠大大加快數據的索引速度      c）加速表與表之間的鏈接，物別是在實現數據的參考完事性方面特別有意義      d）在使用分組和排序子句進行數據檢索時，一樣能夠顯著減小查詢中分組和排序的時間      f）經過使用索引，能夠在時間查詢的過程當中，使用優化隱藏器，提升系統的性能 缺點:      a) 建立索引和維護索引要耗費時間，這種時間隨着數據量的增長而增長      b) 索引須要佔物理空間，除了數據表佔用數據空間以外，每個索引還要佔用必定的物理空間，若是須要創建聚簇索引，那麼須要佔用的空間會更大      c) 以表中的數據進行增、刪、改的時候，索引也要動態的維護，這就下降了整數的維護速度      d) 創建索引的原則      e) 在常常須要搜索的列上，能夠加快搜索的速度 f) 在做爲主鍵的列上，強制該列的惟一性和組織表中數據的排列結構      g) 在常常用在鏈接的列上，這些列主要是一外鍵，能夠加快鏈接的速度      h) 在經常常須要根據範圍進行搜索的列上建立索引，國爲索引已經排序，其指定的範圍是連續的      i) 在常常須要排序的列上，國爲索引已經排序，這樣井底能夠利用索引的排序，加快排序井底時間      j) 在常用在 where 子句中的列上，加快條件的判斷速度