从最初的萌芽到火红的嫩绿，韭菜到底经历了什么？疯狂IPO的创业者最清楚。第一次听说RPO，还以为是专门割韭菜的IPO。再加上说这话的人不停地给我使眼色，弄得我手都在发抖，怎么找也找不到这个专业术语。到最后我才明白，他说的是RPO，不是IPO，是灾备场景下的名词。老兄，另一个缩写！但经过多年的宣传，似乎已经成为标准，却很少有人记住全名。比如你知道HIV，但是你不知道HIV的英文全名是什么，太朗朗上口了。但是今天我们还得看看它的全名。RTO=RecoveryTimeObjective=RecoveryTimeObjectiveRPO=RecoveryPointObject=RecoveryPointObjective的区别，一个是Time，一个是Point。用大白话来说，就是服务失败后的恢复时间和数据恢复的程度。例如，您的数据库崩溃了。如果您的业务可以容忍在30分钟内启动，则RTO等于30分钟。再比如，你的数据库崩溃了，30分钟后恢复。如果您的企业可以容忍丢失最后2分钟的数据，那么您的RPO就是2分钟。值得注意的是，任何宣称RTO=0、RPO=0的厂商都是在吹牛。单机服务对于单机服务来说，从故障到恢复正常服务的间隔不能为0，即使你用supervisor之类的工具瞬间拉起来，也不能瞬间完成。所以RTO不会等于0。但是RPO可以做到接近零损失。因为现在的数据库服务，大部分都会写一个write-aheadlog来防止异常的发生。比如ES会先写translog，MySQL会先写redolog，Postgres会写wallog。这些日志会按顺序写入磁盘，虽然在flush()之间会丢失少量数据，但大部分都是无害的。但是单机服务无法做到HA，所以它的指标再好看，对我们来说也是没有意义的。集群服务对于集群服务，需要考虑分布式环境下的复杂问题。例如，Kafka使用ISR列表来防止单机故障后服务不可用。首先，分布式系统使用复制机制来保证数据冗余。master-slave、raft等交互方式需要选择一个master来接收数据变更操作。当master失效时，需要从slave列表中选出新的master。以Kafka为例，当单节点宕机时，生产和消费暂时受到影响，恢复时间与leader选举时间和partition数量有关（ISR检测时间约10秒）。使用ACK方式重试可以保证失败时数据不会丢失。这已经是很好的效果了。但是如果整个集群出现问题，比如机房掉电了，怎么办？多机房和单机房的风险只能通过冗余机房来解决。目前比较流行的架构是两地三中心。关于两地三中心，这里有专门的文章介绍。《两地三中心，如何部署奇数个节点?》跨机房集群会同时划分AB区。以5节点业务为例，3个部署在A机房，2个部署在B机房，集群最少需要3个节点，当B机房出现问题时，A机房性能与单机房性能相同。但是当A机房出现问题时，我们需要人工介入，手动启动B机房的第六个节点，故障排除的间隔时间就是RTO的值。在这种情况下，也存在丢失数据的风险。5个节点，根据NWR策略，需要写入3个才算成功。但是如果数据写入到A机房的这三个节点，数据还没有完全同步到B机房，就会导致同步区间内的数据丢失。因此，智能服务还必须具备识别机房和分区的能力，这样当出现问题时，至少有一份B机房的数据始终是最新的。End所以，首字母缩略词还是有魅力的。比如xjjdog可以简写成xD，虽然你不能解码它的意思，是不是很有趣？作者简介：品味小姐姐（xjjdog），一个不让程序员走弯路的公众号。专注于基础架构和Linux。十年架构，每天百亿流量，与你探讨高并发世界，给你不一样的滋味。
