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

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

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

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

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

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

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

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

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

基于上面的認知，我們覺得針對分布式數據庫的健康度需要從幾個方面來做綜合評估，傳統的指標當然還是需要的，我們需要從操作系統負載與性能、數據庫負載、數據庫并發、集群與網絡、負載均衡度、數據庫容量等數個方面進行評估。

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

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

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