文章目錄
1.背景
針對暑期高峯時段的防範，保護暑期直播的穩定性。於暑期前和團隊一起進行防火演練以及壓測，一直缺乏整理，此次記錄並分享。
2.目標
接口QPS>=2W。
能容納50W同時在線。
可通過資源線性擴容快速支撐100萬在線能力。
3.前期思考
服務性能瓶頸點究竟由什麼決定？
機器？DB？架構？代碼？
木桶理論：
木桶理論又稱短板理論，其核心思想是一隻木桶盛水多少，並不取決於最高的木板，而取決於最短的那塊木板。
木桶原理應用在系統分析中，即系統的最終性能取決於系統中性能表現最差的組件，爲了提升系統整體性能，對系統中表現最差的組件進行優化可以得到最好的效果。
找尋當前系統最差的點至關重要。而上述的每一點都可能成爲系統的短板
4.壓測（以下壓測都基於優化完代碼之後，壓測不合格請第一時間考慮代碼設計問題！！！）
第一次壓測
1.第一輪壓測評估當前哪些接口性能低下，從這些接口入手。
2.開啓性能監控的工具。監控壓測過程中機器，DB等情況。
機器監控：http://book.open-falcon.org/zh/intro/index.html
DB監控：用的公司運維老師搭建的監控平臺，主要監控的點CPU，used_memory，OPS，traffic_in，traffic_out。
可參考此博客：https://blog.csdn.net/sanyaoxu_2/article/details/88832426
失敗告終
壓測某一接口導致redis主從切換，從庫只允許讀不允許寫，導致大量報錯。
監控顯示redisCPU一下幹到100。
內存毛刺狀。
失敗後的思考
1.爲什麼會壓切？
代碼層面的問題。進行review代碼。
壓測有四個場次，一個場次4W人，是用redis的set，一個zset 4W條數據，接口頻繁zrange，導致redis嚴重阻塞。
解決方案後面詳說。
解決上述問題後第二次壓測，又遇問題，性能依舊不高
監控：
| 指標 | 狀況 |
|---|---|
| 壓力機 | 未打滿 |
| db瓶頸 | 未滿 |
| 接口耗時排查 | 心跳初始化接口耗時過長，大量1s-120s |
| 機器指標 | 部分機器性能idle，cpu不正常 |
去kibana上繪製機器流量圖以及慢響應機器分佈圖
發現某一臺機器出問題。繼續跟進。因爲無線上機子root權限，聯繫運維老師一起查，運維老師沒有發現原因，選擇暫時下掉此機器[記得當時的方案是這樣子的]。
並且這一次有了重大的突破，發現不僅僅這一臺有問題。
這一批機子是新產的機子，發現運維配置新機器的時候，某監控服務配置有誤，導致性能普遍偏低。
第三次壓測
解決完如上問題之後，再壓測。
性能提高40%左右。
| 之前QPS | 現在QPS |
|---|---|
| 16000 | 28000 |
5.總結以及自己的一點心得
來當下的公司經歷了2次壓測了，每一次都有不同的問題出現。這次總結一下自己兩年來所碰到的問題。
1.代碼層面的問題
無論什麼時候，都應該先從自身找原因。看看是不是代碼層面的問題，代碼層面的瓶頸是最容易解決，成本最低的。
| 問題 | 詳細描述 | |
|---|---|---|
| 1 | 代碼質量問題 | 1.循環調用第三方。 2. 數據結構設計不合理。 大key，熱key情況常常出現。 3.二級緩存的必要性。 對於經常調用，但是一定時間內固定的數據，應設置合理的二級緩存，不必要每次都去調用第三方。 |
| 2 | 第三方接口 | 第三方接口拖累。 第三方響應時間過慢，若設置超時時間會導致數據有誤，若不設置會導致接口響應過慢。 |
| 3 | 對應的存儲架構 | 1.長連接與連接數的控制。 我們用的twemproxy與redis建立長連接，發現並不是server_connections連接數越多就越好。文檔：https://github.com/twitter/twemproxy 2.根據業務形態考慮相應的讀寫分離機制。 mysql的binlog。 3.pipeline和異步重要性。最好使用pipeline去批量寫入redis。不需要實時的數據可以考慮異步。 |
2.外部問題
網卡，機器CPU，DB問題等等
此問題比較難解決，需要根據具體情況具體分析。
3.必要時設計優雅降級方案
保護核心業務。通過配置後臺實現優雅降級。
4.針對業務合理拆分
如提交接口單獨集羣。耗費性能的統計接口單獨集羣。
不讓統計影響主流程提交。