背景介紹

---

宅米是一家專注校園電子商務的互聯(lián)網(wǎng)企業(yè)，目前主營校園超市O2O。公司成立于2014年11月，僅僅一年多的時間，公司即經(jīng)過4輪融資，覆蓋近200座城市，1000多所大中專院校，10000多棟宿舍樓，日均訂單20萬，峰值訂單50萬。

?

初識架構(gòu)

---

這樣的系統(tǒng)能不能應對今后快速的業(yè)務發(fā)展？性能問題會不會成為持續(xù)增長的交易量的瓶頸？系統(tǒng)能不能撐得住訪問高峰期的大規(guī)模并發(fā)訪問？ 性能優(yōu)化成為這個時候最重要的工作，于是安排專門的工程師進行性能測試和性能優(yōu)化，從架構(gòu)、代碼、數(shù)據(jù)庫、運維各個層面梳理系統(tǒng)狀況，發(fā)現(xiàn)系統(tǒng)瓶頸，進行針對性優(yōu)化。

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

?

性能測試

---

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

當初按照二八法則推算峰值每秒單量為556筆，以此為基準根據(jù)Nginx日志分析后端接口調(diào)用頻率，推算出接口調(diào)用比率前20的請求，以此構(gòu)造測試場景。

在執(zhí)行性能測試時，我們使用Jmeter作為性能測試工具，利用了云服務提供的系統(tǒng)資源監(jiān)控作為基礎。

小強點評：很多人一直糾結(jié)并發(fā)數(shù)怎么去算，其實算法非常多，在小強性能測試培訓班中就講了大概4種算法，個人覺得根本不存在準確不準確的問題，關鍵是在你的應用場景，這世上哪里有絕對的準確？

架構(gòu)優(yōu)化

---

性能測試結(jié)果并不樂觀，雖然系統(tǒng)此前使用了分布式緩存對熱點數(shù)據(jù)進行緩存，但是比較隨意，哪些數(shù)據(jù)需要緩存，失效策略如何設置都沒有認真分析和設計。性能測試后決定規(guī)范緩存使用，盡可能將各種頻繁讀取的數(shù)據(jù)全部緩存起來，并將Redis服務器做集群和主從復制部署。

小強點評：緩存帶來的效果是明顯的，一般對于大量數(shù)據(jù)的查詢我們都要首先考慮緩存方面的優(yōu)化。當然，這里說的是后端緩存，對于前端的緩存也需要考慮。

此外還使用第三方CDN服務進行靜態(tài)文件訪問加速，產(chǎn)品圖片、JavaScript文件、CSS文件等都通過CDN加速，同時通過Nginx反向代理服務器提供靜態(tài)文件的前端緩存。

小強點評：這些都是偏向于前端性能優(yōu)化方面的問題了，感興趣的可以看我前端性能測試視頻。

性能測試發(fā)現(xiàn)，系統(tǒng)主要瓶頸點在數(shù)據(jù)庫上，雖然使用Redis將熱點數(shù)據(jù)緩存起來，但是數(shù)據(jù)庫依然在并發(fā)量達到一定程度后表現(xiàn)出系統(tǒng)過載的情況。于是對數(shù)據(jù)庫進行主從分離。

?

sql語句優(yōu)化

---

性能測試過程中發(fā)現(xiàn)，由于此前主要精力都在關注如何快速實現(xiàn)業(yè)務，大量數(shù)據(jù)庫查詢語句寫得比較隨意，索引設計非常不合理。 結(jié)合性能測試中Mysql數(shù)據(jù)庫slow.log分析，定位慢查詢SQL追加index，然后利用解釋執(zhí)行計劃explain優(yōu)化SQL

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

?

數(shù)據(jù)庫連接池優(yōu)化

---

在做性能測試的時候發(fā)現(xiàn)在某些情況下有較為嚴重的性能問題。在高并發(fā)情況下，長時間施加壓力，應用程序出現(xiàn)不能訪問的狀況。

上網(wǎng)查找資料，發(fā)現(xiàn)很多人也遇到了C3P0的”APPARENT DEADLOCK”問題。

將C3P0切換成國產(chǎn)數(shù)據(jù)庫連接池Druid之后，狀況明顯好轉(zhuǎn)，類似問題再未出現(xiàn)過。

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

?

H5響應壓縮優(yōu)化

---

開啟Nginx gzip壓縮，降低App響應數(shù)據(jù)包大小，提高響應性能

小強點評：前端的性能優(yōu)化，不論是app、h5還是web都是一樣的，我們很多童鞋學的太死板，沒有做到一通百通。

?

訂單數(shù)據(jù)冷熱分離

---

隨著業(yè)務的持續(xù)發(fā)展，訂單表的數(shù)據(jù)會越來越多。按我們現(xiàn)在日訂單量20萬單預估，月訂單量則為600萬單，年訂單量則達到7200萬單，而且日訂單量還在不斷的增加，用不了多久，數(shù)據(jù)量就會超過MySQL的極限。 一開始我們考慮使用分布式數(shù)據(jù)庫的方案，對訂單表進行水平切分，使用訂單號進行hash，將訂單數(shù)據(jù)切分到多張表上。 進一步分析后發(fā)現(xiàn)，訂單數(shù)據(jù)具有明顯的冷熱不均的特點，即剛剛創(chuàng)建的訂單是熱數(shù)據(jù)，不同應用以各種方式訪問修改這些訂單。經(jīng)過一段時間以后，特別是訂單完成后，訂單訪問頻率急劇降低，而且只有訂單查詢這一種操作。于是我們考慮采取冷熱數(shù)據(jù)分離的策略，以控制熱庫中數(shù)據(jù)總量，保障訂單表數(shù)據(jù)量始終維持在一個可以接受的范圍內(nèi)，進而提供穩(wěn)定的數(shù)據(jù)訪問性能。

小強點評：我們總是覺得要用高級點的技術才顯得牛逼，其實這是裝逼。當年在新浪的時候我們對數(shù)據(jù)庫做了大量的分庫分表，但最后帶來的性能提升并不明顯。我一直強調(diào)技術是服務于業(yè)務的，只有把業(yè)務的特性明確了，根據(jù)業(yè)務來使用合理的技術才會能大的提升，否則就是適得其反。

總結(jié)

---

性能問題是實打?qū)嵉膯栴}，解決辦法也應該針對具體問題各個擊破。通過性能測試了解系統(tǒng)現(xiàn)狀，通過瓶頸分析發(fā)現(xiàn)具體問題，針對具體問題尋找解決方案，實現(xiàn)解決方案再進行性能測試，整個性能優(yōu)化形成閉環(huán)，系統(tǒng)得以持續(xù)優(yōu)化。

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

?

總結(jié)

以上是生活随笔為你收集整理的宅米网性能优化实践（内附小强点评）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。