小程序日均900萬的pv晋涣，超出想象，流量一路漲上來沉桌，服務(wù)器壓力太大谢鹊，各種宕機(jī)，不得不開始各種優(yōu)化留凭。
首先硬件的升級是必不可少佃扼，是革命的本錢，硬件升級如下
1 單機(jī)
2單機(jī)+云數(shù)據(jù)庫
3單機(jī)+云數(shù)據(jù)庫+6G的redis緩存
4五臺服務(wù)器負(fù)載均衡 + 云數(shù)據(jù)庫多臺主從讀寫分離 + 16G的redis緩存
5十臺服務(wù)器負(fù)載均衡 + 云數(shù)據(jù)庫多臺主從讀寫分離 + 32G的redis緩存
因為我們的小程序有很少圖片文件蔼夜，沒有考慮CDN和oss文件存儲
硬件不夠用了就升級兼耀，不過可以一個月一個月的買，不然太貴了
下面的按一條一條的寫求冷，想到哪里寫哪里瘤运。
1、分析瓶頸匠题，小程序是兄弟公司的新手做的拯坟，不過效果還挺好，拿到我們這邊來推廣韭山，沒想到流量一路上漲郁季。當(dāng)流量多了以后冷溃，首先系統(tǒng)的瓶頸出現(xiàn)在數(shù)據(jù)庫，查詢很慢梦裂，看了看表似枕，索引做的不好，甚至有些關(guān)鍵的地方都沒有索引年柠，趕緊加上索引凿歼。
數(shù)據(jù)庫的壓力剛緩解一會，服務(wù)器cpu的占用一直在90%以上冗恨，甚至出現(xiàn)宕機(jī)毅往，分析了一下業(yè)務(wù)，我們的小程序主要是社交出題答題類的派近，并沒有很高的計算需求攀唯，也就在最后用戶生成分享圖片的地方會有計算壓力，果然在從單機(jī)擴(kuò)展到負(fù)載均衡以后渴丸，服務(wù)器的cpu沒有再出現(xiàn)過壓力侯嘀。從此壓力主要圍繞在數(shù)據(jù)的讀和存這一塊，也就是數(shù)據(jù)庫和redis壓力
2谱轨、redis是個好東西戒幔，每次能正確的緩存常用的數(shù)據(jù)，數(shù)據(jù)庫的壓力就能減輕很多土童。redis有兩種緩存思想诗茎，一是針對數(shù)據(jù)庫緩存，在用戶寫入數(shù)據(jù)的時候例如出題献汗、答題敢订，往數(shù)據(jù)庫和redis中都寫入，查詢的時候先插redis的數(shù)據(jù)罢吃，沒有的話從數(shù)據(jù)庫中瘸纭；二是針對接口緩存尿招，直接緩存接口返回的json數(shù)據(jù)矾柜，用戶再次查相同的內(nèi)容，直接返回json數(shù)據(jù)就谜。我個人比較喜歡第二種緩存方式怪蔑，簡單高效，但要針對數(shù)據(jù)不怎么變化的接口丧荐，根據(jù)查詢條件生成合理的redis key值缆瓣，還要設(shè)置合理的過期時間，不然數(shù)據(jù)量太大篮奄。例如有一個接口是用戶查詢自己之前出的題及正確答案捆愁，因為自己出的題不可能再變，就根據(jù)他的這一套題的id進(jìn)行緩存窟却；
3昼丑、負(fù)載均衡，將流量分發(fā)到不同的服務(wù)器上進(jìn)行處理夸赫，對cpu的壓力大大減輕菩帝，但因為數(shù)據(jù)庫的數(shù)據(jù)要共享，只能用云數(shù)據(jù)庫茬腿，對數(shù)據(jù)庫的幫助不明顯
未完待續(xù)
4呼奢、小程序矩陣 社交類小程序免不了分享之類的操作，使用多個小程序部署切平，小程序之間使用unionid互通握础，減小微信突然抽風(fēng)封你功能或小程序帶來的損失
5、業(yè)務(wù)代碼優(yōu)化
6悴品、數(shù)據(jù)庫表結(jié)構(gòu)問題
為了避免過多的join聯(lián)合查詢禀综，可以采取以空間換時間的策略，例如用戶的出題表苔严，肯定會存用戶的id定枷，然后再根據(jù)id去用戶表里查昵稱，如果只是查昵稱就不劃算了届氢，干脆在出題表里也存昵稱欠窒，就不用去用戶表里查詢了，只是舉個例子
7退子、前端提交數(shù)據(jù)過濾
前端數(shù)據(jù)過濾及驗證岖妄，雖然并不能保證100%安全，但能大大的減少bug出現(xiàn)的風(fēng)險和可能大大減少服務(wù)器的壓力
8寂祥、上千萬條記錄甚至上億記錄的大表衣吠，不要使用limit分頁查詢，即使有索引壤靶，速度一定慢到懷疑人生缚俏，一般類似的需求，不如直接使用主鍵的區(qū)間贮乳，例如十萬的區(qū)間按主鍵取數(shù)據(jù)忧换，id 1100000,100000200000，以此類推向拆，這樣的取
9亚茬、開發(fā)時很多人都有喜歡到處記日志的習(xí)慣，問題這些日志隱藏在代碼中浓恳，也不影響使用刹缝，但當(dāng)訪問量多起來碗暗，這些日志文件動輒就達(dá)到上G的大小，浪費(fèi)磁盤空間和IO梢夯，要是只是錯誤日志也就罷了
10言疗、各種手機(jī)設(shè)備的兼容性問題
