本文主要是介绍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,虽然你不能解码它的意思,是不是很带感?
这篇关于RTO, RPO是啥?是割韭菜的意思么?的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!