5000萬pv小程序，高併發及緩存優化，入坑

小程序日均5000萬的pv，超出想象，流量一路漲上來，服務器壓力太大，各類宕機，不得不開始各類優化。

首先硬件的升級是必不可少，是革命的本錢，硬件升級以下

1 單機

2單機+雲數據庫

3單機+雲數據庫+6G的redis緩存

4五臺服務器負載均衡 + 雲數據庫多臺主從讀寫分離 + 16G的redis緩存

5十臺服務器負載均衡 + 雲數據庫多臺主從讀寫分離 + 32G的redis緩存

由於咱們的小程序有不多圖片文件，沒有考慮CDN和oss文件存儲

硬件不夠用了就升級，不過能夠一個月一個月的買，否則太貴了

下面的按一條一條的寫，想到哪裏寫哪裏。

一、分析瓶頸，小程序是兄弟公司的新手作的，不過效果還挺好，拿到咱們這邊來推廣，沒想到流量一路上漲。當流量多了之後，首先系統的瓶頸出如今數據庫，查詢很慢，看了看錶，索引作的很差，甚至有些關鍵的地方都沒有索引，趕忙加上索引。

數據庫的壓力剛緩解一會，服務器cpu的佔用一直在90%以上，甚至出現宕機，分析了一下業務，咱們的小程序主要是社交出題答題類的，並無很高的計算需求，也就在最後用戶生成分享圖片的地方會有計算壓力，果真在從單機擴展到負載均衡之後，服務器的cpu沒有再出現過壓力。今後壓力主要圍繞在數據的讀和存這一塊，也就是數據庫和redis壓力

二、redis是個好東西，每次能正確的緩存經常使用的數據，數據庫的壓力就能減輕不少。redis有兩種緩存思想，一是針對數據庫緩存，在用戶寫入數據的時候例如出題、答題，往數據庫和redis中都寫入，查詢的時候先插redis的數據，沒有的話從數據庫中取；二是針對接口緩存，直接緩存接口返回的json數據，用戶再次查相同的內容，直接返回json數據。我我的比較喜歡第二種緩存方式，簡單高效，但要針對數據不怎麼變化的接口，根據查詢條件生成合理的redis key值，還要設置合理的過時時間，否則數據量太大。例若有一個接口是用戶查詢本身以前出的題及正確答案，由於本身出的題不可能再變，就根據他的這一套題的id進行緩存；

三、負載均衡，將流量分發到不一樣的服務器上進行處理，對cpu的壓力大大減輕，但由於數據庫的數據要共享，只能用雲數據庫，對數據庫的幫助不明顯

未完待續

四、小程序矩陣　　社交類小程序免不了分享之類的操做，使用多個小程序部署，小程序之間使用unionid互通，減少微信忽然抽風封你功能或小程序帶來的損失

五、業務代碼優化   

六、數據庫表結構問題

爲了不過多的join聯合查詢，能夠採起以空間換時間的策略，例如用戶的出題表，確定會存用戶的id，而後再根據id去用戶表裏查暱稱，若是隻是查暱稱就不划算了，乾脆在出題表裏也存暱稱，就不用去用戶表裏查詢了，只是舉個例子

七、前端提交數據過濾

前端數據過濾及驗證，雖然並不能保證100%安全，但能大大的減小bug出現的風險和可能大大減小服務器的壓力

八、上千萬條記錄甚至上億記錄的大表，不要使用limit分頁查詢，即便有索引，速度必定慢到懷疑人生，通常相似的需求，不如直接使用主鍵的區間，例如十萬的區間按主鍵取數據，id 1~100000,100000~200000，以此類推，這樣的取 

九、開發時不少人都有喜歡處處記日誌的習慣，問題這些日誌隱藏在代碼中，也不影響使用，但當訪問量多起來，這些日誌文件動輒就達到上G的大小，浪費磁盤空間和IO，要是隻是錯誤日誌也就罷了

十、各類手機設備的兼容性問題