日韩国产精品99成人不卡在线无毒|狠狠躁夜夜爽一级二级精品|亚洲日日噜噜孕妇中文字幕|日韩久草中文三级片

SQL 優(yōu)化

當(dāng)你開發(fā)的接口響應(yīng)時間超過了 200ms 的時候就得優(yōu)化了，當(dāng)然 200ms 不是絕對值，具體還是看應(yīng)用場景。以 App 舉例，進一個頁面調(diào)用 5 個接口（題外話：也可以做聚合），那么總共就是 1s 的時間，對用戶來說體驗還算可以，當(dāng)然是越快響應(yīng)越好。

接口耗時 200ms，其中占大頭的還是對數(shù)據(jù)庫的操作，一個接口中會有 N 次數(shù)據(jù)庫操作。所以優(yōu)化 SQL 的速度優(yōu)先級是最高的，大量的慢 SQL 會拖垮整個系統(tǒng)。

關(guān)于 SQL 的優(yōu)化不是本文的重點，大部分慢 SQL 還是跟各位平時開發(fā)時的習(xí)慣有關(guān)系。大部分在寫 SQL 的時候不太會去考慮性能，只要寫出來就可以了，join 隨手就來，也不梳理查詢字段，不加索引，剛開始上線沒問題，等到并發(fā)量，數(shù)據(jù)量起來的時候就涼涼了。

關(guān)于數(shù)據(jù)庫的使用規(guī)范大家可以參考下這篇文章：老大讓我整理下公司內(nèi)部mysql使用規(guī)范，分享給大家

當(dāng)數(shù)據(jù)量大了后肯定要做讀寫分離和分庫分表的，這也是優(yōu)化的必經(jīng)之路。

• 讀寫分離

• 分庫分表

減少重復(fù)調(diào)用

性能不好的另一個致命問題就是重復(fù)調(diào)用，相同的邏輯在不同的方法中重復(fù)對數(shù)據(jù)庫查詢，重復(fù)調(diào)用 RPC 服務(wù)等。

比如下面的代碼：

skuDao.querySkus(productId).stream().map(sku -> {
   skuDao.getById(sku.getId());
})

明明數(shù)據(jù)已經(jīng)查詢出來了，又根據(jù) ID 重新去查詢了一次，數(shù)量越多，浪費的時間越多。這里只是舉例，我相信在真實的項目中大量存在重復(fù)查詢的情況，之前我還寫過一篇文章，講解如何解決這種重復(fù)查詢問題，感興趣的可以查看這篇文章：簡直騷操作，ThreadLocal還能當(dāng)緩存用

按需查詢

很多業(yè)務(wù)邏輯不復(fù)雜的功能，卻響應(yīng)很慢。往往都是寫代碼的時候沒有思考，隨便就調(diào)用一些已經(jīng)存在的方法，導(dǎo)致整體響應(yīng)變慢，總結(jié)起來就是：性能問題大部分都是代碼寫出來的。

說個場景，大家肯定都見到過。參數(shù)是一個商品 ID, 功能是上架商品，需要進行狀態(tài)的判斷，符合條件才能上架。這個場景下只需要獲取商品的狀態(tài)進行判斷即可，有的時候你看到的代碼往往都是下面的方式：

GoodsDetail goods = goodsService.detail(id);
if (goods.getStatus() == GoodsStatusEnum.XXXX) {

}

detail 中有大量的邏輯，除了基本的商品信息，還有很多其他的內(nèi)容，這就是慢的原因。

并行調(diào)用

針對一個接口，如果設(shè)計到多個內(nèi)部 RPC 服務(wù)或者多個外部接口，在接口之間沒有關(guān)聯(lián)關(guān)系的情況下，我們可以采用并行調(diào)用的方式來提高性能。

CompletableFuture 就非常適合并行調(diào)用的場景，關(guān)于 CompletableFuture 的使用本文不做詳細說明，做 Java 的都要會用。

除了 CompletableFuture 之外，對于集合類的處理，可以用 parallelStream 來實現(xiàn)并行調(diào)用。

在微服務(wù)中有一層專門用于聚合 API, 聚合層就非常適合并行調(diào)用，一個功能或者一個頁面展示會涉及到多個接口，通過聚合層在后端進行接口的聚合和數(shù)據(jù)的裁剪，一起響應(yīng)給前端。

上緩存

緩存也是優(yōu)化中最常用的，效果提升最明顯的，成本也不大。對于緩存，也不要濫用，不是所有場景都可以靠堆緩存來提高性能的。

首先對于實時性要求不高的業(yè)務(wù)場景可以優(yōu)先使用緩存，也不用太考慮更新的問題，自然過期就行。

實時性要求高的業(yè)務(wù)場景，用緩存一定要有完整的緩存更新機制，否則很容易造成業(yè)務(wù)數(shù)據(jù)和緩存數(shù)據(jù)不一致的情況。

建議的做法是訂閱 binlog 來統(tǒng)一更新緩存，不要在代碼中去更新或者失效緩存，簡單的場景還好，入口就那幾個，問題不大。有些數(shù)據(jù)在多個場景下使用，需要更新的入口太多了，

異步處理

有些邏輯，不需要實時反饋給用戶那就可以采用異步的方式在后臺進行處理。

異步處理的方式最常見的就是將任務(wù)加到線程池中進行處理，線程池需要考慮容量以及對一些指標(biāo)的監(jiān)控，相關(guān)的文章可以查看我的這篇：一時技癢，擼了個動態(tài)線程池，源碼放Github了

除了一些指標(biāo)的監(jiān)控，線程池的使用另一個需要關(guān)注的問題就是任務(wù)的持久化。如果你的數(shù)據(jù)本來就是存儲好了的，然后讀取出來通過線程池去執(zhí)行是沒問題的。如果是沒有持久化直接丟入線程池中進行執(zhí)行，就有可能出現(xiàn)丟失的情況，比如服務(wù)重啟之類的場景。

關(guān)于持久化，無論是線程池還是 EventBus 這種，都會遇到，所以針對異步的場景我建議大家使用消息隊列比較好。

消息隊列可以存儲任務(wù)信息，保證不會丟失。單獨消費隊列的消息進行邏輯處理，如果想提高消費速度，也可以在隊列的消費方使用線程池進行多線程消費，多線程消費也要避免消息丟失的情況，可以查看我的這篇文章：噓！異步事件這樣用真的好么？

JVM 參數(shù)調(diào)整

JVM 參數(shù)的調(diào)整，一般情況下我們都不用怎么去調(diào)整。偶爾有些代碼寫的不好，導(dǎo)致內(nèi)存溢出了，這個時候會去做一些調(diào)整和優(yōu)化代碼。

參數(shù)調(diào)整主要是去降低 GC 的導(dǎo)致的停頓問題，如果你的程序一直在 GC, 一直在停頓，你的接口自然就慢了。

只要沒有頻繁的 Full GC，在優(yōu)化這塊 JVM 的參數(shù)調(diào)整可以最后再做，優(yōu)先以 SQL 優(yōu)化這些為主。

加機器

加機器是最后的終極大招了，并發(fā)量上去的時候，你在怎么優(yōu)化單機器和單數(shù)據(jù)庫抗并發(fā)能力也是有限的，這個時候只能水平擴展了。

如果是創(chuàng)業(yè)初期，并且在快速發(fā)展，加機器是最直接的優(yōu)化方式了，雖然說成本上去了，但是開發(fā)資源也是成本，節(jié)約下來可以實現(xiàn)更多的業(yè)務(wù)需求。等到中期穩(wěn)定了再考慮架構(gòu)，性能方面整體的優(yōu)化和重構(gòu)。

就像玩游戲一樣，有裝備的玩家才能所向睥睨啊，對于后端應(yīng)用來說也是一樣，高配的機器，高配的數(shù)據(jù)庫配置，高配的緩存等。

關(guān)于作者：尹吉歡，簡單的技術(shù)愛好者，《Spring Cloud 微服務(wù)-全棧技術(shù)與案例解析》, 《Spring Cloud 微服務(wù) 入門 實戰(zhàn)與進階》作者, 公眾號猿天地發(fā)起人。

我整理了一份很全的學(xué)習(xí)資料，感興趣的可以微信搜索「猿天地」，回復(fù)關(guān)鍵字 「學(xué)習(xí)資料」獲取我整理好了的 Spring Cloud，Spring Cloud Alibaba，Sharding-JDBC 分庫分表，任務(wù)調(diào)度框架 XXL-JOB，MongoDB，爬蟲等相關(guān)資料。