短網址網站開發運維的經驗分享與總結
所謂隔行如隔山，不干這一行，不懂這一行的難。
隨著用戶的逐漸增多，ft12短網址的日訪問PV終于突破了50萬，但其中摻雜著一半喜與一半憂。喜的是自己的短網址站得到了廣大用戶的認可，憂的是如何處理這么大的流量。期間，服務器分別經歷了內存報警、IO 瓶頸后，CPU爆表等等問題，幾乎使短連接站癱瘓。
前景交代
短網址由于其特殊性，所以非常難盈利，因此硬件特別寒磣（各別土豪站長可以直接無視這一條），各方面的投入，如人力、技術、時間等也不能和其他大網站比。
用來運營網址縮短網站的服務器采用的硬件是： 阿里云入門型，2G內存，雙核彈性ECU，后期又增加了一個 RDS關系型數據庫替代原有的MYSQL數據庫。
硬件成本計算：
既然項目本身基本沒法帶來收益，要生存就只能充分壓榨硬件，大膽使用新技術。根據國內云的計費方式，一般收費的維度是
阿里云入門型的ECS每月200元（主要是帶寬貴，我們選用的是5M的獨立帶寬）
由此我們做了對應的技術選型：
centos：這個不用解釋了吧？windows系統可是資源大戶
Nginx：下雨天，Nginx和centos更配^_^
RDS：性能好，熱數據少內存開銷也少，最主要的是能夠實時備份，數據庫的安全最重要
Redis：事實上RDS數據庫的讀寫非常耗時耗力，通過Redis緩存進行讀取，然后傳遞給RDS會減輕很多壓力
nodejs(with coffeescript)：后期新增，node.js 是天生的異步
supervisord：監控進程
來照張相——咔嚓 
開發與運維
鑒于目前項目投入的開發和運維都只有我一個人，那就可以美其名曰：DevOps 啦。聽上去是不是很高端大氣國際化。
短鏈接的訪問特征
二八法則基本適用（可以更夸張的說一九原則）：不到20% 的 短鏈接 占用了 超過80% 的資源。
監控先行
很多小團隊犯的第一個毛病就是不做監控，等到用戶來告訴你網站無法打開的時候就太晚了。為了省事我們用了監控寶和阿里云監控（主要阿里云監控有免費短信）。
每次出現無法打開網站的狀態時，都應該定位此次問題的原因。如果頻次增加，就要考慮應對策略了。loadavg 很好地反應了系統的負載，可以判斷是否硬件出現瓶頸。
如果是在事發時間，我們可以借助這些工具查看系統狀態：htop（定位哪個進程的問題）、iftop（是否有異常的流量和ip）、iotop（定位 io 瓶頸）。此外就是看日志。
如果事發時在睡覺，那么就看監控歷史記錄。
經驗總結一：硬盤太?。ㄓ捎谫Y金問題，服務器開始買的是乞丐版）
MongoDB在硬盤容量不夠的時候會拒絕啟動。而如果之前沒有使用 lvm 這類工具，將無法快速擴展容量，而國內的云不像 Linode 那么智能地在后臺提供容量的一鍵 resize(雖然這個功能曾把文件系統搞出錯了)。后果很可能是停機幾個小時。這時候，假設你真的不想去擴容服務器的硬盤，那么，請關閉NGINX以及MongoDB的日志，這是硬盤占用的大戶。
經驗總結二：最大打開文件描述符
異步模式下不可避免遇到新問題——最大打開文件描述符。我們先后遇上了 tornado 和 nginx 的最大打開文件描述符問題。 tornado 的表現為：CPU 100%，日志里出現500；Nginx 則在日志里報錯，打開緩慢。
要避免此類問題，要做相應 ulimit 的設置。
用ulimit -n顯示的只是當前會話的（!important）。正確做法是查看進程的 limits： cat /proc/{$pid}/limits
Nginx 的配置文件里還需要設置兩個參數：
1 2 | worker_connections 9999; #根據自己的情況設置 worker_rlimit_nofile 60000; #根據自己的情況設置 |
下圖是 nginx 達到上限的監控圖，很明顯被卡在1000左右了 —— Linux 默認限制為 1024。
經驗總結三：如果想要異步，請把Python換成nodejs
說實話，用 Python 來設計的過程可不是一個愉快的過程。為了避免潛在編碼問題，我們使用了 python3。下面的問題是：
缺乏異步的支持：
Redis 異步驅動只支持 Python2（當然，等了大約半年后 tornado-redis 的作者終于更新了對 python3 的支持）。
不少組件仍然無法支持 python3，
pip install后直接報錯的感覺就是：傻眼了。Bitly 的 asyncmongo 簡直是沒有文檔，最后只能選了 Motor。
Tornado 本身的文檔也不夠詳盡
后來一部分組件使用 nodejs 開發后，簡直是相見恨晚，CoffeeScript 語法糖的表現也很出色。
經驗總結四：不要選擇MYSQL
數據庫幾乎是web應用里最關鍵的一部分，越是有大局觀的技術人員越會謹慎選型。 事實上我們把所有壓力都放 MongoDB 的做法還是過于激進了。
對于幾千萬張表的數據庫，一點點的優化和改進，對性能的影響會非常大（一點也不夸張?。?。一定要用發展的眼光去看待數據庫，強烈建議在規劃初期，就把數據庫進行分表處理，減輕查詢時間和CPU的占用
阿里云RDS 的范式化與反范式化。
幾乎所有對 RDS一知半解的人都會告訴你不要用 SQL 的思維來思考RDS，要使用內嵌文檔來實現需求。但是他們忘記告訴你，不斷增長的內嵌文檔將導致 IO 瓶頸（參考《深入學習 MongoDB》73頁）。
事實上范式化和反范式化（內嵌文檔）還有很多要考慮的因素。
復雜查詢時 MongoDB 的無力
在面對需要計算的查詢時，MongoDB 的 map-reduce 很慢；復雜情況下對內嵌文檔處理有難度；Documents 比 MySQL 更少。年輕人，不要在 mysql 遇到問題時第一時間想到替換數據庫。
就這個項目而言，統計部分要快速出多樣報表時明顯有難度。
不要等到著火了才想起 RDS數據庫
如果 RDS 寫入壓力大，并且沒有做分片，那么單純加機器不會緩解寫入壓力。如果是讀取壓力倒有所幫助。
從單機到 replSet 起碼需要鎖住數據庫。程序代碼也需要修改。打算切換到 replSet 的話，需要提前做準備。
最后我們的做法是將頻繁更新的數據放 redis，定時刷入數據庫，效果很明顯。
正確使用 Redis
控制內存，控制起步成本
如果你打算省錢的，就不要把所有東西都放 Redis 里，哪怕看上去數據量不大——時間久了也占了不少內存。而在 MongoDB 里只有熱數據占內存。 二八法則也適用這種情況：熱數據只占20%。
當然如果你是土豪請你走開！
不要用 pub/sub 做隊列
如果不想丟失數據就不要用 pub/sub 做隊列。進程重啟時將丟失訂閱管道的信息。你可以用 lpush 和 brpop 來實現隊列。
受夠阿里云了
如果被 DDOS 攻擊怎么辦？直接黑洞，至少半小時內服務器無法開動，直接氣死你
為什么所謂的國際大品牌io性能能如此之差，讀寫大約 4-6M/s 的就到其瓶頸了
最后的忠告
多讀書，爭取站在巨人的肩膀上。
