書接上回，今天敘述小米的面試經(jīng)歷。這里可能有一些技術(shù)理解和技術(shù)方案，歡迎討論。另昨天共計收入7筆共95元，夠我喝幾杯咖啡了，謝謝所有捐錢的朋友。

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

小米：運維部

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

wilbur井源同兩位同事與我四人邊吃邊聊，我簡單介紹當(dāng)前的網(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)控這件事情我做了詳細(xì)一些的說明（詳見服務(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ò)接口的請求進(jìn)行監(jiān)控，對異常進(jìn)行匯報，通過收集日志的方式進(jìn)行可用性問題的發(fā)現(xiàn)）。當(dāng)然，還有必不可 少的是對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)化等。當(dāng)然，這是正經(jīng)的運維部門，我闡述了我對“運維”工作的理解：60%的分析整理工作加上40%的技能，分析整理能力是做好運維的基礎(chǔ)。

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

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

電商部

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

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

haproxy的服務(wù)器配置是按照100w并發(fā)的目標(biāo)進(jìn)行配置和優(yōu)化的，計劃100w客戶端連接，考慮每個客戶端連接可能產(chǎn)生1個內(nèi)部連接，按照每個連接消耗4k（此處修正為17K，haproxy的官方數(shù)據(jù)，見參考8,感謝 @GNUer 的修正）內(nèi)存來算，大約8G(此處修正為32G）內(nèi)存【這里的計算還需要再考慮，我擔(dān)心haproxy的每個連接消耗17k內(nèi)存是包含對內(nèi)部服務(wù)器的連接】，實際上往往比這個數(shù)字要大。目前達(dá)到的最大連接數(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)存，實際上遠(yuǎn)遠(yuǎn)永不到這么多，圖片服務(wù)的最外層cache，即Varnish，我們也是部署在haproxy服務(wù)器上的。

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

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

要保證服務(wù)器能夠接收大并發(fā)的連接請求是件不難的事情，但需要考慮一個細(xì)節(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)的連接進(jìn)行丟棄，以達(dá)到快速回收的目的，tw的默認(rèn)回收時間的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的方式進(jìn)行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的進(jìn)程數(shù)量?，F(xiàn)在基本上phpcgi都是運行在php-fpm中的了，其進(jìn)程池邏輯是我最贊賞的功能 之一。

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

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

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

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

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