什么是高可用
高可用是系統(tǒng)的一個(gè)特性，保證系統(tǒng)能在足夠長(zhǎng)的時(shí)間內(nèi)提供指定程度的服務(wù)等級(jí)。再細(xì)化一下，可以說(shuō)是在有限的故障條件下，提供一定級(jí)別的穩(wěn)定服務(wù)。
在傳統(tǒng)領(lǐng)域，SLA用于在商業(yè)上定義系統(tǒng)的高可用。
SLA全稱是service level agreement，在網(wǎng)絡(luò)服務(wù)供應(yīng)商領(lǐng)域被廣泛使用，約定了最小帶寬，同時(shí)服務(wù)客戶數(shù)，最大故障時(shí)間等等一系列指標(biāo)。在軟件領(lǐng)域，最廣泛使用的指標(biāo)是平均服務(wù)時(shí)間。
見下圖
因?yàn)檐浖I(lǐng)域的各項(xiàng)指標(biāo)不好度量，很難約束，因此其他指標(biāo)也很少提到。但可以想像，作為高可用的系統(tǒng)，不止要有達(dá)標(biāo)的故障時(shí)間，同時(shí)要保證在服務(wù)時(shí)間達(dá)到用戶可接受的服務(wù)質(zhì)量，對(duì)于數(shù)據(jù)庫(kù)而言，類似tps，事務(wù)平均時(shí)延，99%時(shí)延等。
各家SLA展播
| 服務(wù)商及產(chǎn)品 | 可用性 | 數(shù)據(jù)持久度 | 除外條款 | 賠償條款 |
|---|---|---|---|---|
| 阿里云ECS | 99.95% | 99.9999999% | （1）不可使用的服務(wù)時(shí)間低于5分鐘的，不計(jì)入不可用時(shí)間；（2）阿里云預(yù)先通知用戶后進(jìn)行系統(tǒng)維護(hù)所引起的，包括割接、維修、升級(jí)和模擬故障演練； （3）不可抗力以及意外事件引起的； | 不可用時(shí)間100倍 |
| 阿里云rds | 99.95% | 同上，高可用版和金融版為1分鐘 | 不可用時(shí)間100倍，高可用版和金融版，服務(wù)費(fèi)的15% - 30% - 100% （99.95%-99%-95%） | |
| AWS EC2 | 99.95% | 無(wú)活躍鏈接，運(yùn)維不算，不可抗力不算 | 低于99.95%，賠 10%；低于99%，賠30% | |
| AWS RDS | 99.95% | 類似阿里，不計(jì)時(shí)間為1分鐘 | 低于99.95%，賠 10%；低于99%，賠25% | |
| AWS S3 | 99.99% | 99.999999999% | ||
| 騰訊云云主機(jī) | 99.95% | 99.999% | 5分鐘以下不計(jì)費(fèi)，無(wú)其他除外條款 | 不可用時(shí)間100倍 |
從這幾家對(duì)比看，AWS是最強(qiáng)的，阿里也差不多了，騰訊云是相對(duì)較差的，看一下服務(wù)條款的完善程度就能明顯地感受到。
評(píng)價(jià)高可用的標(biāo)準(zhǔn)
評(píng)價(jià)系統(tǒng)高可用，可以有幾個(gè)維度：
- 有限故障下數(shù)據(jù)是否丟失，系統(tǒng)的服務(wù)等級(jí)降低幅度是否合理；
- 高壓力下系統(tǒng)的服務(wù)等級(jí)；
- 服務(wù)變更下系統(tǒng)的服務(wù)等級(jí)；
有一個(gè)關(guān)于故障條件下系統(tǒng)表現(xiàn)較好的分級(jí)，見下表：
| 分級(jí) | 描述 |
|---|---|
| 1 | Crash with data corruption, destruction. |
| 2 | Crash with new data loss. |
| 3 | Crash without data loss. |
| 4 | No crash, but with no or very limited service, low service quality. |
| 5 | Partial or limited service, with good to medium service quality. |
| 6 | Failover with significant user visible delay, near full quality of service |
| 7 | Failover with minimal to none user visible delay, near full qualityof service. |
? 摘自《來(lái)自 Google 的高可用架構(gòu)理念與實(shí)踐》
數(shù)據(jù)庫(kù)系統(tǒng)的一些度量方法
數(shù)據(jù)持久度
數(shù)據(jù)庫(kù)系統(tǒng)可以通過(guò)副本備份等方式有效提高數(shù)據(jù)持久度，抵御磁盤損壞等故障造成數(shù)據(jù)丟失的風(fēng)險(xiǎn)。
當(dāng)然隨著現(xiàn)在分布式存儲(chǔ)的發(fā)展，持久度已經(jīng)很少有人關(guān)心了，但是對(duì)于直接使用磁盤的情況，這仍然是一個(gè)需要考慮的問(wèn)題。
平均服務(wù)時(shí)間
對(duì)于計(jì)算服務(wù)可用時(shí)間，引入3個(gè)來(lái)自工業(yè)界的概念：
- MTBF (Mean Time Between Failures) =平均故障間隔時(shí)間
- MTTF (Mean Time To Failure) =平均故障時(shí)間
- MTTR (Mean Time To Repair) =平均修復(fù)時(shí)間
高可用時(shí)間=MTBF/(MTBF+MTTF)
顯然，這里存在執(zhí)行上的問(wèn)題，假設(shè)tcp超時(shí)時(shí)間是2min，那么低于兩分鐘是很難確定到底是系統(tǒng)故障還僅僅是軟件處理較慢?；蛘哕浖捎谫Y源（比如IO）受限被卡住，這是客戶也是很難判斷是否發(fā)生了故障。
對(duì)于系統(tǒng)管理員來(lái)說(shuō)，同樣存在類似的問(wèn)題，心跳檢測(cè)是最常見的監(jiān)控手段，但是心跳時(shí)間也很難設(shè)置太短，這是受網(wǎng)絡(luò)條件限制的，常常，故障的發(fā)現(xiàn)就是以分鐘計(jì)算的。
RTO/RPO
RTO和RPO是傳統(tǒng)數(shù)據(jù)庫(kù)領(lǐng)域常見的兩個(gè)衡量高可用的指標(biāo)。
- RTO(Recovery time objective):故障恢復(fù)耗時(shí)
- RPO(Recovery point objective):恢復(fù)后數(shù)據(jù)對(duì)應(yīng)的時(shí)間點(diǎn)，即丟失的數(shù)據(jù)量轉(zhuǎn)換為時(shí)間
舉個(gè)簡(jiǎn)單的例子，數(shù)據(jù)庫(kù)同城同步備機(jī)，故障后RPO必然是0，tikv一般情況下RPO也是0。RTO也是秒級(jí)的，對(duì)于不同的故障，結(jié)果也不同
請(qǐng)求成功率
對(duì)于分布式系統(tǒng)來(lái)說(shuō)，從系統(tǒng)層面考察平均服務(wù)時(shí)間的意義并不是很大，對(duì)于很多分布式系統(tǒng)來(lái)說(shuō)，單機(jī)的故障并不能影響系統(tǒng)整體穩(wěn)定的繼續(xù)運(yùn)行，從這個(gè)角度來(lái)說(shuō)，系統(tǒng)可用性可以說(shuō)是100%的。這時(shí)，計(jì)算請(qǐng)求的成功數(shù)可能更適合這樣的系統(tǒng)，如下：
可用性=成功請(qǐng)求數(shù)/總請(qǐng)求數(shù)
當(dāng)然這種指標(biāo)更方便觀察系統(tǒng)的內(nèi)部錯(cuò)誤，對(duì)于事務(wù)回滾這種行為，并不能認(rèn)為是失敗的請(qǐng)求。這是和業(yè)務(wù)行為及事務(wù)語(yǔ)義相關(guān)的。
長(zhǎng)穩(wěn)
上面提及SLA，也提到了，其實(shí)在傳統(tǒng)領(lǐng)域，不止可服務(wù)時(shí)間受人關(guān)注，服務(wù)質(zhì)量指標(biāo)（SLO）同樣受人關(guān)注。
大家都知道木桶原理，數(shù)據(jù)庫(kù)做為基礎(chǔ)軟件，既是吞吐沒(méi)有下降，一時(shí)的性能抖動(dòng)可能導(dǎo)致業(yè)務(wù)軟件的性能大幅下降。
衡量數(shù)據(jù)庫(kù)服務(wù)質(zhì)量通常有幾個(gè)指標(biāo)：
- 吞吐量，對(duì)于數(shù)據(jù)庫(kù)系統(tǒng)，一般是qps，或者tps；
- 時(shí)延，關(guān)于時(shí)延，一般有如下幾個(gè)指標(biāo), 平均時(shí)延，95%時(shí)延，99%時(shí)延，最大時(shí)延；
- 回滾率
制定合理的高可用目標(biāo)
不客氣的說(shuō)，對(duì)于絕大部分系統(tǒng)，在正常故障下，2個(gè)9到3個(gè)9已經(jīng)足夠用了，不考慮系統(tǒng)變更，這也是一個(gè)很容易達(dá)到的指標(biāo)。
而提升一個(gè)9，系統(tǒng)設(shè)計(jì)和實(shí)現(xiàn)的復(fù)雜度都要提升很多，所得未必償所失。
打個(gè)比方，我們看到阿里rds的SLA是99.95%，而且是按月結(jié)算的，那么每個(gè)月允許的故障時(shí)間大概是4min，加上1min的不計(jì)時(shí)間，算5min，嚴(yán)格來(lái)說(shuō)，這5min包含故障發(fā)現(xiàn)和故障處理?？梢韵胂瘢绻侨藖?lái)處理，5min都未必能及時(shí)登錄到系統(tǒng)上。必然是全自動(dòng)的故障處理，這個(gè)要求對(duì)系統(tǒng)的自動(dòng)化故障處理能力的要求就非常高了。很多大型互聯(lián)網(wǎng)公司也未必有這個(gè)開發(fā)能力，當(dāng)然，也沒(méi)有這個(gè)必要。
不過(guò)只要不發(fā)生大規(guī)模的故障，賠100倍的時(shí)間，對(duì)阿里也不算什么。不按客戶損失賠償，都是玩笑罷了。
參考資料
- 《SRE: google運(yùn)維解密》
- 來(lái)自 Google 的高可用架構(gòu)理念與實(shí)踐
- 關(guān)于SLA,你到底知多少？
- 云服務(wù)器(ECS)服務(wù)等級(jí)協(xié)議(SLA)
- 騰訊云服務(wù)SLA
- 《the tail at scale》
廣告
最后，打個(gè)廣告，如果對(duì)創(chuàng)業(yè)，分布式數(shù)據(jù)庫(kù)和開源社區(qū)感興趣，歡迎加入pingcap，實(shí)習(xí)和工作都很歡迎！
Email: xuwentao@pingcap.com
微信: fbisland
pingcap是國(guó)內(nèi)為數(shù)不多的newsql方向的分布式數(shù)據(jù)庫(kù)，維護(hù)國(guó)內(nèi)最頂級(jí)的開源社區(qū)，關(guān)注度近萬(wàn)，目前已在騰訊云和ucloud上線，做類f1+spanner架構(gòu)，和多家公司有合作關(guān)系。
TiDB: https://github.com/pingcap/tidb
TiKV: https://github.com/pingcap/tikv
