當系統的使用者量上來，每秒qps上千後，可能就會導致系統的各種卡頓，超時等情況，這時優化操作不可避免
第一步：優化大sql，對於多表關聯的sql，當單錶資料幾百上千萬行時，執行可能會達到好幾秒，對微服務系統來說，我是不建議join多表操作，除非是資料量少的維表，我們可以將一句大sql拆分成多個過程，邏輯在jvm中完成
第二步：超時時間不要設的過長，一般乙個介面的響應時間要控制在200ms以內，超時時間1s就夠了，一旦接近或超過1s，就要考慮是否要用，快取，索引，nosql等手段優化下了
第三步：如果設定了1s超時，可能因為網路的抖動，某次請求超過1s，這個時候需要設定合理的超時重試
第四步：設定重試，那就要考慮介面冪等性的問題，常見解決方案是建唯一索引，或者通過redis判斷下唯一id，保證介面被多次呼叫時不重複插入資料
對於降級操作，可以舉些例子參考
參考：每秒上萬併發下的spring cloud引數優化實戰
微服務架構如何保障雙11狂歡下的99.99%高可用
三千高併發效能優化
3臺64核的應用伺服器，每個應用伺服器部署4個節點 一台資料庫伺服器 3個負載均衡nginx，每個nginx導向4個節點。高併發大量的系統日誌將導致系統堵塞，日誌只開啟error級別，或者日誌在另一線程批量處理。為了保持乙個編號不重複，每次獲取都到資料庫中加1，這樣將導致資源競爭鎖住，調整為每次取一...
為什麼高併發性很重要？
因此，現在比以前複雜得多，架構師面臨的最大挑戰之一就是併發。自web服務開始以來，併發水平一直在不斷增長。乙個流行的 服務數十萬甚至數百萬同時使用者並不罕見。十年前，併發的主要原因是緩慢的客戶端 具有adsl或撥號連線的使用者。如今，併發性是由移動客戶端和較新的應用程式體系結構的組合引起的，這些體系...
高併發 效能調優 架構
關於效能需要熟悉三個指標 併發使用者,響應時間,tps 每秒事務處理個數 比如 單個伺服器配置為32核,64g記憶體,jvm記憶體為6g,效能測試結果 平均響應時間為200ms,併發使用者為300個,tps為1500為了滿足未來發展需要,系統需配備多台伺服器,如 4臺.1.通訊 2.應用集群部署 3...