[[441043]]

 從嫩芽初發(fā)到綠意灼灼，韭菜到底經(jīng)歷了什么?想IPO想瘋了的創(chuàng)業(yè)者最清楚。

第一次聽到RPO，我以為是專門割韭菜的IPO，加上說這話的人不斷對我擠眉弄眼，以至于我手抖，怎么搜都搜不到這個技術(shù)名詞。

到了最后我才弄明白，他說的是RPO，而不是IPO，是災(zāi)備場景中的名詞。

好家伙，又是縮寫!不過經(jīng)過多年的宣傳，它儼然成了標(biāo)準(zhǔn)，反而全稱沒幾個人記得住。打個比方，你知道HIV，但是并不知道HIV的英文全稱是啥，就是這么朗朗上口。

但我們今天就非要看一下它的全稱。

RTO = Recovery Time Objective = 恢復(fù)時間目標(biāo) 
RPO = Recovery Point Object = 恢復(fù)點目標(biāo) 

其差別，一個是Time、一個是Point。用白話來說，就是在服務(wù)發(fā)生故障之后，能夠恢復(fù)的時間和數(shù)據(jù)恢復(fù)的程度。

比如，你的數(shù)據(jù)庫當(dāng)機了。如果你的業(yè)務(wù)能夠忍受30分鐘之內(nèi)啟動起來，那么RTO就等于30分鐘。

再比如，你的數(shù)據(jù)庫當(dāng)機了，30分鐘后恢復(fù)了。如果你的業(yè)務(wù)能夠忍受丟失最后2分鐘的數(shù)據(jù)，那么你的RPO就是2分鐘。

值得注意的是，任何宣稱RTO=0和RPO=0的廠商，都是在吹牛皮。

單機服務(wù)

對于單機服務(wù)來說，從故障到恢復(fù)正常服務(wù)，它的間隔時間不可能是0。哪怕你是用了supervisor這樣的工具瞬間把它給拉了起來，它也不可能瞬間完成。所以RTO不會等于0。

但RPO倒是可以做到逼近0損失的。因為目前的數(shù)據(jù)庫服務(wù)，大多數(shù)都會寫一份預(yù)寫日志來防止異常發(fā)生。比如ES會先寫一份translog，MySQL會先寫一份redo log，Postgres會寫一份wal日志。這些日志會順序?qū)懙酱疟P上，雖然會丟失flush()之間的一小部分數(shù)據(jù)，但大多數(shù)無傷大雅。

但單機服務(wù)無法做到HA，所以即使它的指標(biāo)再好看，對我們來說也沒有意義。

集群服務(wù)

對于集群服務(wù)來說，就需要考慮分布式環(huán)境中的復(fù)雜問題。比如Kafka采用ISR列表防止單臺機器故障之后的服務(wù)可用問題。

首先，分布式系統(tǒng)，都是通過副本機制來保證數(shù)據(jù)的冗余。主從、raft等交互方式都需要從中選出一個master來接收數(shù)據(jù)的變更操作。當(dāng)這個master故障之后，需要從 從列表 中選舉一個新的master。

拿Kafka來說，單節(jié)點當(dāng)機，短暫影響生產(chǎn)消費，故障恢復(fù)時間與 leader 選舉時間與 partition 數(shù)量有關(guān)(約 10 秒 isr 探測時間)。使用 ACK 模式，配合重試，能夠保證故障期間數(shù)據(jù)不丟失。

這已經(jīng)算是一個非常好的效果了。

但假如整個集群出現(xiàn)問題，比如，機房斷電了，怎么辦?

多機房

單機房的風(fēng)險，只能通過冗余機房來解決，目前較為流行的架構(gòu)是兩地三中心。關(guān)于兩地三中心，這里有一篇專門的文章描述。

《兩地三中心，如何部署奇數(shù)個節(jié)點?》

跨機房的集群同時會分為AB區(qū)。拿5節(jié)點服務(wù)來說，A機房部署3個，B機房部署2個，集群要求的最小節(jié)點數(shù)是3。當(dāng)B機房出現(xiàn)問題，A機房的表現(xiàn)與單機房表現(xiàn)無異。但當(dāng)A機房出現(xiàn)問題，我們就需要人工介入，在B機房手動啟動第6個節(jié)點。

故障處理的間隔時間就是RTO的值。

在這種情況下，同樣有丟失數(shù)據(jù)的風(fēng)險。5個節(jié)點，根據(jù)NWR策略，需要寫入3個才算成功。但如果數(shù)據(jù)寫入的恰好是A機房的這三個節(jié)點，數(shù)據(jù)還沒有完全同步到B機房，那同步時間間隔內(nèi)的數(shù)據(jù)就會丟失。所以智能的服務(wù)還要有能夠識別出機房和zone的能力，以便在發(fā)生問題時，B機房起碼有一份數(shù)據(jù)時刻是最新的。

End

所以，縮寫還是很有魅力的。比如，xjjdog就可以縮寫為xD，雖然你不能解碼它的意思，是不是很帶感?

作者簡介：小姐姐味道 (xjjdog)，一個不允許程序員走彎路的公眾號。聚焦基礎(chǔ)架構(gòu)和Linux。十年架構(gòu)，日百億流量，與你探討高并發(fā)世界，給你不一樣的味道。