大家好，我是Tom哥。

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

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

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

• 業(yè)務(wù)類，如：產(chǎn)品要做一個(gè)紅包活動(dòng)，下周一就要上線，于是研發(fā)同學(xué)就吭哧吭哧，周末加班不睡覺也要趕出來
• 技術(shù)類，如：架構(gòu)升級、系統(tǒng)優(yōu)化等，這類事情對技術(shù)能力有一定要求，通常要求有一定的項(xiàng)目經(jīng)驗(yàn)的同學(xué)來 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ǔ)備。

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

至于技術(shù)類，相對就比較溫和的多了，不過也非常考驗(yàn)研發(fā)的技術(shù)實(shí)力。

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

1、本地緩存

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

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

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

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

本地緩存適用兩種場景：

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

注意問題：

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

2、分布式緩存

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

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

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

注意問題：

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

3、并行化

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

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

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

4、異步化

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

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

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

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

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

5、池化技術(shù)

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

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

池化技術(shù)的核心是資源的“預(yù)分配”和“循環(huán)使用”，常見的池化技術(shù)的使用有：線程池、內(nèi)存池、數(shù)據(jù)庫連接池、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) -> {
        if (r instanceof BaseRunnable) {
            ((BaseRunnable) r).rejectedExecute();
        }
    });

6、分庫分表

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

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

分庫分表也可能會(huì)帶入很多問題：

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

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

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

7、SQL 優(yōu)化

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

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

比如：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

如：MongoDB、Hbase、Elasticsearch、TiDB

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

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

11、批量讀寫

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

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

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

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

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

你覺得那種方案更好?

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

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

12、鎖的粒度

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

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

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

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

13、上下文傳遞

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

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

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

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

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

14、空間大小

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

List lists = Lists.newArrayList();

如果說，要往里面插入 1000000 個(gè)元素，有沒有更好的方式?

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

場景一：

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

場景二：

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

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

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

15、查詢優(yōu)化

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