RTO, RPO是啥？是割韭菜的意思么？
從嫩芽初發到綠意灼灼，韭菜到底經歷了什么?想IPO想瘋了的創業者最清楚。
第一次聽到RPO，我以為是專門割韭菜的IPO，加上說這話的人不斷對我擠眉弄眼，以至于我手抖，怎么搜都搜不到這個技術名詞。
到了最后我才弄明白，他說的是RPO，而不是IPO，是災備場景中的名詞。
好家伙，又是縮寫!不過經過多年的宣傳，它儼然成了標準，反而全稱沒幾個人記得住。打個比方，你知道HIV，但是并不知道HIV的英文全稱是啥，就是這么朗朗上口。
但我們今天就非要看一下它的全稱。
- RTO = Recovery Time Objective = 恢復時間目標
- RPO = Recovery Point Object = 恢復點目標
其差別，一個是Time、一個是Point。用白話來說，就是在服務發生故障之后，能夠恢復的時間和數據恢復的程度。
比如，你的數據庫當機了。如果你的業務能夠忍受30分鐘之內啟動起來，那么RTO就等于30分鐘。
再比如，你的數據庫當機了，30分鐘后恢復了。如果你的業務能夠忍受丟失最后2分鐘的數據，那么你的RPO就是2分鐘。
值得注意的是，任何宣稱RTO=0和RPO=0的廠商，都是在吹牛皮。
單機服務
對于單機服務來說，從故障到恢復正常服務，它的間隔時間不可能是0。哪怕你是用了supervisor這樣的工具瞬間把它給拉了起來，它也不可能瞬間完成。所以RTO不會等于0。
但RPO倒是可以做到逼近0損失的。因為目前的數據庫服務，大多數都會寫一份預寫日志來防止異常發生。比如ES會先寫一份translog，MySQL會先寫一份redo log，Postgres會寫一份wal日志。這些日志會順序寫到磁盤上，雖然會丟失flush()之間的一小部分數據，但大多數無傷大雅。
但單機服務無法做到HA，所以即使它的指標再好看，對我們來說也沒有意義。
集群服務
對于集群服務來說，就需要考慮分布式環境中的復雜問題。比如Kafka采用ISR列表防止單臺機器故障之后的服務可用問題。
首先，分布式系統，都是通過副本機制來保證數據的冗余。主從、raft等交互方式都需要從中選出一個master來接收數據的變更操作。當這個master故障之后，需要從 從列表 中選舉一個新的master。
拿Kafka來說，單節點當機，短暫影響生產消費，故障恢復時間與 leader 選舉時間與 partition 數量有關(約 10 秒 isr 探測時間)。使用 ACK 模式，配合重試，能夠保證故障期間數據不丟失。
這已經算是一個非常好的效果了。
但假如整個集群出現問題，比如，機房斷電了，怎么辦?
多機房
單機房的風險，只能通過冗余機房來解決，目前較為流行的架構是兩地三中心。關于兩地三中心，這里有一篇專門的文章描述。
《兩地三中心，如何部署奇數個節點?》
跨機房的集群同時會分為AB區。拿5節點服務來說，A機房部署3個，B機房部署2個，集群要求的最小節點數是3。當B機房出現問題，A機房的表現與單機房表現無異。但當A機房出現問題，我們就需要人工介入，在B機房手動啟動第6個節點。
故障處理的間隔時間就是RTO的值。
在這種情況下，同樣有丟失數據的風險。5個節點，根據NWR策略，需要寫入3個才算成功。但如果數據寫入的恰好是A機房的這三個節點，數據還沒有完全同步到B機房，那同步時間間隔內的數據就會丟失。所以智能的服務還要有能夠識別出機房和zone的能力，以便在發生問題時，B機房起碼有一份數據時刻是最新的。
End
所以，縮寫還是很有魅力的。比如，xjjdog就可以縮寫為xD，雖然你不能解碼它的意思，是不是很帶感?
作者簡介：小姐姐味道 (xjjdog)，一個不允許程序員走彎路的公眾號。聚焦基礎架構和Linux。十年架構，日百億流量，與你探討高并發世界，給你不一樣的味道。
