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

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

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

也可以通過一些比較簡單的方式來判斷分布式數(shù)據(jù)庫的服務(wù)是否正常。服務(wù)很有可能處于“啟動”狀態(tài)，并且并能夠?qū)ν馓峁?shù)據(jù)庫服務(wù)，但是它無法在服務(wù)的 99分位延遲內(nèi)完成給定的工作任務(wù)（比如完成一條標準SQL的執(zhí)行），那么這個數(shù)據(jù)庫就是不健康的。

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

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

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

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

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

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

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

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

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