腾讯高级工程师 方乐明 - 微信红包后台系统可用性设计实践
2020-02-27 1457浏览
- 1.微信红包系统可用性设计实践 michaelfang
- 2.
- 3.微信红包介绍 红包印象
- 4.红包印象 – 产品形态 • 包红包 （支付） •发 •抢 •拆
- 5.红包印象 - 微信支付与微信红包 1. 发起支付 微信红包系统 3. 拉起客户端收银台 2. 预下单 6. 通知商户 订单成功 4. 选择：支付渠道 微信支付 服务器 5. 快捷 支付扣款 XX 银行 微信红包前端 微信客户端 支付过程
- 6.微信红包系统可用性设 计实践 1. 微信红包系统介绍 2. 系统可用性影响因素分析 3. 可用性设计方向 4. 红包系统可用性实践
- 7.微信红包的系统流程 包： 生成发红包单 号 写发红包订单 微信支付下单 发： 微信支付 更新发红包订 单 写发放记录 发微信消息 抢： 查发红包订单 拆： 查发红包订单 计算红包金额 写领取订单 更新发红包订 单 写领取记录 转零钱 更新领取单
- 8.微信红包的系统架构 微信统一接入 微信基 础服务 发红包 抢红包 拆红包 查红包详情 查红包列表 业务逻辑 业务逻辑 业务逻辑 异步队列 异构系统 出口 历史数据 接入 历史订单 迁移 订单接入 ... 订单接入 订单 set0 数据分析 订单 setn-1 TDW & 后台工具 对账 订单接入 订单 setn 审计 cache接入 订单cache 用户数据接 入 用户数据 同步 微信 支付
- 9.可用性影响因素 – 计划外 • 系统级故障 • 主机 • 操作系统 • 中间件 • 数据库 • 网络 • 电源以及外围设备 • 数据和中介故障 • 人员误操作 • 硬盘故障 • 数据错乱 • 其他 • 自然灾害 • 人为破坏 • 供电问题 故障无法 避免
- 10.可用性影响因素 – 计划内 • 日常任务 • 备份 • 容量规划 • 用户和安全管理 • 后台批处理应用 • 运维相关 • 数据库维护 • 应用维护 • 中间件维护 • 操作系统维护 • 网络维护 • 升级相关 • 数据库 • 应用 • 中间件 • 操作系统 • 网络 • 硬件升级 通过精心设计方 案可以优化
- 11.可用性设计方向 降低意外故障 影响 平行扩缩容
- 12.降低故障影响 业务逻辑 层 • 部署方案 • 异步化 • 降级与柔性 订单存储 层 • SET化 • DB故障自 愈能力建设
- 13.业务逻辑层 – 部署方案 • 通过部署设计降 低故障影响 • 方案 • 上海深圳两地部 署 • 同城三园区部署 • 容量冗余1/3 • 收益 • 就近接入 • 单机故障不影响 • 单idc故障不影 响 用户群 上海 idc_1 idc_2 idc_3 用户群 深圳 idc_1 跨城 通道 idc_2 idc_3
- 14.业务逻辑层 – 异步化 • 思路 • 最简关键路径 • 快慢分离 • 方案 • 写用户记录、零钱入账使用MQ异步执行 • 增加对账机制保障最终一致 发： 微信支付 更新发红包订 单 写发放记录 发微信消息 MQ 写发放记录 拆： 查发红包订单 计算红包金额 写领取订单 更新发红包订 单 写领取记录 MQ 转零钱 写领取记录 更新领取单 转零钱 更新领取单
- 15.订单存储层 – 早期架构 • 早期架构设计特点 • 订单顺序生成 • 按订单号末三位分 库表 • 多组物理DB均匀 分配库表 • 接所入有层DB共用同一 • 存在问题 • DB连接数问题 • 存储机器故障影响 放大 • 扩缩容问题 单号： 201704160123456789 业务逻辑服务 XX Y 订单 hash 订单 SERVER 订单 SERVER 订单 SERVER 订单 MASTER 订单 SLAVE_0 订单 SLAVE_1 db_00.t_y ~ db_09.t_y 订单 MASTER 订单 SLAVE_0 订单 SLAVE_1 db_10.t_y ~ db_19.t_y 订单 MASTER 订单 SLAVE_0 订单 SLAVE_1 db_90.t_y ~ db_99.t_y
- 16.订单存储层 - SET化 • 设计方案 • 按物理DB机器分 SET • DB接入机按物理 分SET规则路由 • 同一SET中DB接 入机对等，三园 区部署 • 获得可用性提升 • 控制DB连接数 • 隔离故障影响 • 分流并发 单号： 201704160123456789 业务逻辑服务 XX Y xx=00~09 按订单 hash到 SERVER 订单 SERVER 订单 SERVER 订单 SERVER 订单 MASTER 订单 SLAVE_0 订单 SLAVE_1 按订单 划分set xx=10~19 按订单 hash到 SERVER 订单 SERVER 订单 SERVER 订单 SERVER 订单 MASTER 订单 SLAVE_0 订单 SLAVE_1 xx=90~99 按订单 hash到 SERVER 订单 SERVER 订单 SERVER 订单 SERVER 订单 MASTER 订单 SLAVE_0 订单 SLAVE_1
- 17.订单存储层 – 故障自愈 • 方案 • 业务逻辑层写发红包 订单失败，生成另一 个set的订单号重试 • SERVER监控DB失败情 况，单位时间内失败 次数达到预设值直接 报错 • 效果 • 故障后业务自愈 • 新业务无影响 • 已发未拆红包需等待 机器恢复或者过期退 款 订单 SERVER 单号： 201704160123456789 业务逻辑服务 XX Y xx=00~09 按订单 hash到 SERVER 订单 SERVER 订单 SERVER 订单 SERVER 按订单 划分set xx=10~19 按订单 hash到 SERVER 订单 SERVER 订单 SERVER 订单 SERVER xx=90~99 按订单 hash到 SERVER 订单 SERVER 订单 SERVER 订单 MASTER 订单 SLAVE_0 订单 SLAVE_1 订单 MASTER 订单 SLAVE_0 订单 SLAVE_1 订单 MASTER 订单 SLAVE_0 订单 SLAVE_1
- 18.平行扩缩容 – 早期方案 4. 发布业务逻辑 版本，使用启用新 SET 按订单 hash到 SERVER 订单 SERVER 订单 SERVER 订单 SERVER 订单 MASTER 订单 SLAVE_0 订单 SLAVE_1 db_00.t_y ~ db_09.t_y 3. 停服等待同步 完成 订单 MASTER 订单 SLAVE_0 订单 SLAVE_1 db_05.t_y ~ db_09.t_y 业务逻辑服务 单号： 201704160123456789 XX Y 按订单 划分set 按订单 hash到 SERVER 2. 搭建新SET的DB 接入层 按订单 hash到 SERVER 订单 SERVER 订单 SERVER 订单 SERVER 订单 SERVER 订单 SERVER 订单 SERVER 1. 搭建新SET，作 为原DB的备机并同 步数据 订单 MASTER 订单 SLAVE_0 订单 SLAVE_1 db_90.t_y ~ db_99.t_y 订单 MASTER 订单 SLAVE_0 订单 SLAVE_1 db_95.t_y ~ db_99.t_y 订单 SERVER 按订单 hash到 SERVER 订单 SERVER 订单 SERVER
- 19.为什么要停服？ • 原因 • 按订单分库表 • 订单中表示逻辑库的空 间用尽 • 扩容时需要迁移数据 • 改进 • 订单中预留三位为物理 机器标识 • 扩容时业务逻辑层新成 落地到新机器的订单号 表示逻辑库，每次被分配完； 理论上00~99可分配100组物理 机器 红包单号： 201704160123456789 XX Y 表示物理机器; 最多可扩容1000组 红包单号： 201704160123456789 XXX Y
- 20.改进后的平行扩容 201704160123456789 XXX Y 业务逻辑服务 2. 逻辑服务开始生 成落到新SET订单 xxx=000 按订单 hash到 SERVER 订单 SERVER 订单 SERVER 订单 SERVER 订单 MASTER 订单 SLAVE_0 订单 SLAVE_1 按订单 划分set xxx=001 按订单 hash到 SERVER 订单 SERVER 订单 SERVER 订单 SERVER 订单 MASTER 订单 SLAVE_0 订单 SLAVE_1 xxx=009 按订单 hash到 SERVER ... 订单 SERVER 订单 SERVER 订单 SERVER 订单 MASTER 订单 SLAVE_0 订单 SLAVE_1 1. 搭建新SET xxx=010 按订单 hash到 SERVER 订单 SERVER 订单 SERVER 订单 SERVER 订单 MASTER 订单 SLAVE_0 订单 SLAVE_1
- 21.Q&A
