如何解決寫接口出現的問題

這篇文章主要介紹“如何解決寫接口出現的問題”，在日常操作中，相信很多人在如何解決寫接口出現的問題問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”如何解決寫接口出現的問題”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

深夜，領導：“你寫的接口有問題!趕緊起床瞧瞧”。Ding!催命軟件一響，你就知道，該 Work 了......

可思來想去，覺得不可能啊。我的代碼，就是一個簡單的 Redis 查詢啊，難不成是 Redis 掛了?

同事把證據全部發到了群里，是你的接口無疑。一個簡單的 Get 查詢，平均耗時達到了 2 秒。jstack，promethus  的監控，把問題全部指向到了你的接口!

登錄 Redis 服務器，一切正常。該怎么辦?要這么不明不白不清不楚的背個章丘大鐵鍋么?

快是原罪

這種情況下，要相信自己的直覺。你的接口又快又好，很可能是木秀于林，鶴立雞群，當了替罪鳥。

在 “某些” "高并發"環境下，由于資源未做隔離，在發生問題的時候，一些日志和工具的表現，會有非常強的迷惑性。

發生問題的，都是速度最快、請求最多的接口，但理論上并不可能。

如上圖。這種情況很常見。大多數請求，通過 Tomcat 線程池的調度，進行真正的業務處理。

當然線程池是不干這種臟活的，它把請求交給資源處理池去處理，比如：

• 一個數據庫連接池，執行耗時的統計操作和迅速的查詢操作。

• 一個 Redis 連接池，執行阻塞性的慢查詢和簡單的 GET SET。

• 一個 Http 連接池(HTTPClient、OkHTTP 等)，遠程調用速度不等的資源。

• ...

我們平常的編碼中，通常都會共用這樣的資源池。因為它寫起代碼來簡單，不需要動腦。

但如果你的服務本身，并沒有做好拆分以及隔離，問題就是致命的。比如，你把報表接口和高并發的 C 端接口放在了一個實例上。

這時候，你就有可能被報表接口給坑了。

一個例子

我們以數據庫連接池為例，來說明一下這個過程，先看一下以下基礎信息：

• Tomcat 的連接池，配置大小為 200 個。

• MySQL 的連接池，配置大小為 50 個，算是比較大了。

• 接口 A 需要調用耗時的查詢，耗時為 5 秒。

• 接口 B 速度非常快，查詢數據庫響應時間在 200ms 以下。

速度快的 B 接口，請求量是遠遠大于接口 A 的，平常情況下相安無事。

有一天，接口 A 忽然有了大量的查詢，由于它的耗時比較長，迅速把數據庫的 50 個連接池給占滿了(接口 B 由于響應快，持有時間短，慢慢連接會被 A  吃掉)。

這時候，無論是接口 A，還是接口 B 的請求，都需要等待至少 5 秒鐘，才能獲取下一條數據庫連接，業務才能正常走下去。

不一小會兒，服務的狀態就變成這樣：

• 數據庫連接池 50 個連接，迅速占滿，而且幾乎全被慢查詢占滿。

• Tomcat 連接池的 200 個連接，迅速被占滿，其中大部分是速度快的接口 B，因為它的請求量大速度快。

• 所有接口都 Block 在 Tomcat 的線程上。進而造成：哪怕是查詢一個非數據庫的請求，也要等待 5 秒左右。

一般在遇到這種問題的時候，我們都傾向于使用 jstack 打印信息堆棧，或者查看一些內部的監控曲線。

可惜的是，這些信息，大部分都是騙人的，你看到的慢查詢，并不是真正的慢查詢。

從上面的分析中，你應該很容易看出問題的癥結所在：未隔離的瓶頸資源引起上游資源的連鎖反應。

但在平常的工作中，我不止一次看到有同學對此手忙腳亂。很多證據都指向了一些又快又好的接口，而這些根本和它們一點關系都沒有。他們樂呵呵的截圖，@相關人等，囂張至極。

在遇到這種情況的時候，你可以使用下面的腳本進行初步分析：

$ cat 10271.tdump| grep "waiting to lock " | awk '{print $5}' | sort | uniq -c | sort -k1 -r  26 <0x0000000782e1b590>   18 <0x0000000787b00448>   16 <0x0000000787b38128>   10 <0x0000000787b14558>

上面的例子，我們找到給 0x0000000782e1b590 上鎖的執行棧，可以發現全部是卡在 HttpClient 的讀操作上了。

在實際場景中，可以看下排行比較靠前的幾個鎖地址，找一下共性：

而這些顯示信息非常少的堆棧，才是問題的根本原因。

如何解決

增加 Tomcat 連接池的大小，或者增加連接池的大小，并不能解決問題，大概率還會復現。

最好的解決方式，當然是把耗時的服務和正常的服務拆分開來，比如時下流行的微服務。你的服務查詢慢，自己訪問超時，和我的服務，一丁點兒關系都沒有。

但是，你的服務即然能遇到這種問題，就證明你的公司缺乏這種改造的條件。就只能在單體服務上來做文章。

這種做法，就是隔離：

如上圖，我們在同一個工程里，創建了兩個 MySQL 數據庫連接池，指向了相同的 MySQL 地址。

使用這種方式，連接池的操作，就能夠相對做到互不影響。但到現在為止，還沒完，因為你的 Tomcat 連接池依然是共享的。

慢查詢相關的，從連接池中獲取連接的策略，要改一下，不能一直等待，而應該采用 FailFast  的方式(獲取連接短時間的超時也是可以的)，否則癥狀還是一樣。

時下流行的熔斷概念，也在一定程度上實踐這種隔離性。

到此，關于“如何解決寫接口出現的問題”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！