多活架构的应用尚不普遍

对于金融这类天然对高可用性有较高要求的行业而言，多活数据库架构早就成了必选项。但在拥有上千年历史的餐饮行业中，多活架构的应用实践并不普遍，餐饮企业更多会基于成本、技术复杂度、数据一致性等考量，选择采用单一数据库架构，即所有数据集中存储在一个数据库实例中。

当企业的业务体量和复杂度都相对较低时，单一数据库架构不失为一个性价比极高的选择。但当业务体量和复杂度陡增，单一数据库架构的局限性愈发明显。比如，当业务体量增长到一定程度时，单一数据库的读写压力也会随之增大，容易出现性能瓶颈，进而影响系统响应速度。最致命的是，单一数据库架构等同于“把鸡蛋都放在一个篮子里”，一旦出现人为操作错误、电力系统故障、物理灾害等风险导致数据库宕机，整个业务系统也会跟着全面停摆。

“目前在餐饮行业中，多活架构的应用尚不普遍，企业更多是在数字化转型的推动下开始逐步考虑做多活。此外，多活架构在餐饮行业推广面临的挑战也比较多，包括技术要求较高、成本投入大以及数据一致性等问题。”尽管如此，麦当劳中国 IT 团队指出， 随着数字化转型的深入，多活架构正逐渐成为餐饮行业的一个确定趋势，特别是对于大型 餐饮企业来说，构建多活的高可用架构已经成了保障业务持续稳定运行的必然选择。

麦当劳中国正是基于业务稳定性与连续性的考量，对数据库进行了 3AZ 改造，即在三个可用区（Availability Zone，简称 AZ）部署数据库。

从理论上讲，像麦当劳中国这样的餐饮巨头，过去采用单一数据库架构并非最佳实践。但在麦当劳中国进行本地数字化转型的初期，为了简化系统复杂度，单一数据库架构自然成为一个过渡性的阶段性状态。此外，麦当劳中国当时还面临另外一个现实挑战：一个运行超过 10 年的数据中心也需要迁移到新的中台方案中。在完成整体迁移之前，系统需要暂时依赖单一数据库架构来维持正常运行。

2019 年，麦当劳中国开始正式推进数字化转型进程。随着企业 IT 服务不断增加，来自 APP、小程序的流量和订单占比越来越高。在用餐高峰时段，一旦 APP 或小程序出现故障导致服务中断，将会对业务产生较大影响。基于业务连续性的考量，2022 年，麦当劳中国启动了 BCP 项目，这也是麦当劳中国构建 IT 基础架构时非常重要的核心内容。而在 BCP 项目中，最核心的就是保障用户数据和业务数据的完整性——即便在机房级别故障的情况下，核心业务仍能正常运行。

麦当劳中国率先组建了一个由测试、研发和运维人员组成的 BCP 项目团队，而数据库正是整个项目最关键的一环。团队采用了 TiDB 分布式数据库，并投入了近一年的时间，对 TiDB 的 BCP 方案进行了全面而深入的调研，最终成功完成了 TiDB 的 3AZ 改造，将原有的单中心架构升级为三中心架构。

据麦当劳中国 IT 团队介绍，本次改造的范围包括麦当劳点餐主流程中的所有核心系统，如会员、积分、订单和卡券等。

通过监控数据发现， 改造后的数据库平均 响应时间 比单中心架构下减少了约 20%，系统性能提升了 30%-50%。此外，改造完成后，数据库集群的容灾能力大幅提升，业务恢复时间明显缩短。 在过去的单中心架构下，如果发生机房级别的故障，业务将完全不可用；而在三中心架构下，即使任何一个机房发生故障，数据库可能在 10 分钟内就完成了业务恢复，整个业务系统在半小时内即可恢复正常服务，极大地提升了业务连续性。

五花八门的架构方案，应该怎么选？

在多中心改造过程中，数据库的 CAP（一致性、可用性、分区容错性 ）是重中之重。 为确保找到更适合自身业务场景的技术方案，麦当劳中国的项目团队从 2022 年 5 月开始对 TiDB 的 BCP 方案进行调研，期间开展了多轮的测试和 POC(Proof of Concept，概念验证) 实践，并根据结果持续优化和调整方案。

在调研初期，团队重点考察了四种架构方案：

三中心单集群方案 ： TiDB 使用 Raft 协议作为共识机制，与三数据中心架构兼容性极佳。集群跨三个数据中心部署，每个中心都可对外提供读写服务。即使任一中心故障，系统仍能正常运行，且数据一致性不受影响。