這篇文章的內(nèi)容是兩年前的兩個多IDC高延遲的Troubleshooting，經(jīng)過仔細的分析和定位，最終解決，并對線上業(yè)務起到了很好的優(yōu)化效果。分享給大家，共同交流學習。

最近在梳理某項目上各服務接口的性能情況，遇到兩個問題。以下是定位和解決問題的一個思路，分享給大家。

業(yè)務之前并沒有詳細的性能日志記錄，僅在電信機房(T機房)進行了性能測試，結果是各接口滿足預期，服務上線。

在進一步對接口進行性能分析時，對各業(yè)務接口的關鍵路徑添加了日志統(tǒng)計，通過日志進行分析，將接口的延遲進行統(tǒng)計，接入Grafana，觀察數(shù)據(jù)后，發(fā)現(xiàn)兩類問題。

1. 連接MongoDB的服務，網(wǎng)通機房(C機房)延遲比電信機房(T機房)要高。

2. 連接Mysql的服務，網(wǎng)通機房(C機房)延遲比電信機房(T機房)高。

   NOTE: 這些服務接口，都是只讀，沒有寫操作。

   對兩類問題分別進行排查:

MongoDB

簡單的排查后發(fā)現(xiàn)，MongoDB實例有過一次遷移，并且遷移后只保留了電信機房(T機房)的實例，網(wǎng)通機房(C機房)沒有從庫，所以網(wǎng)通機房(C機房)延遲比電信機房(T機房)高。對網(wǎng)通機房(C機房)部署了從庫實例后，卻意外發(fā)現(xiàn)電信機房(T機房)的延遲比網(wǎng)通機房(C機房)高了。再次排查后發(fā)現(xiàn)，代碼中配置的MongoDB的讀策略是secondary（從庫優(yōu)先），所以網(wǎng)通機房(C機房)有從庫后，電信機房(T機房)也去網(wǎng)通機房(C機房)讀取，導致了電信機房(T機房)的延遲變高。更改讀策略為nearest（就近優(yōu)先），有所好轉，但并沒有預想的效果那么好。仔細看下官方文檔

The driver reads from a random member of the set that has a ping time that is less than 15ms slower than the member with the lowest ping time. Reads in the MongoClient::RP_NEAREST mode do not consider the member’s type and may read from both primaries and secondaries.

就會發(fā)現(xiàn)， nearest是在客戶端維護一個到各個實例延遲小于15ms的集合 ，而我們電信機房(T機房)到網(wǎng)通機房(C機房)是光纖直連，延遲在12ms左右，所以，每次客戶端可能會連接到電信機房(T機房)，也可能到網(wǎng)通機房(C機房)。

這點在以后的應用中，大家可以注意下。

Mysql

在所有的服務中，只有一個服務接口是讀mysql實現(xiàn)的，而這個接口的表現(xiàn)更是奇怪，網(wǎng)通機房(C機房)的延遲比電信機房(T機房)多100 ms+。

開始時猜測有可能業(yè)務內(nèi)做了某些寫主庫的操作，比如寫mysql，或寫redis之類的，跨機房寫導致的延遲高。

實際分析后發(fā)現(xiàn)，業(yè)務內(nèi)并沒有寫操作，多出的時間就是讀mysql的時間。

mysql是有網(wǎng)通機房(C機房)的從庫的，為什么讀取從庫的數(shù)據(jù)，延遲還會這么高呢。在我們服務端ping 網(wǎng)通機房(C機房)的mysql ip，發(fā)現(xiàn)延遲正常，只有零點幾毫秒，不存在網(wǎng)絡問題。

下一步就是通過抓包，分析下我們服務端跟mysql間到底有哪些交互，到底是哪個環(huán)節(jié)慢了。

根據(jù)抓包結果發(fā)現(xiàn)，正常的select查表請求很快能得到響應，但當從我們服務端發(fā)送一個 “Describe tableName”的請求到mysql 服務端時，服務端等待了較長時間(30ms+)才返回結果，而且一次接口服務請求中，有多次Describe的請求，這樣，導致網(wǎng)通機房(C機房)最終延遲很高。

問題定位后，開始嘗試解決。

解決問題前需要先理清思路：

1. DescribeTableName 這個命令是干什么用的，業(yè)務里并沒有顯式調(diào)用。這個請求能不能去掉。

2. 如果不能去掉，那它的延遲為什么這么高，能不能優(yōu)化？

第一個問題比較簡單，Describe 命令是現(xiàn)在ORM中比較通用的做法，通過獲取數(shù)據(jù)庫的表結構，來動態(tài)的創(chuàng)建Model。如果不調(diào)用Describe命令，當然也可以做到，那樣就需要自己業(yè)務端對每個model進行聲明，這樣開發(fā)成本會大大增加，這個方式不可取。所以需要保留Describe命令。

第二個問題，延遲為什么高，這個命令是很簡單的一個命令，沒有任何復雜的操作，而且主庫上都沒有這個問題。結合DBA同學在Mysql上使用了Atlas中間件，可以大膽猜想下，應該是這個中間件搞的鬼，把select請求分配到從庫執(zhí)行，但是把Describe分配到了主庫執(zhí)行，有可能是因為Atlas中間件只考慮了一些讀的SQL，把這類請求分配到從庫，而其它各種請求，可能由于過于復雜，就默認分配到主庫去執(zhí)行。當然這只是猜測，沒有查看過Atlas的源碼，所以不能妄下結論。結合已經(jīng)整理到的線索，跟DBA同學進行了確認，確定 Describe命令確實被Atlas中間件發(fā)送到主庫去執(zhí)行了，至于這么做的原因， 是為了避免主從結構不一致時，從庫拿到的表結構錯誤 。這種情況下，我們也不能評價說中間件做的到底合理不合理，所以我們需要從自己的角度再思考下能不能優(yōu)化。如果說希望避免每次請求都執(zhí)行Describe命令，除了說剛才提到的自己聲明，另外一個方式就是cache了，因為表結構變化的頻次太低了，我們完全可以設置一個較長時間的cache，來避免頻繁的這種請求。業(yè)務使用的是  Phalcon 框架，這個框架中已經(jīng)提供了這種meta-Data cache的方案,Yii中也有類似的實現(xiàn): schemaCaching。

當啟用這種cache后，效果就很明顯，可以看到：

網(wǎng)通機房(C機房)延遲從原來的120ms降到7ms, 電信機房(T機房)延遲從原來的10ms降低到5ms.

后續(xù)需要考慮的就是，如果表結構發(fā)生變化，如何在不影響業(yè)務的情況下進行更新。這個也可以有多種實現(xiàn)的方案，大家可以自己想下。

總結

解決問題的思路就在于，遵循最小化原則，先對可能產(chǎn)生這種問題原因進行大膽猜測，然后快速驗證，逐步縮小范圍，將問題定位到一個最小可復現(xiàn)的范圍內(nèi)，再深入分析具體原因。當然這一切都要有數(shù)據(jù)說話，如果平時開發(fā)中，能提供足夠豐富的日志數(shù)據(jù)，就可以很快的定位問題，甚至提前發(fā)現(xiàn)問題。

最后插個廣告，猜猜我畫的是啥？

 

來自：https://mp.weixin.qq.com/s/4Fq7gLoV1my7UT-h9VI0ig

 

標簽： idc Mysql 代碼 電信機房 機房 數(shù)據(jù)庫 網(wǎng)絡

版權申明：本站文章部分自網(wǎng)絡，如有侵權，請聯(lián)系：west999com@outlook.com
特別注意：本站所有轉載文章言論不代表本站觀點！
本站所提供的圖片等素材，版權歸原作者所有，如需使用，請與原作者聯(lián)系。