微信红包数据架构演变(PPT) [附件下载]

JackJiang · 5 年前

1、内容概述

本次演讲的主题是有关微信红包系统的数据架构摸着石头过河的经历。

微信红包业务从2014年起访问量便呈现指数级增长，体现了移动互联网时代爆发性传播的疯狂。微信红包幕后的运营开发团队一直和飞涨的用户量赛跑，在系统负荷的临界点之前上线解决方案。成功推动微信红包熬过两次春节大战，成长为本行星疑似最大的订单系统。

本次分享为从事技术工作的兄弟们讲解微信红包这个典型互联网业务的后台数据库技术架构演变的过程，微信红包的数据架构从简单到复杂的成长经历以及探索。希望借本次大会和大家交流遇到的问题、拓展数据架构方面的优化思路。

补充说明：本PPT对应的演讲内容已整理成文，详见《社交软件红包技术解密(六)：微信红包系统的存储层架构演进实践》。

2、人物简介

莫晓东：微信支付高级DBA，拥有丰富的数据架构和运维实战经验，擅长大规模MySQL数据库集群的架构、优化和高可用。2010年起在腾讯从事DBA工作，目前专注于微信社交支付的存储层运维和架构优化。

3、相关文章

4、演讲提纲

1）继续使用MySQL
• MySQL支持事物，满足一致性要求。
• 结构化存储，紧凑、连续。
• 支持多索引。
• 部署简单，工具支持。
• 团队技术积累。
• 设备改进。
• 测试先行，实践是检验真理的第一标准。

2）性能优化
• 业务最终一致性，cap、base
      • 允许丢失和对账、异步达成。
• 多层Cache。
      • 定制列表服务，下单前验证预订单。
      • 接入层数据cache，标记红包抢状态。
• 部署优化。
      • 多实例，交错部署。
• MySQL参数优化。
• 系统层参数优化。
• 数据优化。
      • Sharding，水平拆分。
      • 数据冗余，维度拆分。
      • 数据预生成，摇一摇红包预先导入。
      • 字段冗余，减少访问次数。
      • 默认字符集从utf8改latin1。

3）有损服务、柔性可用、大系统小做
• 有损服务:通过精心拆分产品流程，选择性牺牲一部分数据一致性和完整性从而保证核心功能绝大多数运行。核心功能是摇，拆，发。其它模块异常立即降级防止引起雪崩。
• 过载保护，层层过滤、快速拒绝，把千万级别的请求减少到万级，减少DB负载。
• 异步处理，耗时最长的入账操作，直接跳过，异步处理。
• 柔性策略，关闭不重要的功能模块，比如查看收发历史、关闭祝福语。
• 资源隔离，拆分红包DB为50个Set，出现故障只影响1/50。
• 大系统小做，功能单一。逻辑层需要减少模块耦合，存储层也需要多源。
• 故障处理，如果DB故障直接替换空白机器，未领取的红包锁定退款。

4）红包野蛮生长-问题来了
• 红包使用量急剧增长。
      • 拆事务性能瓶颈，高峰抖动。
      • 主从同步压力，对账不及时。
      • 存储容量压力，设备已缩容。
• 需要进行业务重构。
      • 运维和开发处于高负荷状态。
      • 先应付眼前。

5）解决问题:第一阶段，争取时间
• 存储容量不足。
      • 使用InnoDB压缩格式，为冷热分离争取时间。
      • 压缩率订单库44%，用户库57%。
      • 可接受的性能下降10-15%。
• 性能问题。
      • 梳理主机SQL，索引优化、语句优化、请求精简。
      • 高峰期抖动，优化请求时间分布。
      • 新特性如线程池，4k page。
• 主从同步延时。
      • 优化从机SQL。
      • 升级 Percona 5.5，多库同步。

6）解决问题:第二阶段，冷热分离
• 分离依据。
      • 分析数据访问情况占比，实测订单3天内，访问占比98.9%。
• 优化目标。
      • 提高性能，减少现网库表数据量。
      • 节省成本，历史数据使用低成本大容量设备。
• 历史库方案。
      • 按日分表，proxy路由请求。低峰时段搬迁数据，现网只保留7天。
      • 改善性能，从raid10+tokudb迁移到NoRaid+myisam，解决迁移问题和优化查询性能。
暂时解决问题，脱离容量问题，性能稳定性增加。

7）解决问题:第三阶段，必须重构
• 表空间回收困难，现网库删除慢，历史库存储过大。
• 字段过冗余，如果按每月约翻倍的速度增长，到年底是很惊人的。
      • 假设到年底还有6个月，如果2^6=64倍，那到2月份过年2^8=256倍。
      • 目前大约占了20T历史数据，如果几十几百倍，机器数量，业务成本无法承受。
• 性能同样需要优化，拆红包单组DB拆峰值仅仅2000+，预计春节10w峰值，也无法完成任务。
      • 红包系统的性能瓶颈在拆事务上。

8）精简和拆分-容量比想象中更宝贵，按字节计算需求
• 库表重新设计，字段缩减，去冗余。
      • 冗余字段精简。
      • 单号精简。
      • 字段类型精简。
• 按天分表，循环使用。
      • 确保数据单表数据不会无限增长。
      • 用truncate代替delete清理。
• 垂直分表力度更细。
      • 小表性能更佳。
• 主键从单号修改为自增字段。
      • 自增主键减少体积，加速插入速度。
• 不同的内容，不同的存储。
      • 有些内容使用kv更适合。
      • 用户维度迁入列表服务。
      • 扩散读和更依赖cache。
• 个人红包和企业红包分离。
      • 企业红包特有字段去除。

8）性能优化-异步和cache
• 事物优化。
      – 事物语句精简和优化。
      – 入账分布式事务。
      – 提高并发度，请求排队机制。
• 异步化。
      – 异步入账。
      – 异步用户信息。
      – 异步补拆，异步入账。
• 语句优化。
      • 不查不需要的字段。
      • 非核心查询移到从机。
      • 大操作合并查询。
• 先查cache。
      • 通过cache判断能不能抢。
      • 缓存常查询的内容。

9）优化效果
• 单表行数：
      • 千万级别到十万级别。
• 拆性能：
      • 2000/s到6000/s+。
• QPS：
      • 1.5w到6w。
• 为业务快速成长排除了性能瓶颈：
      • 以去年春晚的2倍设备量，支撑今年春晚10倍的处理能力，容量上节省了数百台设备的成本。
      • 元旦实例验证，超过去年春节的量，单机负载小于20%。

10）还存在问题
• 红包系统只部署深圳。
      • 跨城流量高延时。
      • 深圳机架位不足。
• DB宕机后的数据安全
      • 主备切换风险：主备延时，数据不一致。
      • 切换后，数据写脏。
      • 资金风险。

11）春晚准备工作-南北分布
• 挑战。
      – 就近接入。
      – 城域容灾。
• 南北分布设计。
      – 系统切分，相互独立。
      – 流量可调控。
      – 相互容灾。
• 收益。
      – 故障恢复。
      – 流量均衡。
      – 降低时耗。

12）2016年新架构
• 异地多IDC部署。
      • 上海深圳南北分布。
      • 三园区部署。
• 层级结构。
      • 纵向分层。
      • 异步结构。
      • 多set结构。