經常會收到使用者反饋在使用RDS的過程中出現卡慢，閃斷地情況，當出現此類問題的時候，首先我們要進行一下測試，看看問題出現在哪一個階段，RDS給到使用者的是一個DNS地址，其實他包括三個階段：DNS–>VIP–>DB

       我們可以在本地的應用伺服器（VM）上通過簡單的ping命令，或者資料庫的客戶端去不斷的連線測試RDS，來獲取每次連線RDS的響應時間（RT）。在正常情況下RT應該小於20ms以內，如果超出10ms，則表明了RDS的網路鏈路出現了異常，這個時候我們就需要去排查一下是在哪裡出現了問題：

（1）    當DNS鏈路服務出現問題：

當我們測試出DNS的連線比較耗時，而使用vip連線正常的時候，則表明DNS解析比較耗時，此時的問題則出現在了DNS服務上面，這個時候可以嘗試換用其它的DNS伺服器，或者啟用DNS快取服務，或者暫時在hosts檔案中繫結DNS和IP地址，等DNS服務恢復正常後在取消繫結（我們強烈建議在正常情況下不要繫結RDS的DNS和IP地址，或者直接使用IP地址進行訪問，因為RDS的IP地址可能會發生改變，繫結ip或者直連ip的方式會導致RDS訪問出錯）；

（2）    當VIP 鏈路出現問題：

當我們測試超出DNS連線比較耗時，同時使用vip連線也比較耗時的時候，則表明RDS的VIP鏈路出現了異常，這個時候可以提交RDS的工單，讓後端的人員進行排查。

（3）    正常情況下的鏈路表現：

正常情況下，通過DNS或者vip的方式去連線RDS，RT應該在20ms以下。

案例分析一：

使用者應用程式從凌晨0:05左右突然開始出現連線RDS超時，RDS，ECS的cpu，網路，io負載都不高，已經影響使用者的正常使用，使用者的報錯截圖：

第一步：獲取鏈路RT

為了驗證使用者所說的APP連線RDS出現連線超時的情況，我們需要部署監控，看看監控中是否與應用中的超時時間一致，於是在使用者app以及我們的一臺vm上部署

使用者端的APPàRDS測試：（DNS連線）

在我們自己vm上部署的探測測試：（DNS連線）

可以看到無論從使用者本地的app環境去連線RDS，還是從我們自己的vm去連線RDS，都是非常快的，沒有出現過超時：所以鏈路上是沒有問題的；

最後建議使用者從業務上去排查是否存在異常，最終定位應用異常導致。

案例分析二：

使用者反饋例項出現寫入速度過慢.寫入速度不如正常狀態下1/10.

排查使用者的RDS，ECS的cpu，io負載都不高，但在資料庫中發現了有network io的等待，是不是網路出現了異常，所以這個時候需要測試正常的一次連線RDS需要消耗多久的時間，通過SQLping發現了重要線索：

使用者在3臺不同的vm上去連線測試RDS，發現都出現了大量的連線時間高或者超時，證明了RDS的鏈路上確實存在了問題,這個時候你可以提工單進行反饋；進一步去探測DB節點的RT，結果發現在後端的DB伺服器上出現了異常，最終定位問題在後端的物理伺服器上硬體出現了問題，在替換硬體後問題得以解決。