資料庫高可用的定義和度量

作者：徐文韜

什麼是高可用

高可用是系統的一個特性，保證系統能在足夠長的時間內提供指定程度的服務等級。再細化一下，可以說是在有限的故障條件下，提供一定級別的穩定服務。

在傳統領域，SLA用於在商業上定義系統的高可用。

SLA全稱是service level agreement，在網路服務供應商領域被廣泛使用，約定了最小帶寬，同時服務客戶數，最大故障時間等等一系列指標。在軟體領域，最廣泛使用的指標是平均服務時間。

見下圖

因為軟體領域的各項指標不好度量，很難約束，因此其他指標也很少提到。但可以想像，作為高可用的系統，不止要有達標的故障時間，同時要保證在服務時間達到用戶可接受的服務質量，對於資料庫而言，類似tps，事務平均時延，99%時延等。

各家SLA展播

從這幾家對比看，AWS是最強的，阿里也差不多了，騰訊雲是相對較差的，看一下服務條款的完善程度就能明顯地感受到。

評價高可用的標準

評價系統高可用，可以有幾個維度：

1. 有限故障下數據是否丟失，系統的服務等級降低幅度是否合理；
2. 高壓力下系統的服務等級；
3. 服務變更下系統的服務等級；

有一個關於故障條件下系統表現較好的分級，見下表：

摘自《來自 Google 的高可用架構理念與實踐》

資料庫系統的一些度量方法

數據持久度

資料庫系統可以通過副本備份等方式有效提高數據持久度，抵禦磁碟損壞等故障造成數據丟失的風險。

當然隨著現在分散式存儲的發展，持久度已經很少有人關心了，但是對於直接使用磁碟的情況，這仍然是一個需要考慮的問題。

平均服務時間

對於計算服務可用時間，引入3個來自工業界的概念：

1. MTBF (Mean Time Between Failures) =平均故障間隔時間
2. MTTF (Mean Time To Failure) =平均故障時間
3. MTTR (Mean Time To Repair) =平均修復時間

高可用時間=MTBF/(MTBF+MTTF)

顯然，這裡存在執行上的問題，假設tcp超時時間是2min，那麼低於兩分鐘是很難確定到底是系統故障還僅僅是軟體處理較慢。或者軟體由於資源（比如IO）受限被卡住，這是客戶也是很難判斷是否發生了故障。

對於系統管理員來說，同樣存在類似的問題，心跳檢測是最常見的監控手段，但是心跳時間也很難設置太短，這是受網路條件限制的，常常，故障的發現就是以分鐘計算的。

RTO/RPO

RTO和RPO是傳統資料庫領域常見的兩個衡量高可用的指標。

1. RTO(Recovery time objective):故障恢復耗時
2. RPO(Recovery point objective):恢復後數據對應的時間點，即丟失的數據量轉換為時間

舉個簡單的例子，資料庫同城同步備機，故障後RPO必然是0，tikv一般情況下RPO也是0。RTO也是秒級的，對於不同的故障，結果也不同

請求成功率

對於分散式系統來說，從系統層面考察平均服務時間的意義並不是很大，對於很多分散式系統來說，單機的故障並不能影響系統整體穩定的繼續運行，從這個角度來說，系統可用性可以說是100%的。這時，計算請求的成功數可能更適合這樣的系統，如下：

可用性=成功請求數/總請求數

當然這種指標更方便觀察系統的內部錯誤，對於事務回滾這種行為，並不能認為是失敗的請求。這是和業務行為及事務語義相關的。

長穩

上面提及SLA，也提到了，其實在傳統領域，不止可服務時間受人關注，服務質量指標（SLO）同樣受人關注。

大家都知道木桶原理，資料庫做為基礎軟體，既是吞吐沒有下降，一時的性能抖動可能導致業務軟體的性能大幅下降。

衡量資料庫服務質量通常有幾個指標：

1. 吞吐量，對於資料庫系統，一般是qps，或者tps；
2. 時延，關於時延，一般有如下幾個指標, 平均時延，95%時延，99%時延，最大時延；
3. 回滾率

制定合理的高可用目標

不客氣的說，對於絕大部分系統，在正常故障下，2個9到3個9已經足夠用了，不考慮系統變更，這也是一個很容易達到的指標。

而提升一個9，系統設計和實現的複雜度都要提升很多，所得未必償所失。

打個比方，我們看到阿里rds的SLA是99.95%，而且是按月結算的，那麼每個月允許的故障時間大概是4min，加上1min的不計時間，算5min，嚴格來說，這5min包含故障發現和故障處理。可以想像，如果是人來處理，5min都未必能及時登錄到系統上。必然是全自動的故障處理，這個要求對系統的自動化故障處理能力的要求就非常高了。很多大型互聯網公司也未必有這個開發能力，當然，也沒有這個必要。

不過只要不發生大規模的故障，賠100倍的時間，對阿里也不算什麼。不按客戶損失賠償，都是玩笑罷了。

參考資料

1. 《SRE: google運維解密》
2. 來自 Google 的高可用架構理念與實踐
3. 關於SLA,你到底知多少？
4. 雲伺服器(ECS)服務等級協議(SLA)
5. 騰訊雲服務SLA
6. 《the tail at scale》

推薦閱讀：