消息队列的高可用与容灾设计
李玥

你好,我是李玥。
上节课我们通过学习 Kafka 创建主题的过程,掌握了消息队列控制面配置下发的设计方法。
这节课我们继续学习消息队列控制面的另外一个重要功能:高可用。学习一下常见的消息队列都是如何实现高可用架构的,进一步的,在理解高可用架构的实现原理基础上,看看如何基于高可用能力来设计消息队列的容灾架构。
高可用和容灾的区别是什么?
广义的高可用(High Availability, HA)是指系统在长时间运行过程中,能够持续提供服务的能力。高可用系统的设计目标是尽量减少系统的停机时间,确保系统在遇到硬件故障、软件错误或其他意外情况时,仍能正常运行或快速恢复。
在分布式系统设计领域,可以将高可用理解为:“自动抵御小规模故障的能力”。通俗地说,系统应具备这样一种能力:当少量节点故障时,系统仍然持续可用或者能快速恢复。
这里的“少量”是多少呢?一般来说要看系统的规模,几个节点的系统可以容忍一两个节点故障,更大规模的系统可以容忍稍多一些的节点故障。
在设计一个系统的高可用和容灾架构时,有两个重要的衡量指标:RTO 和 RPO。
RTO 指的是系统可容忍的故障时长目标,RPO 就是系统可容忍的数据丢失数量目标。
具体来说,RTO (Recovery Time Objective,复原时间目标) 指的是:故障发生后,从系统宕机导致服务不可用之时开始,到系统恢复至可以正常提供服务之时,这两个时间点之间的时间段。
公开
同步至部落
取消
完成
0/2000
笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结

1. 高可用系统的设计目标是尽量减少系统的停机时间,确保系统在遇到硬件故障、软件错误或其他意外情况时,仍能正常运行或快速恢复。 2. RTO(Recovery Time Objective,复原时间目标)指的是故障发生后,从系统宕机导致服务不可用之时开始,到系统恢复至可以正常提供服务之时,这两个时间点之间的时间段。 3. RPO(Recovery Point Objective,复原点目标)是指对系统的数据而言,要实现能够恢复至可以正常提供服务时,可接受的数据恢复点。 4. 大多数现代的消息队列的高可用能力,RTO 和 RPO 通常为“0~几秒钟”,即系统故障时,最多几秒钟就会自动恢复,最多丢失几秒钟的数据。 5. 容灾指的是系统面对大规模的故障时的恢复能力,分为同城容灾和异地容灾,RTO 和 RPO 很难做到秒级,一般来说能做到几分钟至几十分钟已经是很优秀的水平了。 6. Kafka 控制面的高可用主要是通过 ZooKeeper 的选举能力实现的,确保 Kafka 集群的控制面功能不中断。 7. Coordinator 的功能是管理 Consumer 和 Partition 的绑定关系,其高可用设计和 Controller 是一样的,都是通过 ZooKeeper 选举来实现的。 8. Kafka 的数据面组件只有 Broker 一个组件,当某个 Broker 节点宕机时,会通过选举机制选举出其他可用 Broker 上的副本作为这个分区的新 Leader 来继续提供服务。 9. 同城容灾架构通常采用多 AZ 部署或双主题方案,可以实现较好的可用性和数据一致性。 10. 异地容灾则因受限于网络延迟,多采用主备架构,在可用性、性能和数据可靠性之间寻求一个合理平衡点。
仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《消息队列高手课》,新⼈⾸单¥59
《消息队列高手课》,新⼈⾸单¥59
立即购买
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
登录 后留言
精选留言
由作者筛选后的优质留言将会公开显示,欢迎踊跃留言。
收起评论