1. SpringCloud高並發性能優化
1.1. 前言
當系統的用戶量上來，每秒QPS上千后，可能就會導致系統的各種卡頓，超時等情況，這時優化操作不可避免
1.2. 優化步驟
- 第一步：優化大SQL，對於多表關聯的SQL，當單表數據幾百上千萬行時，執行可能會達到好幾秒，對微服務系統來說，我是不建議join多表操作，除非是數據量少的維表，我們可以將一句大SQL拆分成多個過程，邏輯在JVM中完成
- 第二步：超時時間不要設的過長，一般一個接口的響應時間要控制在200ms以內，超時時間1s就夠了，一旦接近或超過1s，就要考慮是否要用，緩存，索引，NoSQL等手段優化下了
- 第三步：如果設置了1s超時，可能因為網絡的抖動，某次請求超過1s，這個時候需要設置合理的超時重試
- 第四步：設置重試，那就要考慮接口冪等性的問題，常見解決方案是建唯一索引，或者通過redis判斷下唯一id，保證接口被多次調用時不重復插入數據
1.3. Hystrix參數優化
- 我們知道Hystrix線程池的大小和超時時間我們都是可以設置的，線上環境，我們需要對這些參數進行調整，該如何調整呢？
- 假設你的系統B，預計QPS是30，每秒請求響應時間是200ms，那么可以算出30*0.2=6，然后再加點緩沖空間，比如4，那么總共就是6+4=10的線程數量，當然這個4你可以自己調整，這是為了防止突然增大的流量給個緩沖的余地
- 當然這個緩存增加的線程數量對設置超時時間是有參考意義的，比如上面我如果設置了10條線程，此時的超時時間該設置多少？並不是越多越好哦，應該是這么算：10/30=0.333，那么也就是在300ms左右，10是線程池數目，30是你預計的QPS。
- 想象下，如果超時時間設為500ms，當很多請求都變為500ms時，也就是10/0.5=20，你的QPS變成了20，那么多余的請求就不會不斷堆積，導致線程卡死，線程卡死后的恢復速度會是比較慢的，所以要合理設置線程池和超時時間
1.4. 降級操作
對於降級操作，可以舉些例子參考
- 比如redis掛了，對查詢可以查本地緩存，mysql等
- 對插入操作，數據庫掛了，可以嘗試寫入日志文件，或寫入MQ之后恢復