微信红包订单存储架构变迁的最佳实践-CSDN博客

本文链接：https://blog.csdn.net/joy0921/article/details/80128012

作者：莫晓东，微信支付高级DBA。擅长大规模MySQL数据库的架构、优化和高可用；目前专注于社交支付的存储层运维和架构优化。
责编：仲培艺，关注数据库领域，纠错、寻求报道或者投稿请致邮：zhongpy@csdn.net。
本文为《程序员》原创文章，未经允许不得转载，更多精彩文章请订阅2017年《程序员》

微信红包的由来

南方企业一直有过年找老板“逗利是”的习俗，每年春节后开工的第一天，腾讯大厦都会排上长长的队伍，集体上楼找老板们领红包。按照广东习俗，已经结婚的同事也要给未婚同事发红包，这一天腾讯员工就在春茗和寻找红包中度过。

由此孵化了一个内部项目，通过微信来收发红包，把这个公司全员娱乐活动与最活跃的IM平台微信结合起来。最初这个项目并没有预期对外，但是入口不小心开放后，成为了现象级产品。2014年开始爆发性增长，每年的发放量都是上一年的若干倍。根据腾讯公布的数据，到2016年春节，已经是每秒十万次支付，每天近十亿订单的系统。

微信红包本质是小额资金在用户帐户流转，有发、抢、拆三大步骤。在这个过程中对事务有高要求，所以订单最终要基于传统的RDBMS，这方面是它的强项，最终订单的存储使用互联网行业最通用的MySQL数据库。支持事务、成熟稳定，我们的团队在MySQL上有长期技术积累。但是传统数据库的扩展性有局限，需要通过架构解决。

前端流量控制

发十亿红包，难在哪里？大量用户在同一时间发抢红包，瞬间产生每秒数万次的请求，除夕可能成百千万次；这个量级的请求如果不加以疏导处理直接到达后台，必定会导致后端服务过载甚至崩溃。主要思路是缩短关键业务流程，分离可以通过异步、缓存等方式解决的问题，减轻系统压力，加快响应速度，在存储层前面建上一座大坝。

CGI无状态

接入层无状态，逻辑层也无状态，可以方便地水平扩展。但依赖MySQL事务保证交易完整，保证红包系统的精简，减少瓶颈的存在。

资源静态化

利用腾讯强大的基础资源优化部署，尽量把动态内容转为静态资源。静态资源和CGI分离，静态资源通过CDN就近接入，减少用户和CGI的交互，减少内网、访问延时和数据请求。

业务流程异步化

微信红包的发、抢、拆背后都有多个内部环境，关键流程精简，非关键流程和后续业务逻辑进入异步队列进行处理，减少了用户的等待时间，也极大降低了峰值雪崩的概率。繁多的非关键链路也不会影响到主流程。

过载保护

前端保护后端，能在前端处理，就不传递到后端。前端需要按后端能力做削峰限流；客户端、接入层、逻辑层逐层控制流量；前端更容易容错处理，全力保护存储层。微信的过载保护在客户端已提前预埋了策略，在连接失败或超时情况下会有相应提示，减少用户重复请求次数。接入层针对频繁发出请求的客户端限制响应速度，并对系统负载划分出若干等级，达到不同阈值时引导客户端使用不同限速速率；在异常情况出现时，异步限流降速减轻服务器端压力防止过载。

多级读缓存

发一个群红包，抢红包的请求量远大于发红包，如果已经领过完全可以拒绝。逻辑层增加缓存，类似可以缓存的请求都缓存起来，进一步减少存储层流量。

订单写缓存

订单系统有很多请求不会真正完成全流量，创建这些废单不但浪费存储资源，还会挤占逻辑层和数据层的处理能力，影响其他交易。订单在完成支付前可以先落在缓存中，完成支付后再持久化。

图1 微信支付

存储层的高可用设计

在数百倍千倍的业务增长下，存储层很难简单无限扩容，一方面设备成倍增加的成本巨大，另一方面存储层瓶颈堆积不一定能解决问题。

读写分离

写请求需要在主机上，实时读也需要走主机。有大量对延时不那么敏感，又影响性能的查询，完全可以放到从机。读写分离策略是MySQL分布式的入门，简洁地提高了系统容量。

水平切分

数据的水平切分，实质就是分库分表；选取一张数据表按照主要纬度把数据拆分开。实现存储层的平行扩展。有效降低了单台数据库机器的负载，也减小了服务不可用的可能性。单台数据库宕机只会导致部分数据不能访问。主要需要考虑路由规则的选定，方便扩缩容以及数据的均衡分布。

垂直切分

数据表除了水平切分，行内数据可以按属性进一步分开。核心表只保留最关键的字段，保证数据文件短小紧凑。以红包为例，昵称和祝福语这类较长的信息，不属于核心数据，完全可以切分到别的机器上，进一步提升核心数据库的容量。不同数据适合的存储类型也不一样，这类重复率高的长字符串更适合NoSQL存储，对存储空间和性能都是节约极大。

空间换时间

按不同维度组织表，比如按订单属性和用户属性进行组织；适应不同的请求场景，避免复杂的查询。不同维度的表可以通过对账对齐，非核心表可以适当冗余，减少多次请求。

锁的优化

多人争抢红包通过数据库事物来保证，必然存在竞争MySQL行锁。核心事物必须尽量精简，避免死锁。同一个订单的所有请求，尽量在逻辑层进程预排队后通过一个连接发送请求到数据库。

冷热分离

核心数据库存放高频数据，其他数据可以定时移到成本低的冷数据库中。这样可以为核心数据库使用最好的SSD设备，快速设备容量较小较贵，不可能在全量数据上使用。同时可以保证数据表的容量不会一直积累，大表也会导致性能下降。

图2 双活数据中心架构