前陣子和一個做資料庫服務的朋友交流，他們承接了某個企業的國產分散式資料庫的運維工作，安排了一個該資料庫的認證工程師駐場做服務，不過從半年的工作情況來看，效果並不好。作為分散式資料庫的運維，平時小問題也不需要DBA介入，分散式資料庫的故障自愈能力能夠很好的遮蔽這些小問題，並且能夠在短時間內完成自愈。如果真的出了大問題，DBA面對數十個節點的分散式資料庫環境又束手無策，很難定位問題，這種情況讓他們感到很困惑。

實際上這個問題還是挺複雜的，涉及到分散式資料庫這種典型的分散式系統與集中式資料庫之間在架構與功能上的巨大差異。在傳統的資料庫運維上，我們習慣於檢視一些指標，例如CPU負載，鎖超時，活躍會話數、錯誤率等。對於分散式資料庫來說，這些指標實際上並沒有相對於集中式資料庫環境那麼重要，因為分散式資料庫從體系架構上具有極高的容錯能力。資料庫的某個物理節點、某個服務、某個分割槽、某個副本都可以出故障，此時資料庫內部雖然已經存在故障，但是你一點都不需要為此擔心，資料庫依然能夠很好的對外提供服務。這些指標實際上都沒有正確的反映出資料庫是否能夠為客戶端流量提供正常的服務，而這些才是使用者需要關注的。

在“具有動態糾錯能力”並且“可以自動擴充套件、動態負載均衡”的分散式資料庫中，如果單個服務無法實現完整的資料庫功能，那麼單個服務是否處於“啟動”或者“活躍”狀態並不重要，因為這些很可能都不會影響分散式資料庫對外提供服務，這使得像ping延時、CPU使用率這樣的簡單檢查幾乎毫無用處。雖然利用傳統的監控理念，判斷某個服務是否宕掉並不複雜，但要確定處於活動狀態的資料庫服務是否健康要困難得多。

也可以透過一些比較簡單的方式來判斷分散式資料庫的服務是否正常。服務很有可能處於“啟動”狀態，並且並能夠對外提供資料庫服務，但是它無法在服務的 99分位延遲內完成給定的工作任務（比如完成一條標準SQL的執行），那麼這個資料庫就是不健康的。

對於分散式資料庫來說，無法在P99延時內執行完某條SQL，但是資料庫服務還是能承接相關業務的，這種情況是比較常見的故障場景，也是我們的DBA面對的束手無策的常見場景。這種場景大多數情況下與資料庫的某些元件流量過載有關，在高併發服務中，“高併發的重負載”會在分散式資料庫中受到某些序列化機制的影響，正常情況下，透過資源管理器與佇列機制有序的排序。但是如果某個元件出現過載，那麼佇列會產生溢位，這可能導致 RPC 呼叫的延遲增加。一般情況下遇到這種情況，下游服務將簡單地使請求超時並進行重試，這種機制將會導致高負載情況下出現分散式系統的效率下降的問題，此時分散式資料庫的總體效能會有所下降。而如果此時疊加一些其他的因素，比如某塊硬碟的IO延時過大、某個網路卡出現丟包、某個節點的作業系統出現嚴重換頁，那麼整個分散式資料庫環境就有可能出現了正常的處理邏輯無法承受的臨界狀態，再疊加上資料庫本身就存在的一些對此類情況處理不周的BUG，那麼資料庫出現嚴重的問題，甚至出現無法對外提供服務的情況，也是必然的。

而且分散式資料庫一旦進入這樣的狀態，要想透過自身的容錯能力與資源排程能力恢復系統執行，那就不是秒鐘級甚至分鐘級能夠完成的了。此時最好的方法應該是徹底關閉資料庫系統，解決掉出現問題的根源問題，然後重新啟動資料庫。但是對於分散式資料庫這種大型系統而言，在出現故障的時候關閉資料庫在大多數場景中也是不現實的。因此我們只有退而求其次，降低資料庫當前的複雜，解決掉故障問題是退而求其次的解決方案。如果這個方法還是無法執行，那麼就只能先解決掉導致問題的故障，再慢慢等著系統恢復了。

綜上所述，分散式資料庫的某個服務在其生命週期中很可能在不同程度的“健康狀態”之間波動，從完全正常，能夠以預期的併發級別執行下降到接近不正常，此時可能某些高負載導致某的佇列溢位，如果問題持續惡化，資料庫將進入“不正常”狀態，此時資料庫服務質量大幅下降。對於分散式資料庫而言，自適應、自我修復的能力在大部分情況下可以自動處理這種波動，併力求自動恢復。可惜的是這種最佳預期並不總是在生產環境中得以實現，分散式資料庫可能存在某些BUG；而高併發負載的持續時間可能超出硬體的能力範圍；麵包掉在地上黃油朝下的機率也極高。因此分散式資料庫可以解決一切集中式資料庫運維中的問題，達到極高的可用性的說法並不成立。

對於分散式資料庫運維來說，小問題無需介入，大問題介入不了是一種常態。其最主要的問題還是我們無法對分散式資料庫的健康狀態有一個十分準確的評估。如果我們能夠了解分散式資料庫的內部狀態，並提前做出預警，那麼很多故障還是可以避免的。比如負載過高達到硬體資源極限可以透過切斷部分流量來實現快速恢復。而如果能夠在問題發生的更早期介入，資料庫的恢復時間也會縮短很多。

比較麻煩的是，分散式資料庫的健康評估是比較複雜的，對於分散式資料庫來說，健康評估更像是一個布魯姆過濾器。你發現資料庫有問題，那麼資料庫肯定有問題。但是如果你檢查資料庫的狀態是健康的，那麼資料庫僅僅是“可能處於健康狀態”，我們必須透過其他的因素來確認其實健康的。

基於上面的認知，我們覺得針對分散式資料庫的健康度需要從幾個方面來做綜合評估，傳統的指標當然還是需要的，我們需要從作業系統負載與效能、資料庫負載、資料庫併發、叢集與網路、負載均衡度、資料庫容量等數個方面進行評估。

除此之外針對分散式資料庫，我們還需要引入新的評估要素，那就是資料庫功能的健康度評估，簡單查詢、簡單寫入、全表掃描、索引掃描、並行掃描、DDL操作等多種資料庫業務的響應時間是否合理（比如是否超出P99延時），不同計算節點執行相同的簡單操作的延時是否均衡等，也應該作為健康評估的內容。必須如此，才能解決分散式資料庫健康評估的“布魯姆過濾器陷阱”。

僅僅實現準確的健康評估還不足夠，更重要的是發現健康問題之後還需要能夠進行問題溯源與解決方案分析。要想實現這一點，必須從兩個方面做監控的增強。一方面是更加準確與全面的採集分散式資料庫的指標，並能夠高效的進行異常檢測，從而能夠全面的發現資料庫指標的異常；另外一方面是能夠快速的積累故障模型，構建常見故障的分析診斷與應急處置的標準化方法。

比如上面是某國產分散式資料庫的一個故障場景，該場景會導致業務響應變慢。只要擁有充分的指標資料，透過規則引擎很容易描述出其中的場景，並形成自動化分析與診斷的工具。一切恐懼都來自於未知，正是因為我們對國產分散式資料庫的運維經驗積累還不充分，才導致了遇到問題時的手足無措。二十多年前，我們面對Oracle資料庫的時候，也是如此的，隨著應用場景的豐富以及運維經驗被不斷的積累，這些問題都會慢慢好起來的。

分散式資料庫的健康評估

相關文章