關於泰捷商城項目與如何作一個高可用的網站

hi 各位， 上兩週一直都在作泰捷商城這個項目。這個項目的目的就是賣泰捷出品的WEBOX。這是我第一次作有關電子商務的網站。各類頭緒。其實原始需求很簡單，只賣一件商品，每星期只賣一次。 可是online to offline是歷來不是一件簡單的事情。由於這一次你所作的事情不只僅是在線上，而是不少事情要發生在線下的真實世界裏。這是一件很是的消耗精力的事情。但人又是生活在現實生活中。好比訂單的流轉。由於這一次咱們不只僅是作一個訂單，而是要把訂單真正的轉換成工廠生產出來的貨物，並且要經過物流公司真正的把貨物運送到顧客的手中。再好比說錢的流轉，要作到即時又安全。

6月24日，商城的第一次上線就遇到了很嚴重的問題。事情是這樣。因爲程序錯誤，在中午12點開售的時候，倒計時完成，可是購買入口的按鈕一直都沒有出現。因而當時全部人開始刷新咱們的官網。而咱們的官網的首頁有很是多的圖片，並且有的圖片甚至沒有進行壓縮。好比一張只有幾十個像素乘以幾十個像素的圖片居然有1.2MB的大小。所以產生了大量的併發鏈接和502錯誤。瀏覽器上咱們的官網根本打不開或者是打開速度很是慢，而這又會致使更多的頁面刷新。簡而言之，咱們的官網癱瘓而用戶請求像滾雪球同樣愈來愈大，也就是服務器雪崩。

不過不幸中的萬幸是雖然咱們的官網服務器崩潰了，可是咱們商城的服務沒有受到太多的影響。由於它們在物理上是隔離的。並且由於官網的崩潰，避免了用戶在同一時間蜂擁到商城服務器。由於崩潰的時候，咱們的運營人員在論壇和QQ羣等地方發佈咱們商城服務器真正的購買入口URL，但這種場景，用戶是沒有辦法在同一時間蜂擁到商城的。咱們賣完1000臺的時候已是中午1點半了，比預計的時間慢了太多。最初咱們預計在10分鐘以內就會賣光。

第一次泰捷售賣就這麼草草收場了。雖然不是特別成功，可是因爲這是泰捷成立以來賣出的第一批WEBOX，次日咱們仍是在公司開了幾瓶香檳。我想這是我最尷尬的一次慶功了。我人生中開過三次香檳。第一次是微信註冊用戶過2億（當時是做爲編外人員參加的，只吃飯不能抽獎）。第二次是微信海外註冊用戶超過1億。這是第三次了。不過此次確實是很是的尷尬，我都沒好意思喝香檳。

總結一下這一次的搶購。失敗的地方：

1 購買入口放在的頁面太多圖片，下載速度過慢。

2 程序錯誤致使購買入口沒法展現。

3 大量的用戶刷新請求致使雪崩。

成功的地方：

1 官網服務器與商城服務器分離，一邊崩潰的時候，另一邊沒有受到影響。

總結了第一次的得失，咱們改進的地方第一就是把咱們官網的展現購買入口的頁面作的很是簡單，基本上沒有圖片。第二在倒計時完成的時候不發起任何的動態請求。第三把官網所有改爲用CDN的形式訪問。其實基本上只須要把圖片所有放在CDN上就能夠了。不過所有放在CDN上更加保險一點，不過費用也更高。

再作一些更深層次的思考，如何作一個高併發的網站？ 如何預估一個網站的設計容量是否足夠？

首先要考慮系統可能可能出現瓶頸： 帶寬，併發鏈接數, CPU和IO、內存。如何評估帶寬和併發鏈接數不會超限？ 首先須要預估出你的PV。特別是搶購類的網站，用戶過來沖垮你可能就是開始的那一兩秒鐘的事情。因此你必需要搞清楚在那一兩秒中的時間有多少人一塊兒刷你的網頁。

而後咱們發現， 帶寬、併發鏈接數和內存是不太好經過壓力測試去模擬真實狀況的。由於利用壓力測試比較容易模擬的是大量的重複transaction， 而很差模擬的是大量的併發transaction。好比你能夠模擬100、200、400、1000個客戶端去重複發送請求產生壓力，但你很難去模擬1W,2W，10W個真實的客戶端請求。不過，能夠經過你的PV來計算出真實的帶寬、併發鏈接數和內存。

計算方法以下：

帶寬　＝　PV * 平均每頁面的資源數 *平均每一個資源的大小

併發鏈接數　＝　帶寬 / 平均下載速度 = PV * 平均每頁面的資源數 * 平均每一個資源的平均下載時間

舉例來講明：

PV是100/s， 每一個頁面要下載30個資源， 平均每一個資源大小爲100KB。

帶寬 =  100/s * 30 * 100 KB = 300MB/s 

平均每一個資源下載速度爲 100KB/s

併發鏈接數 = 300MB/s / 100KB/s = 3000

內存須要根據併發鏈接數來估算，

例如當你在100併發鏈接時 佔用1MB內存， 那麼3000併發鏈接時， 內存估計消耗爲30MB。 不盡準確，但能夠做爲參考。 

CPU基本和平均每秒請求量相關。

IO和平均每秒請求量先關，和CACHE大小和命中率相關。

在優化靜態網站的時候，能夠根據上面的公式來作優化。好比怎麼下降帶寬？ 回到公式， 帶寬　＝　PV * 平均每頁面的資源數 *平均每一個資源的大小。 能夠有不少方法， 好比咱們能夠經過下降平均每一個頁面的資源數量來解決， 減小一些圖片或者是其餘資源。也能夠下降每一個資源的平均大小，多使用304或者是壓縮一下圖片和JS等。 還有就是下降PV， 好比用一些AJAX的請求代替頁面的所有刷新等。

另一個問題就是動態請求的容量如何預估的問題了。首先要壓力測試去測試出全部動態請求的最大QPS。 找出QPS最低的那個請求即爲系統的短板。系統的最短板的QPS即爲動態請求的最大容量了。動態請求的最大容量不能知足系統的請求怎麼辦？ 縱向擴容， 平行擴容， 優化代碼， 實在沒有辦法，還能夠作過載保護，實現服務柔性可用。不過這個議題的內容太大，不作過多討論了。

通過總結， 咱們在7月1日的第二次搶購就比第一次進步了許多。人生中總有不少第一次的事情會發生， 第一次可能成功也可能會失敗。我想失敗不可怕，關鍵是吸收教訓作好下一次。