小程序日均5000萬的pv，超出想象，流量一路漲上來，服務器壓力太大，各種宕機，不得不開始各種優化。
首先硬件的升級是必不可少，是革命的本錢，硬件升級如下
1 單機
2單機+雲數據庫
3單機+雲數據庫+6G的redis緩存
4五台服務器負載均衡 + 雲數據庫多台主從讀寫分離 + 16G的redis緩存
5十台服務器負載均衡 + 雲數據庫多台主從讀寫分離 + 32G的redis緩存
因為我們的小程序有很少圖片文件，沒有考慮CDN和oss文件存儲
硬件不夠用了就升級，不過可以一個月一個月的買，不然太貴了
下面的按一條一條的寫，想到哪里寫哪里。
1、分析瓶頸，小程序是兄弟公司的新手做的，不過效果還挺好，拿到我們這邊來推廣，沒想到流量一路上漲。當流量多了以后，首先系統的瓶頸出現在數據庫，查詢很慢，看了看表，索引做的不好，甚至有些關鍵的地方都沒有索引，趕緊加上索引。
數據庫的壓力剛緩解一會，服務器cpu的占用一直在90%以上，甚至出現宕機，分析了一下業務，我們的小程序主要是社交出題答題類的，並沒有很高的計算需求，也就在最后用戶生成分享圖片的地方會有計算壓力，果然在從單機擴展到負載均衡以后，服務器的cpu沒有再出現過壓力。從此壓力主要圍繞在數據的讀和存這一塊，也就是數據庫和redis壓力
2、redis是個好東西，每次能正確的緩存常用的數據，數據庫的壓力就能減輕很多。redis有兩種緩存思想，一是針對數據庫緩存，在用戶寫入數據的時候例如出題、答題，往數據庫和redis中都寫入，查詢的時候先插redis的數據，沒有的話從數據庫中取；二是針對接口緩存，直接緩存接口返回的json數據，用戶再次查相同的內容，直接返回json數據。我個人比較喜歡第二種緩存方式，簡單高效，但要針對數據不怎么變化的接口，根據查詢條件生成合理的redis key值，還要設置合理的過期時間，不然數據量太大。例如有一個接口是用戶查詢自己之前出的題及正確答案，因為自己出的題不可能再變，就根據他的這一套題的id進行緩存；
3、負載均衡，將流量分發到不同的服務器上進行處理，對cpu的壓力大大減輕，但因為數據庫的數據要共享，只能用雲數據庫，對數據庫的幫助不明顯
未完待續
4、小程序矩陣 社交類小程序免不了分享之類的操作，使用多個小程序部署，小程序之間使用unionid互通，減小微信突然抽風封你功能或小程序帶來的損失
5、業務代碼優化
6、數據庫表結構問題
為了避免過多的join聯合查詢，可以采取以空間換時間的策略，例如用戶的出題表，肯定會存用戶的id，然后再根據id去用戶表里查昵稱，如果只是查昵稱就不划算了，干脆在出題表里也存昵稱，就不用去用戶表里查詢了，只是舉個例子
7、前端提交數據過濾
前端數據過濾及驗證，雖然並不能保證100%安全，但能大大的減少bug出現的風險和可能大大減少服務器的壓力
8、上千萬條記錄甚至上億記錄的大表，不要使用limit分頁查詢，即使有索引，速度一定慢到懷疑人生，一般類似的需求，不如直接使用主鍵的區間，例如十萬的區間按主鍵取數據，id 1~100000,100000~200000，以此類推，這樣的取
9、開發時很多人都有喜歡到處記日志的習慣，問題這些日志隱藏在代碼中，也不影響使用，但當訪問量多起來，這些日志文件動輒就達到上G的大小，浪費磁盤空間和IO，要是只是錯誤日志也就罷了
10、各種手機設備的兼容性問題