天天說要做性能優化，到底在優化什么？
本文轉載自微信公眾號「猿天地」，作者尹吉歡 。轉載本文請聯系猿天地公眾號。
面試過程中經常被問到：
- 你做過性能優化嗎?
- 優化了哪些方面?
- 怎么做優化的?
- 優化的效果如何?
連環炮問下來，對于有做過優化的老司機來說，肯定能抗住。對于沒有真正做過優化的小白來說，肯定扛不住這一系列的追問，最后只能以面試失敗而告終。
那么性能優化到底在優化什么呢?我們來盤點下一些常用的優化手段。
SQL 優化
當你開發的接口響應時間超過了 200ms 的時候就得優化了，當然 200ms 不是絕對值，具體還是看應用場景。以 App 舉例，進一個頁面調用 5 個接口(題外話：也可以做聚合)，那么總共就是 1s 的時間，對用戶來說體驗還算可以，當然是越快響應越好。
接口耗時 200ms，其中占大頭的還是對數據庫的操作，一個接口中會有 N 次數據庫操作。所以優化 SQL 的速度優先級是最高的，大量的慢 SQL 會拖垮整個系統。
關于 SQL 的優化不是本文的重點，大部分慢 SQL 還是跟各位平時開發時的習慣有關系。大部分在寫 SQL 的時候不太會去考慮性能，只要寫出來就可以了，join 隨手就來，也不梳理查詢字段，不加索引，剛開始上線沒問題，等到并發量，數據量起來的時候就涼涼了。
關于數據庫的使用規范大家可以參考下這篇文章：老大讓我整理下公司內部mysql使用規范，分享給大家
當數據量大了后肯定要做讀寫分離和分庫分表的，這也是優化的必經之路。
- 讀寫分離
- 分庫分表
減少重復調用
性能不好的另一個致命問題就是重復調用，相同的邏輯在不同的方法中重復對數據庫查詢，重復調用 RPC 服務等。
比如下面的代碼：
- skuDao.querySkus(productId).stream().map(sku -> {
- skuDao.getById(sku.getId());
- })
明明數據已經查詢出來了，又根據 ID 重新去查詢了一次，數量越多，浪費的時間越多。這里只是舉例，我相信在真實的項目中大量存在重復查詢的情況，之前我還寫過一篇文章，講解如何解決這種重復查詢問題，感興趣的可以查看這篇文章：簡直騷操作，ThreadLocal還能當緩存用
按需查詢
很多業務邏輯不復雜的功能，卻響應很慢。往往都是寫代碼的時候沒有思考，隨便就調用一些已經存在的方法，導致整體響應變慢，總結起來就是：性能問題大部分都是代碼寫出來的。
說個場景，大家肯定都見到過。參數是一個商品 ID, 功能是上架商品，需要進行狀態的判斷，符合條件才能上架。這個場景下只需要獲取商品的狀態進行判斷即可，有的時候你看到的代碼往往都是下面的方式：
- GoodsDetail goods = goodsService.detail(id);
- if (goods.getStatus() == GoodsStatusEnum.XXXX) {
- }
detail 中有大量的邏輯，除了基本的商品信息，還有很多其他的內容，這就是慢的原因。
并行調用
針對一個接口，如果設計到多個內部 RPC 服務或者多個外部接口，在接口之間沒有關聯關系的情況下，我們可以采用并行調用的方式來提高性能。
CompletableFuture 就非常適合并行調用的場景，關于 CompletableFuture 的使用本文不做詳細說明，做 Java 的都要會用。
除了 CompletableFuture 之外，對于集合類的處理，可以用 parallelStream 來實現并行調用。
在微服務中有一層專門用于聚合 API, 聚合層就非常適合并行調用，一個功能或者一個頁面展示會涉及到多個接口，通過聚合層在后端進行接口的聚合和數據的裁剪，一起響應給前端。
上緩存
緩存也是優化中最常用的，效果提升最明顯的，成本也不大。對于緩存，也不要濫用，不是所有場景都可以靠堆緩存來提高性能的。
首先對于實時性要求不高的業務場景可以優先使用緩存，也不用太考慮更新的問題，自然過期就行。
實時性要求高的業務場景，用緩存一定要有完整的緩存更新機制，否則很容易造成業務數據和緩存數據不一致的情況。
建議的做法是訂閱 binlog 來統一更新緩存，不要在代碼中去更新或者失效緩存，簡單的場景還好，入口就那幾個，問題不大。有些數據在多個場景下使用，需要更新的入口太多了，
異步處理
有些邏輯，不需要實時反饋給用戶那就可以采用異步的方式在后臺進行處理。
異步處理的方式最常見的就是將任務加到線程池中進行處理，線程池需要考慮容量以及對一些指標的監控，相關的文章可以查看我的這篇：一時技癢，擼了個動態線程池，源碼放Github了
除了一些指標的監控，線程池的使用另一個需要關注的問題就是任務的持久化。如果你的數據本來就是存儲好了的，然后讀取出來通過線程池去執行是沒問題的。如果是沒有持久化直接丟入線程池中進行執行，就有可能出現丟失的情況，比如服務重啟之類的場景。
關于持久化，無論是線程池還是 EventBus 這種，都會遇到，所以針對異步的場景我建議大家使用消息隊列比較好。
消息隊列可以存儲任務信息，保證不會丟失。單獨消費隊列的消息進行邏輯處理，如果想提高消費速度，也可以在隊列的消費方使用線程池進行多線程消費，多線程消費也要避免消息丟失的情況，可以查看我的這篇文章：噓!異步事件這樣用真的好么?
JVM 參數調整
JVM 參數的調整，一般情況下我們都不用怎么去調整。偶爾有些代碼寫的不好，導致內存溢出了，這個時候會去做一些調整和優化代碼。
參數調整主要是去降低 GC 的導致的停頓問題，如果你的程序一直在 GC, 一直在停頓，你的接口自然就慢了。
只要沒有頻繁的 Full GC，在優化這塊 JVM 的參數調整可以最后再做，優先以 SQL 優化這些為主。
加機器
加機器是最后的終極大招了，并發量上去的時候，你在怎么優化單機器和單數據庫抗并發能力也是有限的，這個時候只能水平擴展了。
如果是創業初期，并且在快速發展，加機器是最直接的優化方式了，雖然說成本上去了，但是開發資源也是成本，節約下來可以實現更多的業務需求。等到中期穩定了再考慮架構，性能方面整體的優化和重構。
就像玩游戲一樣，有裝備的玩家才能所向睥睨啊，對于后端應用來說也是一樣，高配的機器，高配的數據庫配置，高配的緩存等。
關于作者：尹吉歡，簡單的技術愛好者，《Spring Cloud 微服務-全棧技術與案例解析》, 《Spring Cloud 微服務 入門 實戰與進階》作者, 公眾號猿天地發起人。
原文鏈接：http://cxytiandi.com/blog/user/1
