宅米網效能最佳化實踐（內附小強點評）

背景介紹

---

宅米是一家專注校園電子商務的網際網路企業，目前主營校園超市O2O。公司成立於2014年11月，僅僅一年多的時間，公司即經過4輪融資，覆蓋近200座城市，1000多所大中專院校，10000多棟宿舍樓，日均訂單20萬，峰值訂單50萬。

初識架構

---

這樣的系統能不能應對今後快速的業務發展？效能問題會不會成為持續增長的交易量的瓶頸？系統能不能撐得住訪問高峰期的大規模併發訪問？ 效能最佳化成為這個時候最重要的工作，於是安排專門的工程師進行效能測試和效能最佳化，從架構、程式碼、資料庫、運維各個層面梳理系統狀況，發現系統瓶頸，進行針對性最佳化。

小強點評：這種架構是初識架構，一般系統都是在這個架構上進行逐步演化的，掌握基本的架構知識對於測試工程師來說十分重要。

效能測試

---

校園零食購物的特點是在晚上10點左右進入高峰，在此前後一小時的交易量大概佔整天交易量的一半，也就是說，如果要設計一個日訂單100萬的系統，其實要承受的交易壓力是每小時50萬單。

當初按照二八法則推算峰值每秒單量為556筆，以此為基準根據Nginx日誌分析後端介面呼叫頻率，推算出介面呼叫比率前20的請求，以此構造測試場景。

在執行效能測試時，我們使用Jmeter作為效能測試工具，利用了雲服務提供的系統資源監控作為基礎。

小強點評：很多人一直糾結併發數怎麼去算，其實演算法非常多，在小強效能測試培訓班中就講了大概4種演算法，個人覺得根本不存在準確不準確的問題，關鍵是在你的應用場景，這世上哪裡有絕對的準確？

架構最佳化

---

效能測試結果並不樂觀，雖然系統此前使用了分散式快取對熱點資料進行快取，但是比較隨意，哪些資料需要快取，失效策略如何設定都沒有認真分析和設計。效能測試後決定規範快取使用，儘可能將各種頻繁讀取的資料全部快取起來，並將Redis伺服器做叢集和主從複製部署。

小強點評：快取帶來的效果是明顯的，一般對於大量資料的查詢我們都要首先考慮快取方面的最佳化。當然，這裡說的是後端快取，對於前端的快取也需要考慮。

此外還使用第三方CDN服務進行靜態檔案訪問加速，產品圖片、JavaScript檔案、CSS檔案等都透過CDN加速，同時透過Nginx反向代理伺服器提供靜態檔案的前端快取。

小強點評：這些都是偏向於前端效能最佳化方面的問題了，感興趣的可以看我的前端效能測試影片。

效能測試發現，系統主要瓶頸點在資料庫上，雖然使用Redis將熱點資料快取起來，但是資料庫依然在併發量達到一定程度後表現出系統過載的情況。於是對資料庫進行主從分離。

sql語句最佳化

---

效能測試過程中發現，由於此前主要精力都在關注如何快速實現業務，大量資料庫查詢語句寫得比較隨意，索引設計非常不合理。 結合效能測試中Mysql資料庫slow.log分析，定位慢查詢SQL追加index，然後利用解釋執行計劃explain最佳化SQL

小強點評：任何系統在sql語句方面多多少少肯定會有問題，一般我們的方法就是慢查詢監控>top N語句分析>最佳化改進。思路基本都是這樣，具體的做法各不相同，靈活應對。

資料庫連線池最佳化

---

在做效能測試的時候發現在某些情況下有較為嚴重的效能問題。在高併發情況下，長時間施加壓力，應用程式出現不能訪問的狀況。

上網查詢資料，發現很多人也遇到了C3P0的”APPARENT DEADLOCK”問題。

將C3P0切換成國產資料庫連線池Druid之後，狀況明顯好轉，類似問題再未出現過。

小強點評：C3P0確實有一些小bug。後來我們也用了阿里開源的Druid目前來看還是不錯的哦，可以嘗試一下。

H5響應壓縮最佳化

---

開啟Nginx gzip壓縮 ， 降低App響應資料包大小，提高響應效能

小強點評：前端的效能最佳化，不論是app、h5還是web都是一樣的，我們很多童鞋學的太死板，沒有做到一通百通。

訂單資料冷熱分離

---

隨著業務的持續發展，訂單表的資料會越來越多。按我們現在日訂單量20萬單預估，月訂單量則為600萬單，年訂單量則達到7200萬單，而且日訂單量還在不斷的增加，用不了多久，資料量就會超過MySQL的極限。 一開始我們考慮使用分散式資料庫的方案，對訂單表進行水平切分，使用訂單號進行hash，將訂單資料切分到多張表上。 進一步分析後發現，訂單資料具有明顯的冷熱不均的特點，即剛剛建立的訂單是熱資料，不同應用以各種方式訪問修改這些訂單。經過一段時間以後，特別是訂單完成後，訂單訪問頻率急劇降低，而且只有訂單查詢這一種操作。於是我們考慮採取冷熱資料分離的策略，以控制熱庫中資料總量，保障訂單表資料量始終維持在一個可以接受的範圍內，進而提供穩定的資料訪問效能。

小強點評：我們總是覺得要用高階點的技術才顯得牛逼，其實這是裝逼。當年在新浪的時候我們對資料庫做了大量的分庫分表，但最後帶來的效能提升並不明顯。我一直強調技術是服務於業務的，只有把業務的特性明確了，根據業務來使用合理的技術才會能大的提升，否則就是適得其反。

總結

---

效能問題是實打實的問題，解決辦法也應該針對具體問題各個擊破。透過效能測試瞭解系統現狀，透過瓶頸分析發現具體問題，針對具體問題尋找解決方案，實現解決方案再進行效能測試，整個效能最佳化形成閉環，系統得以持續最佳化。

小強點評：效能最佳化是一個持續的過程，沒有誰能一步最佳化道到位，也沒有誰可以最佳化到極致。他需要你有完善的知識體系，各個方面都要懂一些，並不是大家想的會一個LoadRunner或jmeter就可以完成的，這些只是效能中的很小的一部分而已。讓我們一起加油吧。