日均PV千萬的後臺是如何造成的

新書Java併發編程系統與模型已上線，歡迎拜讀。

       一個日均PV在千萬以上的移動客戶端，大概有20w-50w的註冊用戶數。爲了簡單起見,將一次PV來表明一次Http請求。在移動客戶端下，這些是純邏輯的，不包含靜態頁面的訪問和圖片的訪問。

併發量

       併發量的計算公式是pv/時間。不管是再複雜的請求平均響應時間在1秒之內，若是超過的1秒，那麼就說明須要調優或者從新設計當前的業務系統。一天一共是86400秒，那麼每秒支持的併發數爲100左右，也就是每秒大概100個併發。

服務器配置

       服務器是兩臺32G內存的8核處理器。其中一臺服務安裝上Niginx來作分發，另外一外一臺服務安裝上Redis來緩存。每臺服務器都安裝了Tomcat8。

Redis

       Redis因爲是走內存，因此基本上都是毫秒級響應。使用Redis，基本上80%的請求能夠在緩存中直接獲取。剩下的20%Mysql徹底能夠支撐住。能夠緩存熱點數據，甚至是直接緩存結果。可是緩存結果的時候要注意，只緩存正確的結果。曾經我犯過這樣的錯誤，將錯誤的結果緩存起來了，結果明明BUG已經修復，仍是顯示錯誤的頁面，排查了問題很久，結果就是Redis將錯誤的結果也緩存了。不必對Redis作僞集羣處理，單機的Redis其實在千萬級的PV下都是小case。

日誌

       日均PV千萬的系統，Tomcat的 access_log天天產生大概2g多的日誌。tomcat追加2g多的日誌是很快的，基本上都是毫秒級響應，要注意監控，由於天天2G多的日誌一個月下來就可能將服務器的資源佔滿。因此要定時清理，能夠寫一個shell腳本定時清理前一個月的日誌。

Mysql

       必定要注意加索引和慢查詢（不管是阿里雲仍是騰訊雲都提供慢查詢的工具。能夠清楚的看到是哪些sql致使了慢查詢）。1千多萬條記錄，1G多。索引大概7八百兆。update：2秒多左右。insert1秒多，目前尚未分表，Mysql單表三千萬的記錄示處理起來沒有絲毫障礙。

不要使用事務

       在高併發的狀況下不要使用事務。避免出現鎖等待。Spring的事務註解@Transactional慎用。若是不指定rollbackFor=Exception.class，將會出現事務一直running，致使事務沒法釋放或者事務根本沒法提交，這些未提交的事務因爲一直佔用鎖，那麼其餘sql一直鎖等待，致使更新數據失敗（血淋淋的教訓）。在Mysql 5.5版本之後，若是要查看mysql鎖相關的狀況，到information_schema庫下面，查看下面這些表：

innodb_trx         ## 當前運行的全部事務
innodb_locks       ## 當前出現的鎖
innodb_lock_waits  ## 鎖等待的對應關係
以及SHOW ENINGE INNODB STATUS來查詢INNODB的狀態與死鎖信息。複製代碼

故障排查

到了日均PV千萬，故障排除是重點。一旦線上出問題，影響面是至關廣的。因爲日誌分佈在多個機器上，若是線上出現問題，挨個機器排查日誌是一件很痛苦的事情。因此，構建好的監控系統是重點，推薦使用ELK構建一個快速的錯誤日誌查詢系統。

小廣告

新書《Java併發編程系統與模型》目前已經寫完一部分。可是實際上說實話，並不知道讀者們對java併發系統有哪些比較關心的，並且閉門造車實在是太累，寫出來怕沒人看。因此我放在這裏徵求你們的意見。你們能夠直接在評論裏提問或者但願做者重點描寫哪一部份內容，我好有針對性的寫。