資深程序員實例總結分享短網址開發運維經驗

　　每個蘿卜下都隱藏一個坑。

　　前段時間955短網址日重定向次數最高達400萬，主要開銷是重定向請求的用戶數據儲存與分析。分別經歷了內存瓶頸、IO 瓶頸後，高峰期達到 CPU 上限，幾乎搾干了機器，下文是經驗總結分享。

　　前置條件

　　由於短網址很難盈利，硬件特別寒碜，帶著鐐铐跳舞反而別有風味，當然，人力投入，技術方面也不能和其他大網站比，所以如果要拍磚請輕下手——哎喲。

　　我們采用的硬件： 盛大雲微型，1G內存，單核共享型 CPU。 後期追加了一個同等配置的內網機器做 MongoDB replSet。

　　Startup 硬件成本：

　　既然項目本身基本沒法帶來收益，要生存就只能充分壓搾硬件，大膽使用新技術。根據國內雲的計費方式，一般收費的維度是

　　內存：使用異步模式代替同步多進程。

　　帶寬：2M雙線，301並不需要太多的帶寬開銷

　　硬盤：雲硬盤，按容量收費

　　CPU：單核

　　由此我們做了對應的技術選型：

　　Nginx：無需多說了吧?

　　Tornado：Facebook 開源的 python 異步微框架

　　MongoDB：性能好，熱數據少內存開銷也少

　　Redis：事實上 MongoDB 寫入的 IO 開銷太大

　　nodejs(with coffeescript)：後期新增，node.js 是天生的異步

　　supervisord：監控進程

　　來照張相——咔嚓

　　開發與運維

　　既然目前項目投入的開發和運維都只有我一個人，那就可以美其名曰：DevOps 啦。聽上去是不是很高端大氣國際化。

　　用戶特點

　　二八法則基本適用：20% 的 URL 占用了 80% 的資源(尤其是我們默認為所有短網址開啟了統計之後)。

　　監控先行

　　很多小團隊犯的第一個毛病就是不做監控，等到用戶來告訴你網站無法打開的時候就太晚了。為了省事我們用了監控寶和阿裡雲監控(主要阿裡雲監控有免費短信)。

　　每次出現無法打開網站的狀態時，都應該定位此次問題的原因。如果頻次增加，就要考慮應對策略了。loadavg 很好地反應了系統的負載，可以判斷是否硬件出現瓶頸。

　　如果是在事發時間，我們可以借助這些工具查看系統狀態：htop(定位哪個進程的問題)、iftop(是否有異常的流量和ip)、iotop(定位 io 瓶頸)。此外就是看日志。

　　如果事發時在睡覺，那麼就看監控歷史記錄。

　　慘痛教訓一：硬盤容量——為將來留下後路

　　MongoDB在硬盤容量不夠的時候會拒絕啟動。而如果之前沒有使用 lvm 這類工具，將無法快速擴展容量，而國內的雲不像 Linode 那麼智能地在後台提供容量的一鍵 resize(雖然這個功能曾把文件系統搞出錯了)。後果很可能是停機幾個小時。

　　慘痛教訓二：最大打開文件描述符

　　異步模式下不可避免遇到新問題——最大打開文件描述符。我們先後遇上了 tornado 和 nginx 的最大打開文件描述符問題。 tornado 的表現為：CPU 100%，日志裡出現500;Nginx 則在日志裡報錯，打開緩慢。

　　要避免此類問題，要做相應 ulimit 的設置。

　　用ulimit -n顯示的只是當前會話的(!important)。正確做法是查看進程的 limits： cat /proc/{$pid}/limits

　　Nginx 的配置文件裡還需要設置兩個參數：

　　worker_connections 9999; #根據自己的情況設置

　　worker_rlimit_nofile 60000; #根據自己的情況設置

　　下圖是 nginx 達到上限的監控圖，很明顯被卡在1000左右了 —— Linux 默認限制為 1024。

　　慘痛教訓三：Python 不是天生異步的語言

　　說實話，用 Python 來設計的過程可不是一個愉快的過程。為了避免潛在編碼問題，我們使用了 python3。下面的問題是：

　　缺乏異步的支持：

　　Redis 異步驅動只支持 Python2(當然，等了大約半年後 tornado-redis 的作者終於更新了對 python3 的支持)。

　　不少組件仍然無法支持 python3， pip install 後直接報錯的感覺就是：傻眼了。

　　Bitly 的 asyncmongo 簡直是沒有文檔，最後只能選了 Motor。

　　Tornado 本身的文檔也不夠詳盡

　　後來一部分組件使用 nodejs 開發後，簡直是相見恨晚，CoffeeScript 語法糖的表現也很出色。

　　慘痛教訓四：謹慎選用數據庫

　　數據庫幾乎是web應用裡最關鍵的一部分，越是有大局觀的技術人員越會謹慎選型。 事實上我們把所有壓力都放 MongoDB 的做法還是過於激進了。

　　MongoDB 的范式化與反范式化。

　　幾乎所有對 MongoDB一知半解的人都會告訴你不要用 SQL 的思維來思考 MongoDB，要使用內嵌文檔來實現需求。但是他們忘記告訴你，不斷增長的內嵌文檔將導致 IO 瓶頸(參考《深入學習 MongoDB》73頁)。

　　事實上范式化和反范式化(內嵌文檔)還有很多要考慮的因素。

　　復雜查詢時 MongoDB 的無力

　　在面對需要計算的查詢時，MongoDB 的 map-reduce 很慢;復雜情況下對內嵌文檔處理有難度;Documents 比 MySQL 更少。年輕人，不要在 mysql 遇到問題時第一時間想到替換數據庫。

　　就這個項目而言，統計部分要快速出多樣報表時明顯有難度。

　　不要等到著火了才想起 MongoDB replSet

　　如果 MongoDB 寫入壓力大，並且沒有做分片，那麼單純加機器不會緩解寫入壓力。如果是讀取壓力倒有所幫助。

　　從單機到 replSet 起碼需要鎖住數據庫。程序代碼也需要修改。打算切換到 replSet 的話，需要提前做准備。

　　最後我們的做法是將頻繁更新的數據放 redis，定時刷入數據庫，效果很明顯。

　　正確使用 Redis

　　控制內存，控制起步成本

　　如果你打算省錢的，就不要把所有東西都放 Redis 裡，哪怕看上去數據量不大——時間久了也占了不少內存。而在 MongoDB 裡只有熱數據占內存。 二八法則也適用這種情況：熱數據只占20%。

　　當然如果你是土豪請你走開!

　　不要用 pub/sub 做隊列

　　如果不想丟失數據就不要用 pub/sub 做隊列。進程重啟時將丟失訂閱管道的信息。你可以用 lpush 和 brpop 來實現隊列。

　　受夠盛大雲了

　　內網主機完全不能訪問外網。你想 apt-get update 下?臨時買帶寬吧。

　　被 DDOS 攻擊?直接斷網，沒有任何通知，你還百思不得其解。

　　io性能太差，讀寫大約 5-6M/s 的時候就要掛了。當然阿裡雲的好像更差。

　　最後的忠告

　　「年輕人啊，要多讀書多看報，多思考多學習」——萬峰

　　看到這裡肯定有不少人想噴我了，來吧，我的微博是： @dai-jie ，有錯我改，我改……

　　原鏈接：http://www.pmtoo.com/opinion/2013/0909/3553.html