書接上回，今天敘述小米的面試經(jīng)歷。

這里可能有一些技術(shù)理解和技術(shù)方案，歡迎討論。另昨天共計收入7筆共95元，夠我喝幾杯咖啡了，謝謝所有捐錢的朋友。

如果你心疼我碼字辛苦，有錢朋友錢場，沒錢的請拉朋友來捧個錢場，捧場鏈接：https://me.alipay.com/chunshengster?，多少不限

小米：

1. 運維部

在小米是聊了兩個部門的，首先是運維部門，在?@wilbur井源?的熱情招待下，吃了頓大餐，抱歉的是我沒有帶足現(xiàn)金，所以付款時我無法“客氣”，改天補請。

wilbur井源同兩位同事與我四人邊吃邊聊，我簡單介紹當前的網(wǎng)站的服務(wù)結(jié)構(gòu)以及部分業(yè)務(wù)的技術(shù)設(shè)計，比如網(wǎng)站架構(gòu)的分布情況，分布式文件系統(tǒng)fastDFS的使用狀況、Redis和MySQL的一些部署結(jié)構(gòu)和技術(shù)，其中尤其對監(jiān)控這件事情我做了詳細一些的說明（詳見服務(wù)可用性監(jiān)控的一些思考以及實踐），中間提到了關(guān)于主動監(jiān)控（主動監(jiān)控是指通過運維和業(yè)務(wù)部門指定監(jiān)控的系統(tǒng)資源、接口、頁面、日志等，主動發(fā)現(xiàn)問題,警報級別較高）、被控監(jiān)控的概念（指通過JSlib或客戶端lib對于所有的操作尤其是網(wǎng)絡(luò)接口的請求進行監(jiān)控，對異常進行匯報，通過收集日志的方式進行可用性問題的發(fā)現(xiàn)）。當然，還有必不可少的是對haproxy的運行和優(yōu)化狀況（參見Haproxy配置），MySQL的架構(gòu)及優(yōu)化方式（見MySQL架構(gòu)及運維），Redis常見的性能問題（參見redis架構(gòu)及運維問題），fastDFS同其他分布式存儲MogileFS、TFS、lusterfs的在功能、運維成本上的橫向比較，多IDC圖片cache的部署以及性能優(yōu)化（參見多idc圖片Cache部署），Linux內(nèi)核參數(shù)（參見Linux內(nèi)核配置）和讓我特別自豪的是關(guān)于網(wǎng)卡smp affinity/RPF/RFS的優(yōu)化效果（參考3/4/5）的一些優(yōu)化等。當然，這是正經(jīng)的運維部門，我闡述了我對“運維”工作的理解：60%的分析整理工作加上40%的技能，分析整理能力是做好運維的基礎(chǔ)。

井源也詢問了幾個安全問題，我粗淺的理解是：從SA的經(jīng)歷來講，做好IT系統(tǒng)規(guī)劃，合理區(qū)分服務(wù)器角色，通過iptables是能夠阻止大多數(shù)接入層非法請求的；對于web業(yè)務(wù)的安全來講，SQL注入、CRSF等攻擊是因為對輸入輸入內(nèi)容的過濾不嚴格導(dǎo)致的，在開發(fā)的過程中合理使用一些優(yōu)秀框架或lib，也能夠避免大多數(shù)漏洞的產(chǎn)生；有個比較有意思的話題是關(guān)于溢出的，現(xiàn)在我已經(jīng)不會計算溢出地址了，在我當script boy的時候研究過一點，忘光光了，慚愧……

井源這邊的效率很好，邊吃邊聊的氣氛很放松，不過很多問題都停留在一些思路和效果數(shù)據(jù)上，沒有勾勾畫畫的太多深入的探討。

?

2. 電商部

大約8點半左右到的電商部門，常規(guī)面試的第一輪都是技術(shù)，包括細節(jié)。面試官是位張姓的team leader。

在這輪面試的過程中，因為是在會議室，有筆有板，所以我邊講邊寫。大體上介紹了我對web服務(wù)架構(gòu)的理解，我認為，web服務(wù)架構(gòu)大體上離不開這樣幾個層面：接入層（負載均衡）、業(yè)務(wù)服務(wù)層、數(shù)據(jù)層，一般還會有不少的后臺輔助程序進行同步、異步的處理各種不適合在業(yè)務(wù)層融合的服務(wù)單元。數(shù)據(jù)層可以包括DB、Cache、File等，數(shù)據(jù)層還可能會有很多中間件或代理服務(wù)器用來做數(shù)據(jù)層的負載均衡或是HA，以及Sharding等。同面試官詳細介紹了當前服務(wù)的公司在每一層所采用的技術(shù)，分別是：haproxy、nginx+php、twemproxy+redis、MySQL+RedisCache、Varnish+Squid+nginx+fastDFS。

haproxy的服務(wù)器配置是按照100w并發(fā)的目標進行配置和優(yōu)化的，計劃100w客戶端連接，考慮每個客戶端連接可能產(chǎn)生1個內(nèi)部連接，按照每個連接消耗4k內(nèi)存來算，大約8G內(nèi)存，實際上往往比這個數(shù)字要大。目前達到的最大連接數(shù)目測到過16w，在接入層的系統(tǒng)優(yōu)化上分別有：網(wǎng)卡中斷優(yōu)化（參考3/4/5），linux?內(nèi)核參數(shù)優(yōu)化（見linux sysctl.conf配置）。

值得一提的是，我們的haproxy服務(wù)器都是64G內(nèi)存，實際上遠遠永不到這么多，圖片服務(wù)的最外層cache，即Varnish，我們也是部署在haproxy服務(wù)器上的。

在最外層服務(wù)器上，我們每天大約5億+（1-1.5億+的動態(tài)請求、3-4億+的圖片請求）的請求量，共計使用7臺64G的Dell R410,目前看負載還很低，從系統(tǒng)的各種資源上看，請求量翻倍應(yīng)該是沒有問題的。

在最外層的服務(wù)器配置上，有一個問題值得注意，即sysctl.conf的配置中，timestamp必須為0，這個在tcp協(xié)議的擴展標準中有提到，否有nat環(huán)境的客戶端連接有可能產(chǎn)生異常，異常的狀況可以在netstat -s?的輸出中看到。還需要注意的是timestamp=0的情況下，tw_reuse是不生效的。

要保證服務(wù)器能夠接收大并發(fā)的連接請求是件不難的事情，但需要考慮一個細節(jié)，每接收一個請求，haproxy就需要至少分配一個系統(tǒng)的tcp端口請求后面的業(yè)務(wù)服務(wù)器、cache服務(wù)器，系統(tǒng)一個ip地址可用的端口數(shù)最多為65535，一般還需要減去1024。值得考慮的是減小?tw_bucket?的容量，讓系統(tǒng)在tw_bucket滿的狀況下，對tw狀態(tài)的連接進行丟棄，以達到快速回收的目的，tw的默認回收時間的2倍的MSL。還有一個方式就是多配置幾個ip。

還有一個問題，接入層的服務(wù)器往往會開啟iptables，內(nèi)核中nf的相關(guān)配置也是需要優(yōu)化的，比如?nf_conntrack_max、nf_conntrack_tcp_timeout_established等。

?

在業(yè)務(wù)層的優(yōu)化有nginx+php（fastcgi連接方式、php-fpm.conf配置中的優(yōu)化），我的一個經(jīng)驗是，如果nginx同phpcgi運行在同一臺服務(wù)器，采用unix socket的方式進行fastcgi協(xié)議的交互是效果最快的，比127.0.0.1的回環(huán)地址要快太多。我在08年優(yōu)化過一臺服務(wù)器（Dell 2960，16G內(nèi)存），通過兩個步驟，將一臺服務(wù)器從900qps，優(yōu)化到6000qps以上,其一是將fastcgi協(xié)議運行在unix socket上，其二是合理配置spawn-fcgi的進程數(shù)量。現(xiàn)在基本上phpcgi都是運行在php-fpm中的了，其進程池邏輯是我最贊賞的功能之一。

如果nginx和php-fpm不在同一臺服務(wù)器上，可以考慮使用fastcgi_keepalive的配置，實現(xiàn)nginx同fastcgi服務(wù)器持久連接，以提高效率。

nginx+php-fpm提供的運行狀態(tài)非常有意義，nginx的status模塊和php-fpm的status輸出可以告訴我們nginx進程的請求處理狀況，php-fpm的status輸出可以告訴我們php-fpm的進程池設(shè)置是否合理。我們目前對這兩個數(shù)據(jù)通過nagios定期采集，并繪制成圖表，很有“觀賞價值”。

php-fpm.conf的配置中還有幾個參數(shù)對優(yōu)化比較重要，其一是進程自動重啟的條件pm.max_requests，其二是php-slow log的配置，slow log?是優(yōu)化php代碼的非常重要的信息。在我目前的環(huán)境中，php的慢執(zhí)行日志是通過rsyslog進行傳輸并集中分析的，以此反向推進開發(fā)對php代碼的優(yōu)化。

php的服務(wù)器在高并發(fā)的情況下，有可能因為服務(wù)器本身可提供的端口數(shù)量的限制，無法同redis服務(wù)器建立大量的連接，這時候可以在sysctl.conf中配合timestamps=1?加上tw_reuse/tw_recycle的方式，進行端口快速回收，以便更好的向數(shù)據(jù)層建立連接，接入層的haproxy是不可以這樣的。

這一層還涉及到一個安全問題，就是php代碼被修改并掛馬的狀況，我的解決方案是，將php-fpm的運行用戶同php代碼的屬主設(shè)置成不同的用戶，并且保證php-fpm的運行用戶不能對php代碼具有寫的權(quán)限。

?

數(shù)據(jù)層的情況里，MySQL主從結(jié)構(gòu)以及MHA+keepalived的高可用配置，這個基本上是看文檔應(yīng)該就能夠理解的。如果是5.6的新版MySQL，其高可用監(jiān)控可能可以做的更簡單，MySQL官方提供對應(yīng)的工具，只是我還沒有測試。對MHA的監(jiān)控功能，我覺得亮點是MHA對切換過程中MySQL binlog的獲取和執(zhí)行，在最大程度上避免了數(shù)據(jù)丟失。但是其缺點也是有的，比如：監(jiān)控進程在觸發(fā)切換后就停止了，一旦觸發(fā)，必須重新啟動進程再繼續(xù)監(jiān)控。06年時我在sina做過一個叫Trust DMM的項目，通過?DNS、MON加上自己寫的插件，監(jiān)控MySQL主從集群的可用性，可以實現(xiàn)，主庫、主備自動切換（缺乏binlog處理的環(huán)節(jié)）；從庫是一組服務(wù)器，如果從庫發(fā)生問題，可以自動下線。只是這套系統(tǒng)部署起來比較麻煩。這個項目曾經(jīng)獲得過sina的創(chuàng)新一等獎。

我還提到了我認為的DBA日常的工作至少應(yīng)該包括：審查并執(zhí)行上線SQL；定期檢查MySQL慢日志并分析，將分析結(jié)果反饋到開發(fā)部門進行調(diào)整；定期審查數(shù)據(jù)庫中索引的效率以及可用性，進行優(yōu)化我反饋。現(xiàn)在做一個一般水平的DBA已經(jīng)相當容易了，對percona的工具了解透徹，已經(jīng)能夠解決非常多的數(shù)據(jù)庫問題了。

MySQL還有一個難纏的問題，numa架構(gòu)下，大內(nèi)存服務(wù)器內(nèi)存使用效率的問題，numactl對策略進行調(diào)整，如果使用percona的MySQL版本，可以通過?memlock配置對MySQL的Innodb引擎進行限制，禁止其使用swap。

MySQL常見的架構(gòu)里，還有一種主從存儲引擎不一致的方式，即主庫采用Innodb引擎，提高并發(fā)寫入的能力，從庫采用Myisam引擎，這種方式目前我們也在采用。這樣做一是為了獲取更好的讀性能，另外是，Myisam引擎的是可以節(jié)省內(nèi)存的。Myisam在索引數(shù)據(jù)內(nèi)存讀取，數(shù)據(jù)內(nèi)容磁盤讀取的狀態(tài)下，已經(jīng)可以比較高效的運行了，myisam_use_mmap的配置項，會讓MySQL將myisam的data文件也mmap到內(nèi)存中，這樣做既高效，又可以使用mysiam引擎的特性。

數(shù)據(jù)庫主庫要避免一件事情發(fā)生，就是無條件刪除和無條件修改，如“delete from table”以及”update table set xxx=yyyy”等無where條件語句，原則來講是應(yīng)該禁止執(zhí)行的，這樣的權(quán)限不應(yīng)該開放給開發(fā)的同學(xué)，甚至DBA都不能無限制的操作。目前我的解決方案是?sql_safe_updates=1,但這配置是不能夠?qū)?span style="border:0px; font-family:'AR PL UMing CN',serif; font-style:inherit; margin:0px; outline:0px; padding:0px; vertical-align:baseline">my.cnf中的，只能啟動mysql后進入console進行配置。

?

當前我們還使用了Redis作為DB，基于主從架構(gòu)，跨IDC。目前的問題是，復(fù)制連接斷開后，Redis快照重傳的問題，從庫會在快照替換期間有短暫的性能抖動。?Redis2.8新版本psync的特性應(yīng)該可以改善這個問題。我們還使用twemproxy，目前部署在每一臺php服務(wù)器上，并監(jiān)聽unix socket，php使用phpredis的模塊進行連接。有效減少三次握手的時間。temwproxy還有很多其他的優(yōu)秀特性，通過一致性hash做cache集群，可以有效的避免cache遷移問題。通過其對后端redis的健康監(jiān)控，可以自動下線有故障的redis。

?

還有針對多IDC的圖片存儲和Cache部署情況。目前我們自建的圖片CDN承載網(wǎng)站每天約4億的請求，帶寬最高峰值約1.5G左右，其結(jié)構(gòu)大體上是中心IDC存儲圖片原圖+SQUID disk cache存儲圖片縮略圖，在外地IDC使用兩級緩存，分別為一層SQUID disk cache（兩臺，做HA），另一層為Varnish cache（最多四臺），實際上，如果僅考慮work around的狀態(tài)，squid cache層基本上也可以不要的。但是，目前這樣的結(jié)構(gòu)可以減少varnish回中心節(jié)點的請求，減少中心機房帶寬的壓力。這個結(jié)構(gòu)還算簡單，varnish在高并發(fā)請求下，有一些資源配置是需要注意的，比如NFILES / VARNISH_MAX_THREADS / nuke_limit?等。

?

溝通的技術(shù)問題還是非常多的，包括在井源那里提到監(jiān)控框架的事情，也尤其提到了我對rsyslog的優(yōu)化，優(yōu)化后的rsyslog在可靠性方面是非常值得稱贊的（優(yōu)化思路見參考6）

?

我有一些將電商三面的運維運維同學(xué)的問題綜合到這里了，有些話重復(fù)的就不再描述。

值得一提的是二面是另一位開發(fā)負責人，一看就是個很有獨立思考能力的同學(xué)，他問了我一個很有意思的問題，大體的意思是，在系統(tǒng)架構(gòu)方面，有這樣的幾個層次，從下往上：使用開源、精通開源，優(yōu)化并修改開源軟件，創(chuàng)造開源軟件。問我自己評價我是在哪一個層次的。我認真的思考了一下，我應(yīng)該是在第二個層次，有些精通的，有些修改過的。

?

電商四面是時間最長的，至少有兩個小時以上，結(jié)束的時候已經(jīng)是夜里一點四十了，我覺得電商的老大是應(yīng)該在支付寶里面給我捐一些錢才好的 ，不知道有沒有小米的同學(xué)能夠轉(zhuǎn)告哈??。我們應(yīng)該是談到了非常多的事情，包括秒殺的解決方案，包括對持續(xù)集成和自動化測試的理解、對后臺數(shù)據(jù)業(yè)務(wù)類型的開發(fā)中數(shù)據(jù)計算錯誤的理解，時不時能夠得到“我們想的很一致”這樣的評價。

那時已近半夜，記憶進入低效態(tài)，一些太瑣碎的事情記不得了，重復(fù)的技術(shù)方案也不再贅述。下面簡單描述一下我對秒殺的解決方案的理解：10w的數(shù)據(jù)，從0到10w，不能多賣。目前的問題是，每次到秒殺時分可能同時進入100w的請求/連接。如何破？

我的方案是：排除user、session等外部依賴服務(wù)的前提下，兩臺ha外面抗并發(fā)連接（后來想這個無所謂的，不如做成php的服務(wù)器），三臺PHP服務(wù)器（不要使用任何框架，最樸素的純粹PHP代碼），兩臺Redis（最初說了一臺）。具體優(yōu)化狀況如下：

• haproxy優(yōu)化能夠支持百萬并發(fā)連接，這個很容易了
• nginx優(yōu)化worker connections，優(yōu)化nginx的并發(fā)支持能力和請求隊列的接收能力
• php-fpm優(yōu)化listen.backlog，優(yōu)化fastcgi請求隊列的接收能力。
• Redis?假如在秒殺的1分鐘內(nèi)，服務(wù)器不出現(xiàn)故障，優(yōu)化redis的最大連接數(shù)
• 優(yōu)化所有服務(wù)器的網(wǎng)卡、sysctl參數(shù)

php的邏輯可以簡單的理解為對redis的某一個key進行incr原子操作，如果返回的當前數(shù)值小于等于10w（兩臺redis的情況下應(yīng)小于等于5w），則認為中簽。

從我以前看到的數(shù)據(jù)來講，redis的最好狀態(tài)在8w qps。nginx+php在08年時已經(jīng)優(yōu)化到6000 qps，目前的服務(wù)器設(shè)備（雙核16cpu+64G內(nèi)存）達到2、3wQps應(yīng)該也是不難的事情（這個的最新數(shù)據(jù)我不知道）。上述配置至少應(yīng)該能夠在5s內(nèi)完成10w次redis的incr操作。加上系統(tǒng)各系統(tǒng)對請求隊列的支持，可以幾乎做到不報錯，短暫延遲。

如果考慮1臺redis請求量會很高，可以考慮分片，每臺分5w。

當然，這是在僅僅思考不到1分鐘內(nèi)給出的方案，從現(xiàn)在來看，haproxy是可以不要，nginx扛并發(fā)連接的能力也不錯。所有的細節(jié)還需要通過壓力測試進行驗證。而實際情況加上對其他服務(wù)的依賴（我不知到還有哪些，抽絲剝繭去除干擾），方案也會更加復(fù)雜一些。據(jù)電商老大講，實際情況是，秒殺的服務(wù)用了十幾臺服務(wù)器，秒殺的時候偶爾出現(xiàn)一些故障，小米做秒殺的同學(xué)，壓力很大哦。

如果你提到要記錄中簽的用戶的uid和中簽號碼，還是redis吧。

（突然wps的linux版崩潰了，只能恢復(fù)到這里，后面的部分內(nèi)容是重寫的，可能有點混亂）

針對剛才的問題，我在白板上畫了個簡單的架構(gòu)圖：haproxy+nginx/php+redis，haproxy和nginx/php都是可線性擴展的，redis可以通過sharding來實現(xiàn)擴展。理論上講，一個可擴展的架構(gòu)是可以滿足任何性能要求的，更何況如此簡單的邏輯，單機性能已經(jīng)可以做到非常高了。

電商王姓負責人在問我方案時問這個需求會有哪些難點？我看著白板笑笑：目前看，應(yīng)該不存在難點。如果有問題，應(yīng)該看日志和服務(wù)狀態(tài)以及服務(wù)器狀態(tài)。

?

第四面聊得很頭機，對方幾次想結(jié)束時都突然冒出來一個問題，每一個都會討論比較久，比如后臺的一些計算操作是否換成java更合適，因為java可以更嚴謹。我說這可能不是語言的問題，而是程序員習(xí)慣和素質(zhì)的問題，如果想換，其實我倒是更愿意嘗鮮，比如用go，還可能可以同時滿足性能的問題。

還有突然聊到持續(xù)集成，我坦言，我對持續(xù)集成的理解停留在用工具實現(xiàn)自動測試和發(fā)布這樣的層面上，沒有實操經(jīng)驗。但我個人的一個粗淺的認知是：持續(xù)集成的前提是自動化測試，自動化測試的兩個難點：1,自動化測試用例的設(shè)計；2,程序員對自動化測試的理解和心理反抗程度。我在目前單位有過短暫的嘗試：專業(yè)的傳統(tǒng)測試人員對測試用例進行設(shè)計，程序員接收到的需求應(yīng)該包括正向邏輯的產(chǎn)品需求和測試用例的需求。開發(fā)工作完成的標記是：自己寫的測試用例在自己的代碼上完全通過，代表自己一項開發(fā)工作的完成。

說到這里，對方不禁雙手伸出拇指！（哈哈哈哈）

或多或少也還有一些別的話題，我自認為那晚像演講一樣很精彩，只不過時間已過午夜，其他的一些細節(jié)不太記得了，如果想起或小米參加面試的同學(xué)有提起，我再補充了。

整場小米的面試兩個部門加起來共計約7個小時，這是我經(jīng)歷過的最長時間的面試了……小米的面試很辛苦，今天碼字也很辛苦，現(xiàn)在已經(jīng)是凌晨1點半了，如果你覺得上面的經(jīng)過對你有所幫助或是有意思，就捧個錢場或人場吧：?http://me.alipay.com/chunshengster

?

?

?

?

參考：

?

1. Profiling: From single systems to data centershttp://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/ko//pubs/archive/36575.pdf
2. X-Trace: A Pervasive Network Tracing Framework
   https://www.usenix.org/conference/nsdi-07/x-trace-pervasive-network-tracing-framework
3. http://blog.chunshengster.me/2013/05/smp_irq_affinity.html
4. http://weibo.com/1412805292/zvNrDsqtT
5. http://weibo.com/2173311714/zw40tv3D2
6. http://blog.chunshengster.me/2013/07/high_performance_rsyslogd.html
7. http://www.wandoujia.com/blog/from-qa-to-ep

總結(jié)

以上是生活随笔為你收集整理的三十之惑–面霸的八月（第二部分）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。