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

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

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

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

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

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

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

   對(duì)兩類問(wèn)題分別進(jìn)行排查:

MongoDB

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

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.

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

這點(diǎn)在以后的應(yīng)用中，大家可以注意下。

Mysql

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

開始時(shí)猜測(cè)有可能業(yè)務(wù)內(nèi)做了某些寫主庫(kù)的操作，比如寫mysql，或?qū)憆edis之類的，跨機(jī)房寫導(dǎo)致的延遲高。

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

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

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

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

問(wèn)題定位后，開始嘗試解決。

解決問(wèn)題前需要先理清思路：

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

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

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

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

當(dāng)啟用這種cache后，效果就很明顯，可以看到：

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

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

總結(jié)

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

最后插個(gè)廣告，猜猜我畫的是啥？

 

來(lái)自：https://mp.weixin.qq.com/s/4Fq7gLoV1my7UT-h9VI0ig

 

標(biāo)簽： idc Mysql 代碼 電信機(jī)房 機(jī)房 數(shù)據(jù)庫(kù) 網(wǎng)絡(luò)

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