第一次壓測

慘不忍睹，平均響應時間150ms，而且在這次壓測過程中還發現其它的問題，后臺報錯，經查是OpenSearch每秒查詢次數限制

優化代碼與配置

1、修改OpenSearch配置，并且將壓測環境中的OpenSearch連接地址改為內網地址。2、將代碼中循環查詢緩存的地方改為一次性批量查詢返回。3、和相關同學確認后去掉項目中無用的代碼。

第二次壓測

雖然優化了代碼，修改了配置，但是情況更糟糕了，而且還改出了新的問題。當時，反復檢查了代碼，確定查詢緩存的次數已經是最少了，而且連接線程池相關參數也調到一個相對較大且合理的值了。如果，再壓測還是無法達到要求的話，只有出最后一招了：緩存結果集。即，以用戶ID和用戶搜索的關鍵詞為key，查詢的結果為value，緩存5分鐘。

第三次壓測

總算符合要求了，并發60的時候響應時間達到32ms，而我又發現了新的優化點。

接口中居然還有查數據庫的操作，這可不能忍，排查之后去掉了一些不必要的依賴。

成長

學會了使用RedisTemplate的executePipelined進行redis批量查詢

針對本次優化的總結

1、一定要絕對避免循環查數據庫和緩存（PS：循環里面就不能有查詢緩存，更不能有查詢數據庫的操作，因為循環的次數沒法控制）；

2、對于API接口的話，一般都是直接查緩存的，沒有查數據庫的；

3、多用批量查詢，少用單條查詢，盡量一次查出來；

4、對于使用阿里云，要留意一下相應產品的配置，該花的錢還是得花，同時，千萬要記得正式環境中使用相應產品的內網地址；

5、注意連接池大小（包括數據庫連接池、Redis緩存連接池、線程池）；

6、壓測的機器上不要部署其它的服務，只跑待壓測的服務，避免受其它項目影響；對于線上環境，最好一臺機器上只部署一個重要的服務；

7、沒有用的以及被注釋掉的代碼，沒有用的依賴最好及時清理掉；

8、集群自不用說；

9、一些監控類的工具工具可以幫助我們更好的定位問題，比如鏈路跟蹤，這次項目中使用了PinPoint；

10、如果技術上優化的空間已經非常小了，可以試著從業務上著手，用實際的數據說話，可以從日常的訪問量，歷史訪問量數據來說服測試；

11、每一次代碼改動都有可能引入新的問題，因此，每次修改代碼后都要回歸測試一下（PS：每次修改完以后，我都會用幾組不同的關鍵詞搜索，然后比對修改前和修改后返回的數據是否一致，這個時候postman，以及Beyond compare就派上用場了）；

12、關鍵的地方一定要多加點兒日志，方便以后排除問題，因為排查線上問題最主要還是靠日志；

結語

小編也是很有感觸，如果一直都是在中小公司，沒有接觸過大型的互聯網架構設計的話，只靠自己看書去提升可能一輩子都很難達到高級架構師的技術和認知高度。向厲害的人去學習是最有效減少時間摸索、精力浪費的方式。

我們選擇的這個行業就一直要持續的學習，又很吃青春飯。

雖然大家可能經常見到說程序員年薪幾十萬，但這樣的人畢竟不是大部份，要么是有名校光環，要么是在阿里華為這樣的大企業。年齡一大，更有可能被裁。

小編整理的學習資料分享一波！

送給每一位想學習Java小伙伴，用來提升自己。想要資料的可以點擊這里免費獲取

gitee.com/vip204888/java-p7)**
[外鏈圖片轉存中…(img-jV4BPjQP-1626939283302)]

本文到這里就結束了，喜歡的朋友可以幫忙點贊和評論一下，感謝支持！

總結

以上是生活随笔為你收集整理的学海无涯！java连接mysql的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。