背景

最近收到一個求助，是某項目一天大概有30萬PV左右，現(xiàn)在遇到一個問題就是：服務(wù)器的資源占用率過高，特別是CPU經(jīng)常是100%。筆者初步查看了下這個項目的整體邏輯并不復(fù)雜，主要就是一個url2code表的插入與查詢操作，這個表主要是把對應(yīng)的url轉(zhuǎn)換成產(chǎn)品碼，有點像短網(wǎng)址或者抽獎系統(tǒng)的路徑與隨機碼對應(yīng)的表；而且服務(wù)器配置是2核心4GB。

按理說這個配置坑這種復(fù)雜度的30萬PV的業(yè)務(wù)是沒有問題的。筆者收到的求助是如何把項目的數(shù)據(jù)庫進(jìn)行分表及分庫操作，收到請求的第一反應(yīng)是這種級別的沒必要把架構(gòu)搞得太復(fù)雜，最多分表處理即可，因為業(yè)務(wù)流程本來就很單一，就一個核心流程一張數(shù)據(jù)表（大概50萬條記錄）和一張輔助表；而且業(yè)務(wù)復(fù)雜度和業(yè)務(wù)量并不是特別高。

分析

在一些較復(fù)雜業(yè)務(wù)流程中，50萬條記錄數(shù)據(jù)表進(jìn)行分表是很常見的手段，然而求助方自己其實已經(jīng)把歷史的數(shù)據(jù)分了2張表，新業(yè)務(wù)按照20萬一張表的容量進(jìn)行分表。然而這樣處理后資源占用雖然有所改善，但依然還是過高。于是求助筆者如何把項目快速、安全、低成本進(jìn)行分庫處理。

筆者大概了解了下他們這個項目，在同一條記錄的時候，設(shè)置了10分鐘的memcache實現(xiàn)的內(nèi)存緩存，一天刷新的數(shù)據(jù)次數(shù)也就一萬次以內(nèi)；即便是這樣為啥還是資源占用率超高？通過服務(wù)器分析發(fā)現(xiàn)是mysql進(jìn)程占用很高的CPU資源。按理說這么這種級別的量還不足以導(dǎo)致這么大的系統(tǒng)開銷。

在查看50萬條記錄的主表后發(fā)現(xiàn)問題所在：數(shù)據(jù)表的主鍵是數(shù)據(jù)的id號（自增的），但這個項目的場景并不像普通的CMS系統(tǒng)，在點擊列表具體的文章的時候通過文章的ID去查詢具體的詳細(xì)信息。而它這里是最頻繁的select是通過編碼code去查詢，這個code是個8位數(shù)的隨機字符（字母+數(shù)字組成），也就是普通的文本格式。查詢發(fā)現(xiàn)每次單條數(shù)據(jù)需要0.x秒的時間，如果剛好在某個時間段需要頻繁刷新數(shù)據(jù)則勢必使得mysql造成系統(tǒng)資源的極大開銷。

解決

這里解決這個問題自然不需要去重新購買數(shù)據(jù)庫做分庫處理，那樣開發(fā)成本也會提高（雖然這種復(fù)雜度的業(yè)務(wù)，進(jìn)行分庫也相對容易）。實際上只要優(yōu)化表的索引問題，即可在相同硬件資源情況下輕松抗住當(dāng)前的訪問量。

相關(guān)

上面本質(zhì)問題是由于開發(fā)人員mysql索引問題導(dǎo)致mysql占用CPU過高問題，最土豪的方式肯定是擴充CPU資源來緩解。這里也講一個類似的場景：某技術(shù)支持服務(wù)客戶咨詢說，他們的視頻點播系統(tǒng)，有時候總是很卡；原來的開發(fā)團(tuán)隊解決方案唯一的辦法就是讓他升級帶寬；而且現(xiàn)在服務(wù)器帶寬已經(jīng)升級到100MB獨享了。

看了他們這個項目實際上平常并沒有多少播放量，業(yè)務(wù)高峰僅僅是部分短時間內(nèi)，如他們像用戶（主要是內(nèi)部用）推送視頻類型的通知的時候。很顯然100MB獨享帶寬對于這么小的項目而言是有點浪費的，關(guān)鍵是體驗依然很差勁。因為100MB帶寬對于普通沒有多少訪問量的項目而言是太浪費了、而對于業(yè)務(wù)高峰（尤其是視頻這種大文件傳輸場景）依然不夠用。

其實稍微調(diào)整一下即可低成本解決這個問題，當(dāng)然前提是原來的項目代碼不要太爛。在上傳視頻的時候把視頻文件分離到與web服務(wù)獨立的存儲端（如阿里云OSS），然后用戶訪問的時候通過按量付費的CDN網(wǎng)絡(luò)訪問即可。這樣一來，只有高峰期需要調(diào)度更高的帶寬資源來應(yīng)對，而web頁面有10MB帶寬就足以支撐他這種訪問量的項目了；一年下來節(jié)省的投入可是非常可觀的。

最后

網(wǎng)站開發(fā)到底是否需要考慮高性能？這個問題肯定是需要考慮。但考慮從來不是為了考慮而考慮的，比如網(wǎng)上很多網(wǎng)友動不動就把一個小型網(wǎng)站的性能優(yōu)化搞成了千萬級流量網(wǎng)站的架構(gòu)，那樣成本自然也直線上升。

筆者認(rèn)為，優(yōu)化高性能是必須的；但這里“高性能”應(yīng)該是相對的。比如一個DAU只有1萬以下的普通的新聞資訊站點，幾乎只需要做做簡單的文件緩存或靜態(tài)化以及分離圖片等靜態(tài)資源就足以應(yīng)對這種訪問量；而做更復(fù)雜的架構(gòu)級的升級將大大提升成本。

其實最忌諱的就是本末倒置，比如文章開頭說的案例。咨詢者一上來就說了一堆諸如分庫、均衡負(fù)載等等概念，殊不知其實這種數(shù)據(jù)量的僅僅優(yōu)化索引問題以及其他適當(dāng)優(yōu)化（比如他們已經(jīng)做了memcache做的兩個核心節(jié)點的緩存：查url-code對應(yīng)數(shù)據(jù)，以及緩存了用戶查詢記錄；當(dāng)然也有人用Redis來做這樣的場景）即可。而一些細(xì)節(jié)問題不解決好，再所謂的“高階”方案也是不治本的。