【消息队列】——消息队列的高可用与容灾设计
目录
- 一、高可用和容灾的区别是什么
- 1.1、高可用
- 1.2、容灾
- 二、高可用和容灾架构两个重要的衡量指标(RTO 和 RPO)
- 2.1、RTO
- 2.2、RTO
- 三、高可用、容灾RTO 和 RPO 的总结
- 四、消息队列Kafka高可用设计原理
- 五、如何设计消息队列的容灾架构?
- 5.1、理论上
- 5.2、实践中
- 5.3、 实践中如何在性能和数据可靠性上取舍?
- 5.3.1、同城容灾架构
- 5.3.2、双主题容灾架构
- 5.3.2、主备主题容灾架构
- 六、小结
本文来源:极客时间vip课程笔记
一、高可用和容灾的区别是什么
1.1、高可用
- 广义的高可用(High Availability, HA)是指系统在长时间运行过程中,能够持续提供服务的能力。高可用系统的设计目标是尽量减少系统的停机时间,确保系统在遇到硬件故障、软件错误或其他意外情况时,仍能正常运行或快速恢复。
- 在分布式系统设计领域,可以将高可用理解为:“自动抵御小规模故障的能力”。通俗地说,系统应具备这样一种能力:当少量节点故障时,系统仍然持续可用或者能快速恢复。
- 这里的“少量”是多少呢?一般来说要看系统的规模,几个节点的系统可以容忍一两个节点故障,更大规模的系统可以容忍稍多一些的节点故障。
1.2、容灾
- 容灾指的是系统面对大规模的故障时的恢复能力。
- 这里的大规模故障指的是系统同时失去大量节点,比如,因为网络、电力或空调系统故障而导致的数据中心内大规模宕机,或者由于地震等自然灾害或城市间的骨干网络故障而导致的城市级大面积故障。
- 容灾架构按照可抵御的故障规模,又分为同城容灾和异地容灾。同城容灾架构可以抵御 AZ 级故障,也就是说在失去一个机房时,系统仍然可以从故障中恢复。
- 异地容灾则可以抵御城市级故障。对于大规模系统来说,受限于成本以及性能等因素,容灾架构的 RTO 和 RPO 很难做到秒级,一般来说能做到几分钟至几十分钟已经是很优秀的水平了。
二、高可用和容灾架构两个重要的衡量指标(RTO 和 RPO)
2.1、RTO
- RTO 指的是系统可容忍的故障时长目标。
- 具体来说,RTO (Recovery Time Objective,复原时间目标) 指的是:故障发生后,从系统宕机导致服务不可用之时开始,到系统恢复至可以正常提供服务之时,这两个时间点之间的时间段。
- 比如,当系统中某个节点宕机时,设计的恢复时间不超过 10 秒,那这个 RTO 就是 10 秒;再比如说大规模故障发生后半天内便需要恢复,RTO 值就是十二小时。
2.2、RTO
- RPO 就是系统可容忍的数据丢失数量目标。
- RPO (Recovery Point Objective,复原点目标) 是指对系统的数据而言,要实现能够恢复至可以正常提供服务时,可接受的数据恢复点。
- 相比于 RTO,RPO 不是太好理解。它是一个衡量系统故障时丢失多少数据的指标,但是它的单位却是时间,可以理解为“最多可以丢失多长时间的数据”。
- 比如,对于一个单机的数据库系统,每天凌晨零时进行备份一次。如果数据库宕机,当使用备份的数据恢复服务后,系统内储存的数据只会是宕机发生前那个凌晨零时的备份,那么 RPO 的值就是 24 小时。
- 需要注意的是,RPO 的时长是不包含系统不可用的这段时间的时长的,因为系统不可用的这段时间不