書接上回，今天敘述小公尺的面試經歷。這裡可能有一些技術理解和技術方案，歡迎討論。另昨天共計收入7筆共95元，夠我喝幾杯咖啡了，謝謝所有捐錢的朋友。
小公尺：運維部
在小公尺是聊了兩個部門的，首先是運維部門，在 @wilbur井源 的熱情招待下，吃了頓大餐，抱歉的是我沒有帶足現金，所以付款時我無法「客氣」，改天補請。
wilbur井源同兩位同事與我四人邊吃邊聊，我簡單介紹當前的**的服務結構以及部分業務的技術設計，比如**架構的分布情況，分布式檔案系統fastdfs的使用狀況、redis和mysql的一些部署結構和技術，其中尤其對監控這件事情我做了詳細一些的說明（詳見服務可用性監控的一些思考以及實踐）， 中間提到了關於主動監控（主動監控是指通過運維和業務部門指定監控的系統資源、介面、頁面、日誌等，主動發現問題,警報級別較高）、被控監控的概念（指通 過jslib或客戶端lib對於所有的操作尤其是網路介面的請求進行監控，對異常進行匯報，通過收集日誌的方式進行可用性問題的發現）。當然，還有必不可 少的是對haproxy的執行和優化狀況（參見haproxy配置），mysql的架構及優化方式（見mysql架構及運維），redis常見的效能問題（參見redis架構及運維問題），fastdfs同其他分布式儲存mogilefs、tfs、lusterfs的在功能、運維成本上的橫向比較，多idccache的部署以及效能優化（參見多idccache部署），linux核心引數（參見linux核心配置）和讓我特別自豪的是關於網絡卡smp affinity/rpf/rfs的優化效果（參考3/4/5）的一些優化等。當然，這是正經的運維部門，我闡述了我對「運維」工作的理解：60%的分析整理工作加上40%的技能，分析整理能力是做好運維的基礎。
井源也詢問了幾個安全問題，我粗淺的理解是：從系統管理員（sa）的經歷來講，做好it系統規劃，合理區分伺服器角色，通過iptables是能夠阻止大多數接入層非法請求的；對於web業務的安全來講，sql注入、crsf等攻擊是因為對輸入輸入內容的過濾不嚴格導致的，在開發的過程中合理使用一些優秀框架或lib，也能夠避免大多數漏洞的產生；有個比較有意思的話題是關於溢位的，現在我已經不會計算溢位位址了，在我當script boy的時候研究過一點，忘光光了，慚愧……
井源這邊的效率很好，邊吃邊聊的氣氛很放鬆，不過很多問題都停留在一些思路和效果資料上，沒有勾勾畫畫的太多深入的**。
電商部
大約8點半左右到的電商部門，常規面試的第一輪都是技術，包括細節。面試官是位張姓的team leader。
在這輪面試的過程中，因為是在會議室，有筆有板，所以我邊講邊寫。大體上介紹了我對web服務架構的理解，我認為，web服務架構大體上離不開這樣幾個層面：接入層（負載均衡）、業務服務層、資料層，一般還會有不少的後台輔助程式進行同步、非同步的處理各種不適合在業務層融合的服務單元。 資料層可以包括db、cache、file等，資料層還可能會有很多中介軟體或**伺服器用來做資料層的負載均衡或是ha，以及sharding等。同面試 官詳細介紹了當前服務的公司在每一層所採用的技術，分別是：haproxy、nginx+php、twemproxy+redis、 mysql+rediscache、varnish+squid+nginx+fastdfs。
haproxy的伺服器配置是按照100w併發的目標進行配置和優化的，計畫100w客戶端連線，考慮每個客戶端連線可能產生1個內部連線，按照每個連線消耗4k（此處修正為17k，haproxy的官方資料，見參考8,感謝 @gnuer 的修正）記憶體來算，大約8g(此處修正為32g）記憶體【這裡的計算還需要再考慮，我擔心haproxy的每個連線消耗17k記憶體是包含對內部伺服器的連線】，實際上往往比這個數字要大。目前達到的最大連線數目測到過16w，在接入層的系統優化上分別有：網絡卡中斷優化（參考3/4/5），linux 核心引數優化（見linux sysctl.conf配置）。
值得一提的是，我們的haproxy伺服器都是64g記憶體，實際上遠遠永不到這麼多，服務的最外層cache，即varnish，我們也是部署在haproxy伺服器上的。
在最外層伺服器上，我們每天大約5億+（1-1.5億+的動態請求、3-4億+的請求）的請求量，共計使用7臺64g的dell r410,目前看負載還很低，從系統的各種資源上看，請求量翻倍應該是沒有問題的。
在最外層的伺服器配置上，有乙個問題值得注意，即sysctl.conf的配置中，timestamp必須為0，這個在tcp協議的擴充套件標準中有提 到，否有nat環境的客戶端連線有可能產生異常，異常的狀況可以在netstat -s 的輸出中看到。還需要注意的是timestamp=0的情況下，tw_reuse是不生效的。
要保證伺服器能夠接收大併發的連線請求是件不難的事情，但需要考慮乙個細節，每接收乙個請求，haproxy就需要至少分配乙個系統的tcp埠請 求後面的業務伺服器、cache伺服器，系統乙個ip位址可用的埠數最多為65535，一般還需要減去1024。值得考慮的是減 小 tw_bucket 的容量，讓系統在tw_bucket滿的狀況下，對tw狀態的連線進行丟棄，以達到快速**的目的，tw的預設**時間的2倍的 msl。還有乙個方式就是多配置幾個ip。
還有乙個問題，接入層的伺服器往往會開啟iptables，核心中nf的相關配置也是需要優化的，比如 nf_conntrack_max、nf_conntrack_tcp_timeout_established等。
在業務層的優化有nginx+php（fastcgi連線方式、php-fpm.conf配置中的優化）， 我的乙個經驗是，如果nginx同phpcgi執行在同一臺伺服器，採用unix socket的方式進行fastcgi協議的互動是效果最快的，比127.0.0.1的回環位址要快太多。我在08年優化過一台伺服器（dell 2960，16g記憶體），通過兩個步驟，將一台伺服器從900qps，優化到6000qps以上,其一是將fastcgi協議執行在unix socket上，其二是合理配置spawn-fcgi的程序數量。現在基本上phpcgi都是執行在php-fpm中的了，其程序池邏輯是我最讚賞的功能 之一。
如果nginx和php-fpm不在同一臺伺服器上，可以考慮使用fastcgi_keepalive的配置，實現nginx同fastcgi伺服器持久連線，以提高效率。
nginx+php-fpm提供的執行狀態非常有意義，nginx的status模組和php-fpm的status輸出可以告訴我們nginx進 程的請求處理狀況，php-fpm的status輸出可以告訴我們php-fpm的程序池設定是否合理。我們目前對這兩個資料通過nagios定期採集， 並繪製成圖表，很有「觀賞價值」。
php-fpm.conf的配置中還有幾個引數對優化比較重要，其一是程序自動重啟的條件pm.max_requests，其二是php-slow log的配置，slow log 是優化php**的非常重要的資訊。在我目前的環境中，php的慢執行日誌是通過rsyslog進行傳輸並集中分析的，以此反向推進開發對php **的優化。
php的伺服器在高併發的情況下，有可能因為伺服器本身可提供的埠數量的限制，無法同redis伺服器建立大量的連線，這時候可以在 sysctl.conf中配合timestamps=1 加上tw_reuse/tw_recycle的方式，進行埠快速**，以便更好的向資料層建立 連線，接入層的haproxy是不可以這樣的。
這一層還涉及到乙個安全問題，就是php**被修改並掛馬的狀況，我的解決方案是，將php-fpm的執行使用者同php**的屬主設定成不同的使用者，並且保證php-fpm的執行使用者不能對php**具有寫的許可權。
逝去的八月
八月，失去了我乙個摯愛的親人 外婆。外婆走了有乙個月了，希望外婆在那邊一切都好。這個月對於老婆來說也是難熬的乙個月，岳父做了個手術，病情也挺讓大家擔心的，手術很順利，希望他早日 也許是這些事情讓我感到了身體的重要，從本月8號 全域性健身日 起，開始跑步，快跑了乙個月了，繼續堅持，讓跑步成為一種習慣，...
八月，開始之路
題外話，又是這種月結式的博文，真沒辦法。先吼一聲，我終於也算是踏入職場的人了。好吧，這話後面滿滿的都是辛酸，尤其還是初來乍到乙個新城市，真的是各種支出和坑。不管怎樣，積極面對，暫時而已了。八月中旬入職，緊接著就是 天的封閉培訓。說實話，這些日子的美好，我已經開始懷念了。從全國各地飛來的各路同學，短短...
八月英語 近朱者赤
強烈推薦乙個大神的人工智慧的教程 個人 這個月接觸了新的學習材料，小豬佩琪，這個材料看了三部了，雖然是動畫，但是每一集都有新的東西，有的句子比較簡單，很容易引起共鳴，有的詞語之前是沒有接觸過的，但是根據畫面也就可以猜出是什麼意思。雖然佩琪的弟弟喬治只會說dinosaur，不過每次說都好好聽呀！還能體...