RocketMQ 在小米的多场景灾备实践案例

01 为什么要容灾？

在小米内部，我们使用 RocketMQ 来为各种在线业务提供消息队列服务，比如商城订单、短信通知甚至用来收集 IoT 设备的上报数据，可以说 RocketMQ 的可用性就是这些在线服务的生命线。作为软件开发者，我们通常希望服务可以按照理想状态去运行：在没有Bug的前提下，系统可以提供正常的服务能力。

但现实的运维经验告诉我们这是不可能的，硬件故障是非常常见的问题，比如内存故障、磁盘故障等，甚至是机房相关的故障（专线故障、机房拉闸等）。因此我们需要对数据进行备份，使用多副本的方式来保证服务的高可用。Apache RocketMQ 设计上就支持多副本、多节点容灾，比如 Master-Slave 架构、DLedger 部署模式。

在小米内部，因为是面向在线业务，服务的恢复速度至关重要，而基于 Raft 协议的 DLedger 模式可以实现秒级 RTO，因此我们在 2020 年初选用了 DLedger 架构作为基本的部署模式（在 5.0 中，主从模式也可以做到自动 failover）。支持机房灾备需要增加额外的成本，下面我将用三个灾备部署的实践案例，讲解小米如何在成本和可用性的取舍上去支持灾备。

完整内容请点击下方链接查看： 

RocketMQ 在小米的多场景灾备实践案例-阿里云开发者社区

版权声明：本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《                                 阿里云开发者社区用户服务协议》和《                                 阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写                                 侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容