1. 微信红包系统可用性设计实践 michaelfang

2.

3. 微信红包介绍 红包印象

4. 红包印象 – 产品形态 • 包红包 （支付） • 发 • 抢 • 拆

5. 红包印象 - 微信支付与微信红包 1. 发起支付 微信红包系统 2. 预下单 4. 选择：支付渠道 3. 拉起客户端收银台 微信红包前端 6. 通知商户 订单成功 微信支付 服务器 微信客户端 支付过程 5. 快捷 支付扣款 XX 银行

6. 微信红包系统可用性设 计实践 1. 微信红包系统介绍 2. 系统可用性影响因素分析 3. 可用性设计方向 4. 红包系统可用性实践

7. 微信红包的系统流程 包： 生成发红包单 写发红包订单 微信支付下单 发： 微信支付 更新发红包订 写发放记录 发微信消息 号 单 抢： 查发红包订单 拆： 查发红包订单 计算红包金额 写领取订单 更新发红包订 单 写领取记录 转零钱 更新领取单

8. 微信红包的系统架构 微信统一接入 抢红包 发红包 微信基 础服务 业务逻辑 拆红包 业务逻辑 历史数据 订单接入 接入 历史订单 订单 set0 查红包详情 业务逻辑 异步队列 数据分析 异构系统 出口 订单接入 订单接入 cache接入 用户数据接 入 订单 ... 订单 订单cache 用户数据 setn-1 setn TDW & 后台工具 迁移 查红包列表 对账 审计 同步 微信 支付

9. 可用性影响因素 – 计划外 • 系统级故障 • • • • • • 主机 操作系统 中间件 数据库 网络 电源以及外围设备 • 数据和中介故障 • 人员误操作 • 硬盘故障 • 数据错乱 • 其他 • 自然灾害 • 人为破坏 • 供电问题 故障无法 避免

10. 可用性影响因素 – 计划内 • 日常任务 • • • • • 运维相关 • • • • • • 备份 容量规划 用户和安全管理 后台批处理应用 数据库维护 应用维护 中间件维护 操作系统维护 网络维护 升级相关 • • • • • • 数据库 应用 中间件 操作系统 网络 硬件升级 通过精心设计方 案可以优化

11. 可用性设计方向 降低意外故障 影响 平行扩缩容

12. 降低故障影响 业务逻辑 订单存储 层 层 • 部署方案 • SET化 • 异步化 • DB故障自 • 降级与柔性 愈能力建设

13. 业务逻辑层 – 部署方案 • 通过部署设计降 低故障影响 • 方案 • 上海深圳两地部 署 • 同城三园区部署 • 容量冗余1/3 用户群 上海 • 收益 • 就近接入 • 单机故障不影响 • 单idc故障不影 响 用户群 深圳 idc_1 idc_1 跨城 通道 idc_2 idc_3 idc_2 idc_3

14. 业务逻辑层 – 异步化 • 思路 • 最简关键路径 • 快慢分离 • 方案 • 写用户记录、零钱入账使用MQ异步执行 • 增加对账机制保障最终一致 发： 更新发红包订 单 查发红包订单 计算红包金额 写发放记录 发微信消息 MQ 拆： 微信支付 写发放记录 写领取订单 更新发红包订 单 写领取记录 转零钱 更新领取单 MQ 写领取记录 转零钱 更新领取单

15. 订单存储层 – 早期架构 • 早期架构设计特点 • 订单顺序生成 • 按订单号末三位分 库表 • 多组物理DB均匀 分配库表 • 所有DB共用同一 接入层 单号： 201704160123456789 XX Y 业务逻辑服务 订单 hash 订单 SERVER 订单 SERVER 订单 SERVER • 存在问题 • DB连接数问题 • 存储机器故障影响 放大 • 扩缩容问题 订单 MASTER 订单 MASTER 订单 SLAVE_0 订单 SLAVE_1 db_00.t_y ~ db_09.t_y 订单 SLAVE_0 订单 MASTER 订单 SLAVE_1 db_10.t_y ~ db_19.t_y 订单 SLAVE_0 订单 SLAVE_1 db_90.t_y ~ db_99.t_y

16. 订单存储层 - SET化 • 设计方案 单号： 201704160123456789 • 按物理DB机器分 DB接入机按物理 SET 分SET规则路由 同一SET中DB接 入机对等，三园 区部署 Y 业务逻辑服务 • XX 按订单 划分set • xx=00~09 • 获得可用性提升 • • • 控制DB连接数 隔离故障影响 分流并发 xx=10~19 按订单 hash到 SERVER 订单 SERVER 按订单 hash到 SERVER 订单 SERVER 订单 SERVER 订单 SERVER 按订单 hash到 SERVER 订单 SERVER 订单 MASTER 订单 SLAVE_0 xx=90~99 订单 SERVER 订单 SERVER 订单 SERVER 订单 MASTER 订单 SLAVE_1 订单 SLAVE_0 订单 SERVER 订单 MASTER 订单 SLAVE_1 订单 SLAVE_0 订单 SLAVE_1

17. 订单存储层 – 故障自愈 • 方案 • • • 业务逻辑层写发红包 订单失败，生成另一 个set的订单号重试 SERVER监控DB失败情 况，单位时间内失败 次数达到预设值直接 报错 单号： 201704160123456789 XX Y 业务逻辑服务 效果 按订单 划分set • 故障后业务自愈 • 新业务无影响 • 已发未拆红包需等待 机器恢复或者过期退 款 xx=00~09 xx=10~19 按订单 hash到 SERVER 订单 SERVER 按订单 hash到 SERVER 订单 SERVER 订单 SERVER 订单 SERVER 按订单 hash到 SERVER 订单 SERVER 订单 MASTER 订单 SLAVE_0 xx=90~99 订单 SERVER 订单 SERVER 订单 SERVER 订单 MASTER 订单 SLAVE_1 订单 SLAVE_0 订单 SERVER 订单 MASTER 订单 SLAVE_1 订单 SLAVE_0 订单 SLAVE_1

18. 平行扩缩容 – 早期方案 业务逻辑服务 单号： 201704160123456789 XX Y 4. 发布业务逻辑 版本，使用启用新 SET 按订单 划分set 按订单 hash到 SERVER 订单 SERVER 2. 搭建新SET的DB 接入层 按订单 hash到 SERVER 订单 SERVER 订单 SERVER 订单 SERVER 订单 SERVER 订单 SERVER 按订单 hash到 SERVER 订单 SERVER 订单 SERVER 订单 MASTER db_90.t_y ~ db_99.t_y 订单 MASTER 订单 SLAVE_0 订单 SLAVE_1 订单 SLAVE_0 db_00.t_y ~ db_09.t_y 3. 停服等待同步 完成 订单 SERVER 订单 MASTER 订单 SLAVE_1 订单 SLAVE_0 按订单 hash到 SERVER 订单 SLAVE_1 db_05.t_y ~ db_09.t_y 1. 搭建新SET，作 为原DB的备机并同 步数据 订单 MASTER 订单 SLAVE_0 订单 SLAVE_1 db_95.t_y ~ db_99.t_y 订单 SERVER 订单 SERVER 订单 SERVER

19. 为什么要停服？ • 原因 • 按订单分库表 • 订单中表示逻辑库的空 间用尽 • 扩容时需要迁移数据 表示逻辑库，每次被分配完； 理论上00~99可分配100组物理 机器 红包单号： 201704160123456789 XX Y • 改进 • • 订单中预留三位为物理 机器标识 扩容时业务逻辑层新成 落地到新机器的订单号 表示物理机器; 最多可扩容1000组 红包单号： 201704160123456789 XXX Y

20. 改进后的平行扩容 201704160123456789 XXX Y 2. 逻辑服务开始生 成落到新SET订单 业务逻辑服务 1. 搭建新SET 按订单 划分set xxx=000 按订单 hash到 SERVER 订单 SERVER 按订单 hash到 SERVER 订单 SERVER 订单 SERVER 订单 SERVER 订单 SLAVE_0 订单 SERVER 订单 SLAVE_0 订单 SERVER 订单 SERVER ... 订单 MASTER 订单 SLAVE_1 按订单 hash到 SERVER 按订单 hash到 SERVER 订单 SERVER 订单 MASTER xxx=010 xxx=009 xxx=001 订单 SLAVE_1 订单 SERVER 订单 SERVER 订单 SERVER 订单 MASTER 订单 MASTER 订单 SLAVE_0 订单 SERVER 订单 SLAVE_1 订单 SLAVE_0 订单 SLAVE_1

21. Q&A