記一次接口性能優化實踐總結：優化接口性能的八個建議

前言

最近對外接口偶現504超時問題，緣由是代碼執行時間過長，超過nginx配置的15秒，而後真槍實彈搞了一次接口性能優化。在這裏結合優化過程，總結了接口優化的八個要點，但願對你們有幫助呀~

• 數據量比較大，批量操做數據入庫

• 耗時操做考慮異步處理

• 恰當使用緩存

• 優化程序邏輯、代碼

• SQL優化

• 壓縮傳輸內容

• 考慮使用文件/MQ等其餘方式暫存，異步再落地DB

• 跟產品討論需求最恰當，最舒服的實現方式

嘻嘻，先看一下咱們對外轉帳接口的大概流程吧

1.數據量比較大，批量操做數據入庫

優化前：

優化後：

性能對比：

• 批量插入性能更好，更加省時間，爲何呢？

打個比喻:假如你須要搬一萬塊磚到樓頂,你有一個電梯,電梯一次能夠放適量的磚（最多放500）,你能夠選擇一次運送一塊磚,也能夠一次運送500,你以爲哪一種方式更方便，時間消耗更少?

2.耗時操做考慮異步處理

耗時操做，考慮用異步處理，這樣能夠下降接口耗時。本次轉帳接口優化，匹配聯行號的操做耗時有點長，因此優化過程把它移到異步處理了，以下：

優化前：

優化後

匹配聯行號的操做異步處理

性能對比：

假設一個聯行號匹配6ms

解析：

• 由於聯行號匹配比較耗時，放在異步處理的話，同步聯機返回能夠省掉這部分時間，大大提高接口性能，而且不會影響到轉帳主流程功能。

• 除了這個例子，平時咱們相似功能，如用戶註冊成功後，短信郵件通知，也是能夠異步處理的，這個優化建議香餑餑的~

• 因此，太耗時的操做，在不影響主流程功能的狀況下，能夠考慮開子線程異步處理的啦。

3.恰當使用緩存

在適當的業務場景，恰當地使用緩存，是能夠大大提升接口性能的。這裏的緩存包括：Redis，JVM本地緩存，memcached，或者Map等。

此次轉帳接口，使用到緩存啦，舉個簡單例子吧~

優化前

如下是輸入用戶帳號，匹配聯行號的流程圖

優化後：

恰當使用緩存，代替查詢DB表，流程圖以下：

解析：

• 把熱點數據放到緩存，不用每次查詢都去DB拉取，節省了這部分查SQL的耗時，美滋滋呀~

• 固然，不是什麼數據都適合放到緩存的哦，訪問比較頻繁的熱點數據才考慮緩存起來呢~

4. 優化程序邏輯、代碼

優化程序邏輯、程序代碼，是能夠節省耗時的。

我這裏就本次的轉帳接口優化，舉個例子吧~

優化前：

優化前，聯行號查詢了兩次（檢驗參數一次，插入DB前查詢一次），以下僞代碼：

優化後：

優化後，只在校驗參數的時候插敘一次，而後設置到對象裏面~ 入庫前就不用再查啦，僞代碼以下：

解析：

• 對於優化程序邏輯、代碼，是能夠下降接口耗時的。以上demo只是一個很簡單的例子，就是優化前payeeBankNo查詢了兩次，可是其實只查一次就能夠了。不少時候，咱們都知道這個點，但就是到寫代碼的時候，又忘記了呀~因此，寫代碼的時候，留點心吧，優化你的程序邏輯、代碼哦。

• 除了以上demo這點，還有其它特色，如優化if複雜的邏輯條件，考慮是否能夠調整順序，或者for循環，是否重複實例化對象等等，這些適當優化，都是可讓你的代碼跑得更快的。

以前我這篇文章，也提了幾個優化點噢，有興趣的朋友能夠看一下哈~

寫代碼有這些想法，同事纔不會認爲你是複製粘貼程序員

5. 優化你的SQL

不少時候，你的接口性能瓶頸就在SQL這裏，慢查詢須要咱們重點關注的點呢。

咱們能夠經過這些方式優化咱們的SQL：

• 加索引

• 避免返回沒必要要的數據

• 優化sql結構

• 分庫分表

• 讀寫分離

有興趣的朋友能夠看一下我這篇文章呢，很詳細的SQL優化點：

後端程序員必備：書寫高質量SQL的30條建議

6.壓縮傳輸內容

壓縮傳輸內容，文件變得更小，所以傳輸會更快啦。10M帶寬，傳輸10k的報文，通常比傳輸1M的會快呀；打個比喻，一匹千里馬，它馱着一百斤的貨跑得快，仍是馱着10斤的貨物跑得快呢？

解析：

• 若是你的接口性能很差，而後傳輸報文比較大的話，這時候是能夠考慮壓縮文件內容傳輸的，最後優化效果可能很不錯哦~

7. 考慮使用文件/MQ等其餘方式暫存數據，異步再落地DB

若是數據太大，落地數據庫實在是慢的話，能夠考慮先用文件的方式保存，或者考慮MQ，先落地，再異步保存到數據庫~

本次轉帳接口，若是是併發開啓，10個併發度，每一個批次1000筆數據，數據庫插入會特別耗時，大概10秒左右，這個跟咱們公司的數據庫同步機制有關，併發狀況下，由於優先保證同步，因此並行的插入變成串行啦，就很耗時。

優化前：

優化前，1000筆先落地DB數據庫，再異步轉帳，以下：

優化後：

先保存數據到文件，再異步下載下來，插入數據庫，以下：

解析：

• 若是你的耗時瓶頸就在數據庫插入操做這裏了，那就考慮文件保存或者MQ或者其餘方式暫存吧，文件保存數據，對比一下耗時，有時候會有意想不到的效果哦。

8.跟產品討論需求最恰當，最舒服的實現方式

這點我的以爲仍是很重要的，有些需求須要好好跟產品溝通的。

好比有個用戶連麥列表展現的需求，產品說要展現全部的連麥信息，若是一個用戶的連麥列表信息好大，你拉取全部連麥數據回來，接口性能就降下來了。若是產品打樁分析，會發現，通常用戶看連麥列表，也就看前幾頁~所以，奸笑，哈哈~ 其實，那個超大分頁加載問題也是相似的。即limit +一個超大的數，通常會很慢的~~

總結

本文呢，基於一次對外接口耗時優化的實踐，總結了優化接口性能的八個點，但願對你們平常開發有幫助哦~嘻嘻，有興趣能夠逛逛個人github哈，本文會收藏到github裏滴哈

https://github.com/whx123/JavaHome