進階招聘題目

系統工程師：

題目1 很簡單，某mysql資料庫伺服器A，出現mysql連結過多，導緻前端web伺服器無法打開資料庫連接配接，現在，由你來解決這個問題。

題目1之問題1：你會以怎樣的步驟來處理這個事情。請注意，步驟

題目1之問題2：如何分析這一問題，共有幾種可能性，每種可能性的分析方式，判别标準是什麼。

題目1之問題3：針對不同可能性，給出盡可能完整的解決途徑。

不要告訴我您會修改mysql連結參數，如果您隻想到這一條，不要來信了。

題目2： 某linux伺服器平時負載很輕，cpu在10%-20%之間，但是每周都會有幾天在不定時間突然躍升到100%，然後導緻該伺服器拒絕一切響應（包括ssh連結在内），無奈之下隻能電話通過機房重新開機。

現在，負載飙升時無法連接配接ssh，暫時無法确認負載飙升原因，請給出你想到的處理步驟和解決思路。

不要告訴我您會設定一個24小時短信提醒，那是最基本基本的了。

題目3：某linux 伺服器一直負載很輕，但是會突然拒絕正常的服務，此時仍然可以登入，仍然看到線上很輕的負載，請告訴我你分析排查的思路。

開發工程師：

1：概述題

都知道資料庫使用索引能夠提高效率，為什麼，用自己的了解簡單描述。

這道題是後面n多題的基礎。

2：實戰題

2.1 借了一道據說是騰訊面試的題目，和我當年在某公司商業分析部招聘的題目幾乎一樣，這道題很有代表性，拿出來說一下。

現在有個檔案裡有40億條無重複整型數，為4位元組無符号數，或者說，0 到 2的32次方。下面要求你寫一個程式，列出所有 0 -2的32次方裡，該檔案不存在的整數。注意你的系統可用記憶體是有限的，也許隻有1G或2G。如果這40億條有重複，有什麼差別？

2.2 一個很典型常見問題，對使用者做地區判定，比如新浪首頁，百度新聞首頁，會根據不同地區使用者顯示當地的新聞；比如百度，谷歌搜尋結果會根據不同使用者地區顯示不同廣告。這個是基于使用者ip位址的，ip位址區間是國際組織配置設定的，非常散列，并不是嚴謹的順序， 現在已知有10萬段的ip位址對應段。在高并發情況下，如何在使用者通路的時候快速傳回該使用者對應的地區，給出你的方法和要點。注意，效率是考核的關鍵，如果一秒鐘無法實作超過1000次不同ip的查詢結果（單台雙至強伺服器隻做該查詢的情況下），效率肯定不行的。

2.3 又一個典型問題，目前政府有屏蔽詞表，每個網站都要遵守，發帖的時候會自動替換屏蔽詞；另一個場景是諸如新浪新聞等媒體往往有商業詞表，發新聞的時候會自動建立關鍵詞鉚接。這個相當于一個簡單的基于詞典的分詞系統，下面的問題就是，如何實作一個快速有效的，基于自定義詞典精确比對的分詞系統，一是要滿足每天幾萬篇，幾十萬篇文章釋出的要求；另一個必須的要求是，當詞庫倍增擴充時（比如10萬詞），效率的影響不允許是線性降低的。

營運總監：

1： 請用你的了解點評zynga與facebook 的走勢。

2： 請用你的了解講述百度貼吧

3： 如果你隻有3個員工，卻要營運一個日活躍200萬的社群，你怎麼營運？如果是30個，怎麼營運？你希望是3個還是30個，還是其他數字？

4： 社交遊戲，網頁遊戲，小遊戲，各列出你所認為前20個流行的，并給出各分類前三流行遊戲的點評和趨勢判斷。

5： 白社會搶房女事件，按照你的了解簡單點評。

6： 如果在資源有限的情況下，你來負責組建營運團隊（遊戲社群），你希望招聘什麼背景的人，以及如何培養。

系統分析師：

caoz考核，一看意識，二看思路，三看方法

前言 ： 其實考試這種東西本身是不平等的，因為出題人肯定有優勢，是以有些人水準比caoz高很多，答caoz的題目也隻能得到七八十分而已，如果換過來出題，caoz可能及格都是問題，而且這些題目其實更适合面試進行，因為可以層層遞進剖析問題，從一個大問題引申提出更多子問題，這是caoz面試常用的習慣，很多趾高氣揚的人進來，灰頭土臉的出去，當然，還是那句話，考核本身是不平等的。也許您答的和caoz期望的相差不少，但是不代表caoz比你水準高。

回過頭來說，意識是第一位的

1:資料連結過多，這是最常見的問題，但是其實也是這裡最重點的問題

子問題1，為什麼提到步驟，很少有人告訴我，第一步是盡快臨時恢複線上應用，這就是意識！

恢複線上應用有幾種場景，最簡單的是show processlist 然後kill掉阻塞的processlist，其次是重新開機資料庫，如果資料庫重新開機後又會快速堵塞，那麼要盡快從前端代碼中找到阻塞點，臨時屏蔽掉某些導緻阻塞的功能，以及增加同時連結參數，為了保證在你徹底解決這個問題的這段時間裡，你的前面網頁是可以順利打開的。

這裡存在一個小問題，如果是面試我會單獨提出來，你怎麼保證連接配接過多的情況下，後面還能看到show processlist，這裡的竅門是，前段務必不要使用root連接配接資料庫，這樣mysql後端root仍然會多出一個程序來滿足查詢要求。 之前我跟工程師說這個問題，他們果然換了一個賬号，一個不叫root但是權限是root的賬号在前端連接配接資料庫，害的我郁悶了n多天找不到阻塞點。

第二步是确認阻塞點和阻塞方向，為什麼說阻塞方向，因為資料庫的阻塞，并不一定都是資料庫造成的，連帶影響非常多，通過show processlist ，如果看到大量的Lock，那麼其一是代碼優化，其二是改造資料引擎，如果Lock不多，而執行中查詢很多，其一是索引優化，其二是資料庫參數優化，有人說會看慢查詢，慢查詢很重要，但是不夠的，對于高并發來說，一個常見SQL執行0.1秒都是不可容忍的，通常這是索引不徹底造成的，比如簡單來說 ，如果有個同城速配的常見SQL select * from users where sex='女' and area='廈門' order by lastlogin desc ，這麼一個查詢，你會怎麼建立索引？我告訴你，三鍵複合索引！少一個效率都不行. 而且順序還必須保證！ 之前非常多發現因為複合索引不到位，導緻資料查詢執行0.05 -0.1秒的準慢查詢，通過set profiling是可以分析的，優化後效率提升10-100倍。 此外，連帶影響也是一個大問題，比如說，有時候你會看到大量SLEEP連結，那多半是前段執行完SQL沒有及時關閉，之前我的部落格如果有認真閱讀的，會看到因為echo影響，因為memcache連結阻塞影響都會存在，當然還有一種，網絡帶寬阻塞影響，Waiting for net狀态阻塞，

這裡确認阻塞點和阻塞方向，最關鍵的是思路要足夠發散，不要隻看資料庫配置，或者資料索引；前端程式，網絡環境（曾經因為别人的外挂程式，以及代碼不嚴謹，導緻内網網卡阻塞，資料庫連接配接過多）都需要考慮周全，是以有些答案caoz回複說思路不開闊，就是這個原因。這裡具體分支場景很多，caoz也隻是列舉一二，僅僅配置優化，就有無數參數可以提出。

第三步是解決，這裡通常要多向考慮，什麼叫多向考慮，分析問題如果夠全面，就會發現問題往往是伴生出現，比如出現阻塞，也許你優化背景參數的确可以解決，但是如果前端調用腳本也優化一下，可能就會得到更好的效果，那麼這裡要強調的是，解決問題必須給出明确的數字支援，比如更新後，性能提升多少，負載支撐提升多少，可支援多少并發，支援多少同時連接配接，由于經驗問題，很多人估算不準，這不是問題，幾次訓練下來就準了，但是如果不去估算，那麼永遠都沒有經驗，永遠估不準，這其實也是意識。

但是到了這裡，事情還不算完，還有一步！

第四步是什麼呢？無人值守腳本

千算萬算，不能不算，無人值守情況下，資料連結過多怎麼辦，有幾種解決方案，重新開機資料庫未必明智，一個很簡單的原因，如果是myisam，重新開機可能導緻資料索引出錯，如果是innodb，可能重新開機需要很長時間，最有效的，還是直接kill掉阻塞的查詢程序。然後記錄日志以備後續分析。

而且，按照caoz的經驗，不要等連結阻塞再去kill掉查詢程序，應該在連結數超過報警門檻值的時候直接kill掉執行時間過長的SQL查詢程序，有人會問，哪裡有這樣的系統？自己寫一個cron腳本，花不了一個小時的。

第二個問題，在上頭啰啰嗦嗦有羅列

第三個問題，場景很多，簡單列如下

1：資料庫讀寫鎖，換成innodb引擎是最快的方法，那麼讀寫分離做主從也是一種方案，不過要考慮成本還是蠻高的。此外就是讀取資料多用緩存，寫入過多怎麼辦？也用緩存！緩存回寫，同主鍵寫入合并，具體政策不多說了，這是caoz看家的本事。

2： sleep連結太多，前端代碼檢查，找到關聯影響點，盡快釋放mysql連結

3： 慢查詢和準慢查詢太多，索引優化，以及資料庫拆分優化（忙閑拆分，主鍵hash拆分，還有其他拆分模式），索引碎片整理（資料索引優化或重建，半夜偷偷幹吧）

4： 網絡阻塞，減少控制資料庫操作的資料流量，改代碼去吧

5：i/o壓力過大，有些參數可以設定的，比如innodb的資料送出不一定每次操作都送出的。

總之，優化方案之多，難以全面羅列，可以整理如下

優化分為架構優化，比如引入緩存層，引入主從架構，引入中間件，分庫分表，都屬于架構優化。

代碼優化，減少重複和不必要的查詢，合并重複查詢，良好的代碼習慣

DBA優化，索引優化，存儲引擎優化，mysql參數優化，資料庫版本優化

作業系統優化，檔案系統優化，linux核心優化，

對系統架構的了解，有助于從不同層面分析問題，思路要發散，不要隻看資料庫

對資料查詢的了解，多使用set profiling，對每一個停留狀态，每一個耗時和資源配置設定，索引的每一次查詢方式要心理有數。

對資料庫參數的了解，要知道每個參數對i/o的影響，對查詢執行的影響，對每個SQL程序執行步驟（set profiling可以分析SQL執行步驟）的影響是什麼，

對程式的了解，要知道程式為什麼請求資料，請求資料的目标和方法是否合理，是否有重複和無效的請求占用資源。請求資料後是否長期閑置連結，是否存在不合理的關聯影響。

對系統的了解，是否存在系統配置短闆，導緻資料庫性能無法發揮。

第二題

簡單說，關鍵是無人值守腳本，無人值守腳本要

1：記錄負載提升時的系統狀态和程序清單，程序資源占用資料。

2：自動對突然增加負載的使用者或系統程序進行處理，

3：記錄處理結果和處理後的狀态。

無人值守記錄是系統維護的關鍵點，有很多人用第三方工具，當然很好，但是必要的時候必須親自做一些監控腳本，這東西用什麼寫都可以，php,perl，ruby都無所謂，能記錄，能執行關閉程序和啟動程序的操作就可以。

第三，這種問題當然有很多種可能，分析日志也好，分析系統狀态也好，不過根據caoz經驗，出這種問題，80%以上是系統某參數越界，這種越界還蠻多的，比如最多檔案打開數，系統最大連接配接數，syn_backlog，甚至最多檔案節點數（看硬碟空間還有，其實inode沒有了，大量瑣碎小檔案就會出這個問題！）還有，ip_contrack什麼參數，可能導緻網絡丢包嚴重， 是以這個問題的關鍵是，對linux各項核心參數必須有深入了解，有時候你看伺服器跑不動了，可能改一下參數馬上就好了，但是改哪個參數，怎麼改，這就隻能是經驗和搜尋技巧了。

其實caoz想到的也不完整，後來有人給caoz很多提醒，比如前端mysql,memcache連結應該設定逾時參數雲雲。不過總體來說

意識到位（先臨時處理立即恢複線上應用，再徹底處理，處理要評估并且做出預判，優化與故障自動處理要并行，不能100%依賴優化結果）

思路開闊（dba的問題别死盯着dba，謝謝）

經驗豐富，上述列到的，您列出了幾個？

答案就此公開，謝謝各位的來信。真有不少人才，讓caoz興奮！

題目1

現在有兩個日志檔案，格式為

211.137.1.1

125.65.2.3

202.36.71.33

....

每條一個ip位址。每個日志檔案各有100萬左右條。檔案中可能少部分ip是重複。

現在想知道檔案1與檔案2中，相同的ip有多少，請編寫腳本實作。

小提示：第一，不要吧這個問題複雜化，這是這裡最簡單的問題。第二，注意程式效率。

答案，此題其實相當簡單

将第一個檔案周遊讀取，存入數組，無須排序，存入即可。

$arr[$ip]=1;

然後周遊第二個檔案，針對第二個檔案中的每一個ip

查一下是否存在該數組下标

if (isset($arr[$nip])) $sum++;

然後輸出$sum即可

其中無任何地方需要排序處理。

題目2

還是剛才那個日志檔案，隻有一個，100萬條ip記錄，少部分有重複

現在有一個ip位址庫

格式為

ip位址1 - ip位址2 - 地區

這個庫有15萬條記錄

現在請編寫腳本，将這100萬條記錄的地區分布列出來。

小提示，這個題目的關鍵詞是，效率。100萬×15萬，如果不用點竅門，是不可承受的系統開銷，那麼很多人都知道索引是提高效率的重要手段，但是基于區間的查詢，是不能直接使用索引的，但是，想一下索引的實作原理和效率提升的原理，這個問題就會迎刃而解。很多時候，我們不僅僅要善于利用一些有效的工具，更要明白，這些工具背後的邏輯。

答案，

實際上是要點隻有一條，将15萬條地區庫建立為有序的數組并格式化儲存，這個數組會非常有用，做一次排序儲存即可，在n多涉及地區查詢的實際應用中都可以統一調用，無須每次重新排序。

之後就是最典型的二分查找法了，關鍵是編寫一個二分查找的函數，可以通過不斷的二分處理在15萬條記錄中快速找到該ip所對應的區間，理論每個ip的查找次數是log2(150000),

周遊100萬條記錄（這100萬條記錄無須做任何排序），對每個ip判斷是否已進行過地區識别，如果沒有，則調用二分查找，傳回所屬地區屬性，然後

$sumarea[$return]++; 最後把sumarea排一下序輸出即可。

這裡唯一的排序是對15萬條地區ip區段資訊排序，而且隻需要進行一次長期儲存即可。考核的關鍵不是排序，而是二分查找，二分查找是最簡單的快速索引算法，網上大量資料可查閱。

題目3

現在有2億web服務的日志，假設就是apache日志或類似格式的日志，沒說錯，2億條，格式大體為如下

ip位址,通路url,來路url,目前時間

假設就這些吧,這裡可能涉及的是2萬個不同的站點。

現在要求，做出每個站點的流量統計，包括這個站點的獨立ip數，pv數，時間段分布，地區分布，來路分布，受訪分布，Top進入url。

現在給你的電腦是一台雙CPU，2G記憶體的伺服器，請考慮實作方式。

小提示，這裡的關鍵詞除了效率，還有資源開銷，如果我們不考慮數字，隻考慮應用，這個題目并不複雜，隻是羅嗦，但是當你考慮到要分析2億個日志，而且對2萬個站點每個站點都要做出統計，那麼你程式時就可能會遇到一個天大的問題，按照一般的方式處理，記憶體肯定遠遠不夠用。但是如果大量使用硬碟空間來替代記憶體，又存在巨大的i/o開銷，如何尋找均衡的方式，這裡考查的不是腳本編寫，而是系統設計。

答案

這道題看上去很唬人，但是實際上隻是一個日志切分的問題，不要把系統考慮太複雜

實際上組建一個二步處理的過程，第一步是周遊2億的日志，然後将每條日志的站點主域取出來，作為檔案名，處理到一定數量時批量儲存為獨立檔案。

過程示例如下,處理函數略

$seed=0;

while ($str=fgets($fd))

{

$seed++;

$arr=checklog($str); //将日志切分,将日志中的各個字段切分

$site=$arr["site"];

$vstr["$site"]=$vstr["$site"].$str;

if ($seed>1000000) //假設以100萬條日志為記憶體處理容量

{

    foreach($vstr as $key=>$value)

    {

    $fd=fopen("$path/$key","a");

    fwrite($fd,$value);

fclose($fd);

}

unset($vstr);

$seed=0;

}

}

這個程式執行後，2億條日志就被分割為2萬個檔案，每個檔案對應一個站點

然後再做一次針對站點的周遊，每個站點分析日志，就屬于純粹的羅嗦體力活了，過程略

該題目中不涉及任何排序操作及算法。這個模式隻需要周遊日志兩次，此外需要日至容量一倍的寫操作，這些代價并不是不能承受的，至少系統設計上很簡單。

題目4

小張是某大學的體育部主任助理，為了友善安排體育課程，他做了一個調查，發了1000份問卷，讓所有人填寫自己所期望的體育課程，這份調查是允許多選。

基本結果為，足球 500份，籃球350份，乒乓球200份，羽毛球200份，網球120份，棒球50份，....

然後小張做了另一個統計，針對每個項目，檢視與它共同選擇最多的項目，看看冷門項目中，有沒有多個項目合并的可能，結果發現，所有選擇冷門項目的人，最多的共同選擇項幾乎都是足球和籃球。那麼，是不是說所有項目都與足球，籃球高度相關呢？是不是所有冷門項目都可以并入足球籃球呢？這裡的問題在哪裡？

如果你是小張，你是否能有更好的處理方法，如有可能，代碼實作。

小提示，這是一個基本的關聯模型和聚類模型的應用，關聯模型中，考慮關聯性的因素都包括哪些，共同選擇的數字并非唯一的标尺。

答案：

關聯模型中，我們不僅需要考慮支援度（共同推舉數），也需要考慮置信度（相對比例），這裡其實就是一種思維模式的考量，很多時候，我們設計關聯模型時，針對不同應用，需要有不同的考量及評估模式，實際應用會比這個題目複雜。

總結

以上都是工作中遇到的實際問題，并非算法考試，和百度程式之星，google程式大賽的模式是不同的，這次招聘面向的目标是非技術部門的資料分析工作，是以并不十分特别強調高效算法，但是強調有解決實際問題的能力，所謂解決實際問題，核心的要求就是簡潔高效，從收獲的一些答案看，大部分應屆生喜歡把問題複雜化，也許是題目描述的問題，不過希望年輕朋友們一定要記住，工作和做學術答辯不一樣，一般學生做畢業論文的時候，喜歡化簡為繁，簡單的問題複雜化，顯示卓越的學識和技能，但是工作要求的是化繁為簡，用最短時間解決最多的問題，最短的時間不僅僅是程式執行的時間，也包括設計和編碼的時間。