大家好，我是Tom哥。

作為后端研發(fā)同學(xué)為了幾兩碎銀，沒(méi)日沒(méi)夜周旋于各種人、各種事上。

如果你要想成長(zhǎng)的更快，就要學(xué)會(huì)歸納總結(jié)，找到規(guī)律，并且善用這些規(guī)律。

就比如工作，雖然事情很多、也很繁瑣，但如果按照性質(zhì)歸下類，我覺(jué)得可以分為兩大類：

1、業(yè)務(wù)類，如：產(chǎn)品要做一個(gè)紅包活動(dòng)，下周一就要上線，于是研發(fā)同學(xué)就吭哧吭哧，周末加班不睡覺(jué)也要趕出來(lái)。

2、技術(shù)類，如：架構(gòu)升級(jí)、系統(tǒng)優(yōu)化等，這類事情對(duì)技術(shù)能力有一定要求，通常要求有一定的項(xiàng)目經(jīng)驗(yàn)的同學(xué)來(lái) owner。

關(guān)于業(yè)務(wù)類的內(nèi)容很大程度依賴于產(chǎn)品同學(xué)的節(jié)奏，研發(fā)更多是被動(dòng)角色，我們能做的是就是多跟產(chǎn)品聊天，「實(shí)時(shí)」了解產(chǎn)品的最新動(dòng)向，培養(yǎng)自己的業(yè)務(wù) sense，給自己多預(yù)留一定的buffer時(shí)間可以去做技術(shù)調(diào)研、技術(shù)儲(chǔ)備。

工作過(guò)一段時(shí)間同學(xué)一般都經(jīng)歷過(guò)，產(chǎn)品變化節(jié)奏很快，經(jīng)常都是倒排時(shí)間，讓研發(fā)苦不堪言。

至于技術(shù)類，相對(duì)就比較溫和的多了，不過(guò)也非?？简?yàn)研發(fā)的技術(shù)實(shí)力。

今天，我們就來(lái)聊下關(guān)于接口性能優(yōu)化有哪些技巧？

1、本地緩存

本地緩存，最大的優(yōu)點(diǎn)是應(yīng)用和cache是在同一個(gè)進(jìn)程內(nèi)部，請(qǐng)求緩存非?？焖伲瑳](méi)有過(guò)多的網(wǎng)絡(luò)開(kāi)銷等，在單應(yīng)用不需要集群支持或者集群情況下各節(jié)點(diǎn)無(wú)需互相通知的場(chǎng)景下使用本地緩存較合適。缺點(diǎn)也是因?yàn)榫彺娓鷳?yīng)用程序耦合，多個(gè)應(yīng)用程序無(wú)法直接的共享緩存，各應(yīng)用或集群的各節(jié)點(diǎn)都需要維護(hù)自己的單獨(dú)緩存，對(duì)內(nèi)存是一種浪費(fèi)。

常用的本地緩存框架有 Guava、Caffeine 等，都是些單獨(dú)的jar包 ，直接導(dǎo)入到工程里即可使用。

我們可以根據(jù)自己的需要靈活選擇想要哪個(gè)框架。

使用門檻比較低， 大家可以自行網(wǎng)上搜索相應(yīng)的教程，這里就不展開(kāi)了。

 本地緩存適用兩種場(chǎng)景：

• 對(duì)緩存內(nèi)容時(shí)效性要求不高，能接受一定的延遲，可以設(shè)置較短過(guò)期時(shí)間，被動(dòng)失效更新保持?jǐn)?shù)據(jù)的新鮮度。
• 緩存的內(nèi)容不會(huì)改變。比如：訂單號(hào)與uid的映射關(guān)系，一旦創(chuàng)建就不會(huì)發(fā)生改變。

注意問(wèn)題：

• 內(nèi)存 Cache 數(shù)據(jù)條目上限控制，避免內(nèi)存占用過(guò)多導(dǎo)致應(yīng)用癱瘓。
• 內(nèi)存中的數(shù)據(jù)移出策略。
• 雖然實(shí)現(xiàn)簡(jiǎn)單，但潛在的坑比較多，最好選擇一些成熟的開(kāi)源框架。

2、分布式緩存

本地緩存的使用很容易讓你的應(yīng)用服務(wù)器帶上“狀態(tài)”，而且容易受內(nèi)存大小的限制。

分布式緩存借助分布式的概念，集群化部署，獨(dú)立運(yùn)維，容量無(wú)上限，雖然會(huì)有網(wǎng)絡(luò)傳輸?shù)膿p耗，但這1~2ms的延遲相比其更多優(yōu)勢(shì)完成可以忽略。

優(yōu)秀的分布式緩存系統(tǒng)有大家所熟知的 Memcached? 、Redis。對(duì)比關(guān)系型數(shù)據(jù)庫(kù)和緩存存儲(chǔ)，其在讀和寫(xiě)性能上的差距可謂天壤之別，redis單節(jié)點(diǎn)已經(jīng)可以做到 8W+ QPS。設(shè)計(jì)方案時(shí)盡量把讀寫(xiě)壓力從數(shù)據(jù)庫(kù)轉(zhuǎn)移到緩存上，有效保護(hù)脆弱的關(guān)系型數(shù)據(jù)庫(kù)。

注意問(wèn)題：

• 緩存的命中率，如果太低無(wú)法起到抗壓的作用，壓力還是壓到了下游的存儲(chǔ)層。
• 緩存的空間大小，這個(gè)要根據(jù)具體業(yè)務(wù)場(chǎng)景來(lái)評(píng)估，防止空間不足，導(dǎo)致一些熱點(diǎn)數(shù)據(jù)被置換出去。
• 緩存數(shù)據(jù)的一致性。
• 緩存的快速擴(kuò)容問(wèn)題。
• 緩存的接口平均RT，最大RT，最小RT。
• 緩存的QPS。
• 網(wǎng)絡(luò)出口流量。
• 客戶端連接數(shù)。

3、并行化

梳理業(yè)務(wù)流程，畫(huà)出時(shí)序圖，分清楚哪些是串行？哪些是并行？充分利用多核 CPU 的并行化處理能力。

如下圖所示，存在上下文依賴的采用串行處理，否則采用并行處理。

JDK 的 CompletableFuture?  提供了非常豐富的API，大約有50種 處理串行、并行、組合以及處理錯(cuò)誤的方法，可以滿足我們的場(chǎng)景需求。

之前寫(xiě)的文章：搞定 CompletableFuture，并發(fā)異步編程和編寫(xiě)串行程序還有什么區(qū)別？

4、異步化

一個(gè)接口的 RT 響應(yīng)時(shí)間是由內(nèi)部業(yè)務(wù)邏輯的復(fù)雜度決定的，執(zhí)行的流程約簡(jiǎn)單，那接口的耗費(fèi)時(shí)間就越少。

所以，普遍做法就是將接口內(nèi)部的非核心邏輯剝離出來(lái)，異步化來(lái)執(zhí)行。

下圖是一個(gè)電商的創(chuàng)建訂單接口，創(chuàng)建訂單記錄并插入數(shù)據(jù)庫(kù)是我們的核心訴求，至于后續(xù)的用戶通知，如：給用戶發(fā)個(gè)短信等，如果失敗，并不影響主流程的完成。

我們會(huì)將這些操作從主流程中剝離出來(lái)。

業(yè)務(wù)的普遍做法就是，下單成功后，發(fā)送一條異步消息到MQ 服務(wù)器，由消費(fèi)端監(jiān)聽(tīng) topic，異步消費(fèi)執(zhí)行，通過(guò)發(fā)布/訂閱 模式也能支持一些新的消費(fèi)任務(wù)的快速接入。

5、池化技術(shù)

TCP 三次握手非常耗費(fèi)性能，所以我們引入了 Keep-Alive 長(zhǎng)連接，避免頻繁的創(chuàng)建、銷毀連接。

池化技術(shù)也是類似道理，將很多能重復(fù)使用的對(duì)象緩存起來(lái)，放到一個(gè)池子里，用的時(shí)候去申請(qǐng)一個(gè)實(shí)例對(duì)象 ，用完后再放回池子里。

池化技術(shù)的核心是資源的“預(yù)分配”和“循環(huán)使用”，常見(jiàn)的池化技術(shù)的使用有：線程池、內(nèi)存池、數(shù)據(jù)庫(kù)連接池、HttpClient 連接池等。

連接池的幾個(gè)重要參數(shù)：最小連接數(shù)、空閑連接數(shù)、最大連接數(shù)。

比如創(chuàng)建一個(gè)線程池:

new ThreadPoolExecutor(3, 15, 5, TimeUnit.MINUTES,
    new ArrayBlockingQueue<>(10),
    new ThreadFactoryBuilder().setNameFormat("data-thread-%d").build(),
    (r, executor) -> {
         (r instanceof BaseRunnable) {
            ((BaseRunnable) r).rejectedExecute();
        }
    });

6、分庫(kù)分表

MySQL的底層 innodb 存儲(chǔ)引擎采用 B+ 樹(shù)結(jié)構(gòu)，三層結(jié)構(gòu)支持千萬(wàn)級(jí)的數(shù)據(jù)存儲(chǔ)。

當(dāng)然，現(xiàn)在互聯(lián)網(wǎng)的用戶基數(shù)非常大，這么大的用戶量，單表通常很難支撐業(yè)務(wù)需求，將一個(gè)大表水平拆分成多張結(jié)構(gòu)一樣的物理表，可以極大緩解存儲(chǔ)、訪問(wèn)壓力。

分庫(kù)分表也可能會(huì)帶入很多問(wèn)題：

• 分庫(kù)分表后，數(shù)據(jù)在分表內(nèi)產(chǎn)生數(shù)據(jù)傾斜。
• 如何創(chuàng)建全局性的唯一主鍵id。
• 數(shù)據(jù)如何路由到哪一個(gè)分片。

每一個(gè)問(wèn)題展開(kāi)都要花費(fèi)很長(zhǎng)篇幅來(lái)講解，這里主要講接口性能優(yōu)化的方案匯總，就不展開(kāi)細(xì)講了。

關(guān)于分庫(kù)分表，市場(chǎng)受歡迎的開(kāi)源框架是 sharding-jdbc，目前已經(jīng)捐贈(zèng)給Apache并啟動(dòng)孵化。

之前寫(xiě)的文章：為什么要分庫(kù)分表？

7、SQL 優(yōu)化

雖然有了分庫(kù)分表，從存儲(chǔ)維度可以減少很大壓力，但「富不過(guò)三代」，我們還是要學(xué)會(huì)精打細(xì)算，就比如所有的數(shù)據(jù)庫(kù)操作都是通過(guò) SQL 來(lái)執(zhí)行。

一個(gè)不好的SQL會(huì)對(duì)接口性能產(chǎn)生很大影響。

比如：

• 搞了個(gè)深度翻頁(yè)，每次數(shù)據(jù)庫(kù)引擎都要預(yù)查非常多的數(shù)據(jù)。
• 索引缺失，走了全表掃描。
• 一條 SQL 一次查詢 幾萬(wàn)條數(shù)據(jù)。

SQL 優(yōu)化的經(jīng)驗(yàn)非常多，比如：

• SQL 查詢時(shí)，盡量不要使用 select * ，而是 select 具體字段。
• 如果只有一條查詢結(jié)果（或者最大值、最小值），建議使用 limit 1。
• 索引不宜太多，一般控制在 5個(gè)以內(nèi)。
• where 語(yǔ)句中盡量避免使用 or來(lái)連接條件。or 可能會(huì)導(dǎo)致索引失效，從而全表掃描。
• 索引盡量避免建在有大量重復(fù)數(shù)據(jù)的字段上，如：性別。
• where 、 order by 涉及的列上建索引，避免全表掃描。
• 更多.....

SQL 優(yōu)化的內(nèi)容非常多，這里就不展開(kāi)了。

8、預(yù)先計(jì)算

有很多業(yè)務(wù)的計(jì)算邏輯比較復(fù)雜，比如頁(yè)面要展示一個(gè)網(wǎng)站的 PV、微信的拼手氣紅包等。

如果在用戶訪問(wèn)接口的瞬間觸發(fā)計(jì)算邏輯，而這些邏輯計(jì)算的耗時(shí)通常比較長(zhǎng)，很難滿足用戶的實(shí)時(shí)性要求。

一般我們都是提前計(jì)算，然后將算好的數(shù)據(jù)預(yù)熱到緩存中，接口訪問(wèn)時(shí)，只需要讀緩存即可。

是不是一下子就快了很多。

9、事務(wù)相關(guān)

很多業(yè)務(wù)邏輯有事務(wù)要求，針對(duì)多個(gè)表的寫(xiě)操作要保證事務(wù)特性。

但事務(wù)本身又特別耗費(fèi)性能，為了能盡快結(jié)束，不長(zhǎng)時(shí)間占用數(shù)據(jù)庫(kù)連接資源，我們一般要減少事務(wù)的范圍。

將很多查詢邏輯放到事務(wù)外部處理。

另外在事務(wù)內(nèi)部，一般不要進(jìn)行遠(yuǎn)程的 RPC 接口訪問(wèn)，一般占用的時(shí)間比較長(zhǎng)。

10、海量數(shù)據(jù)處理

如果數(shù)據(jù)量過(guò)大，除了采用關(guān)系型數(shù)據(jù)庫(kù)的分庫(kù)分表外，我們還可以采用 NoSQL。

如：MongoDB、Hbase、Elasticsearch、TiDB。

NoSQL 采用分區(qū)架構(gòu)，對(duì)數(shù)據(jù)海量存儲(chǔ)能較好的支持，但是事務(wù)方面可能沒(méi)那么友好。

每一個(gè) NoSQL 框架都有自己的特色，有支持 搜索的、有列式存儲(chǔ)、有文檔存儲(chǔ)，大家可以根據(jù)自己的業(yè)務(wù)場(chǎng)景選擇合適的框架。

11、批量讀寫(xiě)

當(dāng)下的計(jì)算機(jī)CPU處理速度還是很多的，而 IO 一般是個(gè)瓶頸，如：磁盤IO、網(wǎng)絡(luò)IO。

有這么一個(gè)場(chǎng)景，查詢 100 個(gè)人的賬戶余額？

有兩個(gè)設(shè)計(jì)方案：

方案一：開(kāi)單次查詢接口，調(diào)用方內(nèi)部循環(huán)調(diào)用 100 次。

方案二：服務(wù)提供方開(kāi)一個(gè)批量查詢接口，調(diào)用方只需查詢 1 次。

你覺(jué)得那種方案更好？

答案不言而喻，肯定是方案二。

數(shù)據(jù)庫(kù)的寫(xiě)操作也是一樣道理，為了提高性能，我們一般都是采用批量更新。

12、鎖的粒度。

并發(fā)業(yè)務(wù)，為了防止數(shù)據(jù)的并發(fā)更新對(duì)數(shù)據(jù)的正確性產(chǎn)生干擾，我們通常是采用 加鎖 ，涉及獨(dú)享資源每次只能是一個(gè)線程來(lái)處理。

問(wèn)題點(diǎn)在于，鎖是成對(duì)出現(xiàn)的，有加鎖就是釋放鎖。

對(duì)于非競(jìng)爭(zhēng)資源，我們沒(méi)有必要圈在鎖內(nèi)部，會(huì)嚴(yán)重影響系統(tǒng)的并發(fā)能力。

控制鎖的范圍是我們要考慮的重點(diǎn)。

之前寫(xiě)過(guò)一篇常用的鎖有哪些，聊聊 13 種鎖的實(shí)現(xiàn)方式。

13、上下文傳遞

Tom哥帶團(tuán)隊(duì)對(duì)小伙伴有要求，代碼必須要有 code review 環(huán)節(jié)，review 同學(xué)代碼經(jīng)常發(fā)現(xiàn)一個(gè)問(wèn)題。

當(dāng)需要一個(gè)數(shù)據(jù)時(shí)，如果沒(méi)有調(diào) RPC 接口去查，比如想用戶信息這種通用型接口。

因?yàn)榍懊嬉茫隙ㄒ呀?jīng)查過(guò)。但是我們知道方法的調(diào)用都是以棧幀的形式來(lái)傳遞，隨著一個(gè)方法執(zhí)行完畢而出棧，方法內(nèi)部的局部變量也就被回收了。

后面如果又要用到這個(gè)信息，只能重新去查。

如果能定義一個(gè)Context 上下文對(duì)象，將一些中間信息存儲(chǔ)并傳遞下來(lái)，會(huì)大大減輕后面流程的再次查詢壓力。

14、空間大小

如何創(chuàng)建一個(gè)集合，這還不簡(jiǎn)單，很快我們就寫(xiě)出下面代碼。

List<String> lists = Lists.newArrayList();

如果說(shuō)，要往里面插入 1000000  個(gè)元素，有沒(méi)有更好的方式？

我們做個(gè)試驗(yàn)：

場(chǎng)景一：

結(jié)果：1000000 次插入 List，花費(fèi)時(shí)間：154。

場(chǎng)景二：

結(jié)果：1000000 次插入 List，花費(fèi)時(shí)間：134。

如果我們預(yù)先知道集合要存儲(chǔ)多少元素，初始化集合時(shí)盡量指定大小，尤其是容量較大的集合。

ArrayList 初始大小是 10，超過(guò)閾值會(huì)按 1.5 倍大小擴(kuò)容，涉及老集合到新集合的數(shù)據(jù)拷貝，浪費(fèi)性能。

15、查詢優(yōu)化

避免一次從 DB 中查詢大量的數(shù)據(jù)到內(nèi)存中，可能會(huì)導(dǎo)致內(nèi)存不足，建議采用分批、分頁(yè)查詢。