PaxosStore在微信支付业务的实践 郑建军

1. PaxosStore 在微信支付业务的实践 郑建军(Rock Zheng) 腾讯高级工程师
3. 郑建军(Rock Zheng) • 腾讯高级工程师,负责微信基础存储的研发。 2014年加入微信后台团队,参与了多个大型 分布式系统的架构设计和研发工作,其中作 为微信核心存储 PaxosStore 主创人员之一, 对微信核心存储系统(消息、朋友圈、好友 关系链等)进行升级改造,提升了服务的可 用性和数据的安全性。
4. • 问题与挑战 • 微信支付业务的解决方案 • 远距离容灾的高可靠存储设计 • 未来规划
5. 数据业务背景与挑战 • 十亿级用户、百亿千亿级服务 • 支撑微信账号/消息/朋友圈/通讯录… • 每天数万亿的读写量、峰值1亿+/秒 • 开放平台,支付等业务持续增长 • 2015年,除夕不眠夜,VPN修数据
6. PaxosStore简介 • PaxosStore是什么? 基于Paxos协议在园区数据中心间同步复制,提供灵活的数据模型和访问接口,支持亿 行大表,并具备快速伸缩能力,低延迟低成本,强一致和高可用的分布式数据库系统。 • PaxosStore特点: • 无租约多主多写,可用性高达6个9的水平; • 针对业务和架构特点进行优化,整体成本降低15+%; • 同一容灾、迁移框架下,支持多种数据模型(例如亿行大表); • 基于反馈的自适应迁移系统,提供快速伸缩的能力。
7. PaxosStore简介:整体架构图
8. 数据模型的多样性 • 业务需求:分析、提炼、抽象 • 提供必要的功能接口
9. 可用性的级别不断被抬高
10. 微信支付业务 • 远距离跨省容灾(华南、华东、华北) • 实时结算低延迟的要求 • PaxosStore取代同城MySQL • 强一致、高可用、低延迟、快速伸缩……
11. • 问题与挑战 • 微信支付业务的解决方案 • 远距离容灾的高可靠存储设计 • 未来规划
12. 余额需求 • 经典案例:商户余额账户 • 操作流水入库,不重不漏 • 数据保证一条不丢 • 业务逻辑与存储平台解耦
13. 限额需求 • 场景:支付限额、支付次数 • 维度:微信用户、银行卡、身份证 • 普通接口:直接加减额度 • 2PC:预加减、成功、撤销
14. 数据结构抽象
15. 数据结构上的操作 • 提供具体的接口 • 基本操作组合 • 提供两阶段(2PC)支持 • Prepare/Commit/Roll Back
16. 数据保证一条不丢 • MySQL主备同步缺陷(异步同步)
17. 数据保证一条不丢 • MySQL主备同步缺陷(半同步) 思考题:假设不存 在脑裂的情况下, 如何做到强一致?
18. 数据保证一条不丢 • Paxos:Indeed, all working protocols for asynchronous consensus we have so far encountered have Paxos at their core. ----- Chubby • 世上只有一种一致性协议,那就是Paxos。 Paxos
19. 数据保证一条不丢 • Why not NRW(QuorumKV)? • Vr + Vw > V,Vw > V/2 • 保证强一致情况下:可用性低
20. 数据保证一条不丢 • 数据副本之间对齐 • 变更日志实时CRC校验 • 数据副本损坏探测
21. 操作流水订阅需求 • 不重不漏、满足多订阅需求(对账、查询、分析等)
22. 如何获得操作流水推送到队列 • 操作流水不重不漏 • 一般可容忍少量重,但不能接受漏 • Log文件删除时剥离LSM引擎 • 异步推送,不影响实时任务 • 每个Paxos Group实例维护同步版本
23. 解决方案要点总结 • 基于树结构的基本操作组合 • 低耦合、支持业务快速开发 • 数据保证一条不丢 • PaxosStore的强一致同步代替MySQL的主备同步 • 一些额外措施(数据对齐、实时校验、损坏探测) • 操作流水入库 • 不重不漏、支持多订阅需求
24. • 问题与挑战 • 微信支付业务的解决方案 • 远距离容灾的高可靠存储设计 • 未来规划
25. 什么是远距离容灾存储? • 强一致 vs 最终一致 • 数据重要性 vs 用户体验 vs 对账修复成本 • 三地 vs 两地
26. PaxosStore跨园区容灾模式 • 伸缩:按Set隔离、一致性哈希 • 容灾:数据三园区分布 • 存储:单机作为数据副本节点
27. 直接升级为跨城容灾模式 • 运营系统不成熟 • 单机故障危害放大(园区间延迟1~4ms,城市间延迟约30ms) 跨园区容灾 跨城容灾
28. 跨城容灾存储架构目标 • 数据在城市间强一致同步复制 • 拥有成熟稳定的运营系统 • 写请求通常只需要一次跨城RTT延迟 • 读请求支持本城读 • Paxos是最优选择 • 复用跨园区模式的系统 • 避免单机故障抖动影响 • 常量服务(终态直接应答)
29. 以单机作为副本节点的分层结构
30. 逻辑层与存储引擎分离 • 计算存储分离? PaxosStore集群 (StringKV)
31. 逻辑层与存储引擎分离 • 复用跨园区容灾模式下的基础设施(迁移、冷备、路由中心) • 城市数据中心内自治 • 3个副本 => 9个副本 • 天津IDC采用见证者模式 • 9个副本 => 6个副本
32. 逻辑与存储引擎分离 • 无状态逻辑服务(抢占式操作数据) • 存储引擎服务提供CAS接口 • 区别于基于分布式锁的架构 • 锁租约时长一般为10s~1min BigTable(基于分布式锁的架构)
33. 跨城容灾存储整体架构 • StringKV:Key-Value数据模型的PaxosStore存储服务 • CityReplSvr:无状态服务群、复用PaxosStore同步复制组件的核心逻辑
34. 用户请求路由 • Client优先访问本城CityReplSvr服务 • 本城发起提议:保证在一个跨城RTT内完成协议交互 • 路由规则采用一致性哈希算法
35. 如何在一个跨城RTT时间内完成两阶段? • Paxos两阶段协议 • Prepare + Accept • Multi-Paxos优化 • 不存在稳定的提议者
36. 如何在一个跨城RTT时间内完成两阶段? • 三数据副本特性:本地 + 对机 = 多数派 • 本地先Promised,携带Value广播Prepare请求
37. 远距离容灾设计要点总结 • 逻辑与存储引擎分离 • 逻辑层抢占式操作数据,不存在切换等待 • 城市数据中心内自治 • 迁移(伸缩)、冷备、路由中心 • 基于三副本的Paxos协议优化 • 写请求通常只需要一次跨城RTT延迟
38. • 问题与挑战 • 微信支付业务的解决方案 • 远距离容灾的高可靠存储设计 • 未来规划
39. 未来规划 • 全面替换MySQL • 升级到类Spanner架构的系统