1. 美团数据库高可用系统 张洪

2. 个人介绍 2018--2020：负责到店&金融DBA团队，数据库高可用系统 2020--至今：负责数据库高可用系统，数据库访问中间件， 数据迁移平台，测试数据隔离等生态工具建设

3. 主要内容 1、高可用简介 2、高可用部署 3、重点模块设计 4、未来思考

4. 面临挑战 实例增长越来越快 RTO要求越来越严 容灾场景越来越复杂，常规容灾（软件、硬件、网络）、AZ容灾、Region容灾 容灾能力等级 容灾能力建设标准 容灾规模（集 群数） <100 容灾能力水平（可用性 优先） 单服务RTO<1分钟 容灾能力水平（一致性 优先） 单服务RPO<1分钟 L3 具备AZ级容灾能力 <4000 整AZ宕机RTO<5分钟 整AZ宕机RPO=0 具备大型AZ宕机全链 路可观测能力 关键点：1. 容灾场景：跨Region专线故障情况下的整AZ宕机；2. 高可用全链路实现隔离，支持动态扩展 批量兜底RTO<10分 钟 L4 具备跨Region容灾能 力并实现Region级故 障处理全链路闭环 <6000 整AZ宕机RTO<5分钟 整AZ宕机RTO<5分钟 批量兜底RTO<60分 钟 L0 L1 L2 容灾能力水平（可观 容灾能力水平（容错 测性） 兜底） 具备单集群容灾能力 具备单服务切换平台 单服务兜底RTO<5 但未经演练验证 化和可观测能力 分钟 具备单集群容灾能力 <500 单服务RTO<1分钟 单服务RPO<1分钟 具备批量切换平台化 批量兜底RTO<5分 并实现平台化演练 和可观测能力 钟 具备大规模容灾能力 <2000 单服务RTO<30秒 单服务RPO=0 具备大规模批量切换 批量兜底RTO<10分 并实现常态化演练 全链路可观测能力 钟 关键点：1. 容灾场景：整AZ宕机，网络异常等；2. 容灾规模：具备处理大规模AZ宕机能力；3. 可观测性：全链路可视化 具备全链路管控和全 视角的可观测能力

5. 发展历程 -2015 年 ， MMM （ Master-Master 2017-2019 年 ， MMHA （ MySQL Master 2019年-，分布式高可用（基于Orchestrator）， replication manager for manager、agent架构： High Availability），manager集中式架构： ① 解决了VIP接入的问题 分布式架构： ① Raft group多机房部署 ① VIP接入，无法支持跨机房、网段 ② 无需维护agent节点，误判问题解决 ② 统一托管主从所有实例 ② Agent维护困难，无高可用，容易误判 ③ manager单点，性能差、无自身高可用 ③ 高性能、大规模并发处理 MySQL ） ， ③ manager单点，无法解决机房级高可用 随着业务体量增长及场景复杂度的增加，先后经历三次大的系统迭代 MMM 2015 MMHA 2017 分布式高可用 2019 新一代去中心化架构 2023

6. 主要内容 1、高可用简介 2、高可用部署 3、重点模块设计 4、未来思考

7. 高可用架构 业务访问流程 高可用控制流程

8. 高可用部署 HA core：多Region、多AZ、多集群部署，单集群托管MySQL实例千级别 微服务：同步、任务调度服务均多Region、多机房部署，配置中心双Region部署 数据层：MGR集群多Region多机房部署，单Region写、多Region读

9. 主要内容 1、高可用简介 2、高可用部署 3、重点模块设计 4、未来思考

10. 故障发现 减少漏判、降低误判 故障探测：独立多通道，主要以服务端为主，业务端上数据计划中 故障协商：Raft多节点，每个节点独立探测，Leader节点发起协商和决策 以心跳故障为例 • • • 所有节点独立探 测和分析 Leader发起故 障协商 所有节点达成故 障共识

11. 故障选举 选举因子+选举策略=决定谁是新主 选举因子：影响选举的核心因素 选举策略：同机房优先->同中心优先->同区域优先

12. 故障选举 选举因子影响 例如：S2一票否决；S1是同AZ，比S3S4优先；S4权重100，比S3优先级高 实例 promotion rule 自定义权重 AZ 服务器类型 CPU核数 M / / AZ1 / / S1 prefer 90 AZ1 独享容器 32 S2 must not 100 AZ1 共享容器 16 S3 prefer not 90 AZ2 物理机 48 S4 prefer 100 AZ2 独享容器 48 …..

13. 数据一致性 为什么要数据一致性？为什么出现一致性问题？ 风险1：主库数据未实时落盘 风险2：从库IO线程未拿到最 新数据 风险3：从库SQL线程未执行 完IO线程拿到的所有数据 风险4：符合最优选择的从库 不是数据最新从库 其他：不完整的事务数据对一 致性的影响

14. 数据一致性 问题3、4--->复制补数据-- ->S1 问题2--->重放老主库未传 递的差异事务--->S2 S1+S2是否可以保证0 RPO？

15. 数据一致性 S3：基于Ripple的一致性方案 Ripple：保证数据完全 • 高性能 • 强一致 • 存算分离 HA：保证数据完整 • 全托管 • 可定制 • RPO≈0 Ripple+HA的一致性方案，比IO thread+SQL thread的一致性保证更灵活，更可控

16. 数据一致性 可用性优先：可根据业务特性自定义，承诺RTO不保证RPO 一致性优先：可根据业务特性自定义，保RPO但不会无限制，RTO会控制上限 不可控因素：事务大小、延迟、事务完整性等 S1：策略一 分类 可用性优 先 一致性优 先 S2：策略二 S3：策略三 策略套餐 容灾能力水平 总耗时 上限 S1耗时上限 是否开启 事务数量 上限 S2耗时上限 S3耗时上限 通用-A1 优先保证RTO - - - - - - 业务模版-A 取决于实际配 置项 可配置 可配置 开启 / 关 闭 可配置 可配置 可配置 通用-C1 优先保证RPO - - - - - - 业务模版-C 取决于实际配 置项 可配置 可配置 开启 / 关 闭 可配置 可配置 可配置

17. 多机房高可用 常规场景：Leader故障 ---> 快速选举新的Leader继续工作 机房宕机：Leader跟Master同机房 ---> 新Leader如何处理？

18. 多机房高可用 保证多节点状态机连续性： 状态同步：leader实时将状态机同步到所有的follower节点 临界状态：根据执行代价确定的状态机临界点 回滚：新leader执行状态机回滚，包括对应的操作 继续：新leader继续执行老leader状态机

19. 配置下发 同Region下发 跨Reion下发 ① 写入到存储层 ① 同步服务获取最新配置 ② Config-server更新最新配置 ② 配置推送到异地一致性服务 ③ 配置推送到客户端 ③ 走同Region下发流程

20. 主要内容 1、高可用简介 2、高可用部署 3、重点模块设计 4、未来思考

21. 未来思考 一、提升容灾能力 AZ级容灾 VS Region级容灾 二、去中心化架构 内置Proxy VS 内置MySQL 三、去依赖、集群化 元数据配置中心同步 VS 元数据Raft 同步

22. Q&A

23. 更多技术干货 欢迎关注“美团技术团队” 微信扫码 了解美团招聘岗位