从嫩芽初发到绿意灼灼，韭菜到底经历了什么?想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。十年架构，日百亿流量，与你探讨高并发世界，给你不一样的味道。
