盛大公司PHP面試題

無筆試。重點(diǎn)看問題

談?wù)動^察者模式是什么？主要應(yīng)用。

答：類似會有一些server對象時(shí)刻偵聽某個(gè)對象的一些動作。被監(jiān)聽的對象也會有這個(gè)server列表，或者提供添加列表的接口。促發(fā)條件根據(jù)需 求。觸發(fā)的時(shí)候這個(gè)object對象會發(fā)送本身給這些server列表中的一個(gè)方法里，這樣server也就會取得傳過來的對象實(shí)現(xiàn)偵聽。主要應(yīng)用在插件 上的。

什么是索引？建立索引有什么規(guī)則？注意點(diǎn)？

答：類似一種目錄表吧，dbms會實(shí)現(xiàn)讀寫，mysql在查詢的時(shí)候，可以直接去查找這個(gè)目錄表，就不會去掃描整個(gè)表了。有什么注意點(diǎn)嘛？首先我會 看這個(gè)表，如果他生來就注定寫多讀少，盡量避免建立很多索引，因?yàn)樗矔加脮r(shí)間，對吧！另外在建立的時(shí)候我也會盡量建立在數(shù)字字段上，或者類似用戶名 上，這樣做可能，在需求上作select時(shí)候不會有l(wèi)ike或者其他計(jì)算在里面。也不要有！有的話，不要放在左值上。。。被打斷！

其實(shí)我想問是放在查詢語句，select什么什么where什么什么的什么地方？

答：哦，放在where后字段上。

Mysql有幾種引擎？或者你經(jīng)常使用哪幾個(gè)？

答：innodB，myisam，temporary（當(dāng)時(shí)愣是沒讀上來這個(gè)單詞，就拼寫了）

innodB和myisam有什么區(qū)別？temporary你經(jīng)常用在什么地方。

答：一個(gè)是行鎖，一個(gè)是表鎖，這樣并發(fā)程度也就不一樣了。innodB有日志，然后就能現(xiàn)實(shí)事務(wù)保證，他也能實(shí)現(xiàn)外鍵功能。Myisam在查詢上快 點(diǎn)。文件方面。Myisam放有三個(gè)文件，在同一的目錄中，數(shù)據(jù)也會放在其中一個(gè)上。而innodB的數(shù)據(jù)是放在目錄外的idata文件中。innodB 也能實(shí)現(xiàn)這個(gè)idata文件大小的配置，比如可以配置最大為1G，到了這個(gè)大小，mysql會自動生成另一個(gè)idata文件。Temporary我會用在 類似用戶登錄的session表上。

你有沒有想過為什么innodB要把數(shù)據(jù)提到一個(gè)文件中了？而不是想myisam放在自己的文件中？

答：這個(gè)嘛。。。可能是為了什么查詢方便吧？或者好做日志，事務(wù)吧？瞎扯中。。。

HTTP報(bào)文格式是什么樣的？能大概敘述下么？

答：源地址ip與端口號，目標(biāo)ip與端口號，協(xié)議類型。（只記得這三個(gè)。然后開始瞎扯?。╊~。。。還有什么了？請求數(shù)據(jù)，請求頁面。。。。（面試官愕然?。┍淮驍啵?br style="box-sizing: border-box;font-size: 0px;height: 0px;line-height: 0;color: rgb(57, 57, 57);font-family: "Microsoft YaHei", 微軟雅黑, helvetica, arial, verdana, tahoma, sans-serif;letter-spacing: 1px;text-align: start;white-space: normal;background-color: rgb(228, 230, 233);">
Tcp三次握手大概是怎么樣的？

答：先Client發(fā)送連接請求報(bào)文給Server。Server收到后發(fā)送ack確認(rèn)報(bào)文給Client。Client收到確認(rèn)報(bào)文后再發(fā)送確認(rèn)報(bào)文給Server。完成三次握手。

這三次握手報(bào)文大概是什么樣的？

答：額。這個(gè)嘛。。。client自己生成一個(gè)請求序列號吧，然后在隨機(jī)綁定一個(gè)端口號，發(fā)送。對方加一后ack過來。。。。此處省略n字！其實(shí)不太懂！扯著玩。被打斷！

HTTP協(xié)議中傳輸報(bào)文可能被hacker竊取了，并且解密了。你該怎么做？

答：（日！二進(jìn)制都給解密了！地球已經(jīng)不能阻止他了！反正我個(gè)小菜是沒辦法了?。╊~，這個(gè)嘛，，，，沒太考慮！我想在傳輸?shù)臅r(shí)候就該把主要的數(shù)據(jù)加密了再傳輸吧，比如用戶密碼，用戶名什么的，這樣解密了也不要緊吧！至于怎么加密，用MD5就好了。

了解https協(xié)議么？說說看。

答：怎么說了，停留在書本知識，從來沒實(shí)踐過。是443對吧？額，，，是http的加密連接協(xié)議。安全，可靠。然后開始瞎扯。其實(shí)不太懂！被打斷！

session和cookie有什么不同？

答：一個(gè)是client-server保持機(jī)制，一個(gè)是client保持機(jī)制。存放的地方也不同。。。被打斷！

恩，好。這些基本的我想你都知道。說說看你對cookie安全方面有什么考慮？比如他在client端會被篡改，你怎么做？

答：這個(gè)嘛。。。首先密碼和一些重要數(shù)據(jù)一定不能存。還有就是，把要存放的數(shù)據(jù)都加密了。比如用戶id，用戶名，角色什么的。。。被打斷！

MD5是不可逆的，你把用戶id加密了，怎么比配??？

答：（其實(shí)我還真沒吧id加密過！沒辦法硬著頭皮往下說?。╊~，就匹配吧，在比對的時(shí)候，server也進(jìn)行一次MD5加密，看是否相等就行了！

你對加密有什么心得？我們都知道MD5解密網(wǎng)站很多了？

答：額，重要數(shù)據(jù)，不要用簡單的一次MD5加密就行了。比如說，用戶密碼，我們可以給每個(gè)用戶一個(gè)隨即6位的加密因子。做位處理后再做MD5運(yùn)算，比如說相與相或什么的。

你說的密碼因子就是類似密鑰么？放在什么地方？

答：恩，差不多吧。放在用戶表里，隨機(jī)的6為字符，用戶每次登陸完后系統(tǒng)會更新這個(gè)字段與實(shí)際的密碼字段。我現(xiàn)在做系統(tǒng)就是這么做的。你想啊，在這中間，別人最可能拿到的就是我們加密后的密碼字符。這時(shí)候其實(shí)很可能已經(jīng)失效了！

那別人拿到了真正用戶密碼了？

答：這個(gè)問題我有想過，后來想想我感覺好像沒辦法了吧！（面試官和我一樣犯過這樣的傻啊，呵呵）

對nosql熟悉么？有用過么？

答：還行吧。大部分沒太用過。不過memcache用過，很常見，也很容易使用。主要在DB類層做判斷就行了，如果內(nèi)存中已經(jīng)有了這個(gè)鍵值對，直接 memcache_connect，然后get數(shù)據(jù)。不然就去查找mysql。你想啊，最終我們交互的數(shù)據(jù)肯定都要到這個(gè)DB類抽象層。其他的nosql 如果有需要，我會去看這方面的書！

你對memcache的命中率有跟蹤過么？效率怎么樣？

答：這個(gè)嘛。。。這個(gè)自己沒有跟蹤過哦，只看過一些大神的博客比較過他和redis。貌似redis效率更高些（答非所問?。?br style="box-sizing: border-box;font-size: 0px;height: 0px;line-height: 0;color: rgb(57, 57, 57);font-family: "Microsoft YaHei", 微軟雅黑, helvetica, arial, verdana, tahoma, sans-serif;letter-spacing: 1px;text-align: start;white-space: normal;background-color: rgb(228, 230, 233);">
你接觸過最大的數(shù)據(jù)量有多少？最多有服務(wù)器？

答：大幾百萬吧。是個(gè)社區(qū)。有11臺服務(wù)器。

對于大數(shù)據(jù)訪問效率你怎么處理？

答：首先看是否能搭建分布式環(huán)境，做主從數(shù)據(jù)庫，讀寫分離。讓replication進(jìn)程實(shí)現(xiàn)master-slave同步。

然后再考慮分表。水平、垂直分表都行。用什么算法分表看具體業(yè)務(wù)。比如比較簡單主鍵的奇偶性。還有分表上，我建議用mysql5.1版本以上的邏輯 分表功能模塊，先安裝partition，簡單配置下，做不同磁盤的存儲，減少I/O的讀寫（在一次日資企業(yè)面試中學(xué)到的，然后回來看看，果真牛逼）。

其實(shí)這個(gè)也沒減少I/O讀寫的。（沒敢反駁！以后要真成了同事，咱們在慢慢討論也不遲。）一般我們做master與slave同步很好處理，假如你發(fā)現(xiàn)你的應(yīng)用中master寫壓力很大，你需要做多個(gè)master來分解壓力。你怎么實(shí)現(xiàn)他們之間的同步？

答：這個(gè)。。。我還真沒做過多個(gè)master。沒考慮過哦。。。

對于分表算法，你有什么心得？

答：最簡單的主鍵奇偶性，主要還是看需求，甚至按年份，月份都可以。

這些算法你怎么實(shí)現(xiàn)查詢定位到具體表？

答：恩，這個(gè)因?yàn)槟闼械臄?shù)據(jù)交互，都要交給類似DB類得抽象層，這里面我會寫類似find，select的方法，對其傳過來的表參數(shù)實(shí)現(xiàn)具體算法 規(guī)則上的變換。盡量不要讓運(yùn)行原生的sql語句。即使運(yùn)行我也會提供類似可以完成替換數(shù)據(jù)表的特殊字符串，讓DB類能夠?qū)崿F(xiàn)替換。比如很多框架會在sql 里面建議用戶用類似大寫的__TABLE__字符串。

接觸過cdn么？

答：接觸過，是買的人家cdn，前一家公司是個(gè)社區(qū)，pv很大。這個(gè)是必須要有。

你能大概畫一個(gè)web架構(gòu)圖么？比如你們之前11臺服務(wù)器怎么架構(gòu)的。

答：（一邊畫一邊講）最前面的這個(gè)是cdn，接下來這個(gè)是負(fù)載均衡器。后面有多個(gè)web server，每個(gè)都用的是nginx接受請求，后端用代理apache做處理。其中有一個(gè)當(dāng)?shù)?，其他服?wù)器也會正常服務(wù)。然后這幾個(gè)是主mysql服務(wù) 器，后面這幾個(gè)是slave。這個(gè)是圖片服務(wù)器。

你web頁面上怎么請求你的圖片服務(wù)器資源？

答：我們這個(gè)是單獨(dú)的圖片服務(wù)器，用戶上傳圖片的時(shí)候時(shí)候，數(shù)據(jù)表里的字段會放完整的路徑名，這樣就能請求這個(gè)圖片服務(wù)器了。

你們怎么實(shí)現(xiàn)這個(gè)圖片服務(wù)器的安全？比如這個(gè)服務(wù)器掛掉了。有備份服務(wù)器的話，你怎么實(shí)現(xiàn)同步？

答：凌晨2點(diǎn)。呵呵。

那只能實(shí)現(xiàn)時(shí)間段得備份吧！比如在某天凌晨2點(diǎn)之前服務(wù)器掛了，當(dāng)天的圖片除了cdn上會有臨時(shí)存儲，其他就沒了？

答：這個(gè)嘛。。。恩，肯定的。那我也不能在每個(gè)請求做一次同步吧。這個(gè)嘛。。。省略n個(gè)字，又到扯著玩時(shí)候了。。。

對web server熟悉么？對linux熟悉么？對shell熟悉么？

答：（實(shí)踐表明，對這個(gè)面試官，不懂不要瞎扯，會帶你到溝里去?。゛pache還行吧，能配置。Nginx，弱一點(diǎn)，有需要我可以學(xué)習(xí)。Linux的話，不太在行，缺少實(shí)踐經(jīng)驗(yàn)，理論知識還行。shell命令都還記得。


你說你們現(xiàn)在的平臺要做java到php轉(zhuǎn)換。你們要接觸java么？為什么要轉(zhuǎn)換了？

答：不會接觸java。兩個(gè)系統(tǒng)是平行使用的，目前也不會取代這個(gè)系統(tǒng)。聽說是ceo不滿意目前的這個(gè)java外包系統(tǒng)。所以要改的。

CEO不滿意？這個(gè)理由不充分哦？

答：這個(gè)嘛。。。這個(gè)我也不知道哦。就聽說ceo不滿意的。

你在這個(gè)系統(tǒng)中做什么？

答：省略n個(gè)字。

你對linux c熟悉么？linux shell腳本了？

答：linux c一點(diǎn)不會！linux shell腳本還行，不過缺少實(shí)踐。