做了這麼久開發，終於涉及到性能優化了
原因是打開一個頁面花了2-6秒，被提了bug
不得不說自己有點小白，嘗試了異步線程和把單次的dubbo查詢優化成批量的查詢。
但是這兩種嘗試都沒有宣告成功
出了問題首先要找到問題在哪裏
既然是耗時，那就要看看到底哪裏耗時最多（這裏要說一下，因爲我是改別人的代碼，所以對業務邏輯不是很清楚，完全靠debug去改。如果有精力，最好能掌握業務邏輯，這樣改起來更得心應手）
我太忙於優化dubbo查詢了，把單次改爲批量查詢後，我發現並沒有減少時間。與沒改前基本持平。
不過dubbo優化也是必須做的，爲後續做準備。
正題開始了：我開始找哪個dubbo耗時最多。
整個方法用了5個dubbo吧。在我將單次改爲批量後。我又發現了有個dubbo的查詢結果可以複用，就又省去了一個dubbo。現在只剩下4個dubbo了。問了大數據的大神，hbase的性能很好，肯定不會很耗時。事實卻是如此，所以排除了這個dubbo
然後在剩下的dubbo前後都加上了耗時計算
結果發現。返回map<Integer, List<對象>>這個dubbo耗時太嚴重。600ms上下。所以就鎖定了這個dubbo
解決辦法就是加緩存。不過這裏有兩個地方，一個是我本地查詢結果家緩存，還有一點是數據大神提醒我的。dubbo實現類裏面實際查詢了90多次的mysql，不如直接把查詢結果加緩存。但是就算把查詢結果加了緩存，也沒有很減少時間，因爲畢竟要查詢90多次redis。最後還是要在使用方的查詢結果里加緩存。果然加了緩存以後就好了。耗時幾十ms。目前符合需求了
不過有個問題就是緩存的時效性。由於我目前在dubbo的實現類和dubbo服務的使用方都加了緩存，這個時效性的問題還需要考慮一下。不過在更新數據的時候更新redis緩存是很有必要的。
好了，先寫這麼多吧，下班回家。