行业案例：2个大厂 100亿级 超大流量 红包 架构方案.pdfVIP

2个大厂100亿级超大流量红包架构方案

100亿级红包应用场景

概述

话说每逢双十一节或春节等节假日，对大家来讲是最欢乐的日子，可以在微信群中收发红包，此外今年

微信还推出了面对面红包，让大家拜年时可直接收发，对于用户来讲很爽也很方便。但对于技术架构侧

的考量，这使得微信红包的收发数据成几何倍数上升，处理的复杂度也增加了很多。

2017年微信红包发送量最大的时间段是除夕夜，达到了142亿个。

如此大规模、高并发、高峰值的业务场景，怕是在美帝互联网的技术团队，包括EBay、Amazon等也无

法想象，在这种巨大的流量与并发后面，需要什么样级别的技术架构支撑？

当达百亿级别的资金交易规模时，我们该怎样来保证系统的并发性能和交易安全？

当今中国的互联网平台，有两个场景称得上亿级以上的并发量：

一个是微信的红包，

一个是字节的红包，

都是在一个单位时间达到亿万以以上的请求负载。

百亿级微信红包技术架构

与传统意义上的红包相比，近两年火起来的“红包”，似乎才是如今春节的一大重头戏。历经上千

年时代传承与变迁，春节发红包早已成为历史沉淀的文化习俗，融入了民族的血脉。按照各家公

布的数据，除夕全天微信用户红包总发送量达到80.8亿个，红包峰值收发量为40.9万个/秒。春晚

直播期间讨论春晚的微博达到5191万条，网友互动量达到1.15亿，网友抢微博红包的总次数超过

8亿次。

微信红包在经过15年春晚摇一摇之后，2015年上半年业务量一度呈指数级增长。尤其是微信红包活跃

用户数的大量增长，使得2016除夕跨年红包成为极大挑战。为了应对16年春节可预知的红包海量业

务，红包系统在架构上进行了一系列调整和优化。主要包括异地架构、cache系统优化、拆红包并发策

略优化、存储优化一系列措施，为迎接2016春节红包挑战做好准备。下面介绍最主要的一些思路。

架构

微信用户在国内有深圳、上海两个接入点，习惯性称之为南、北（即深圳为南，上海为北）。用户请求

接入后，不同业务根据业务特性选择部署方式。微信红包在信息流上可以分为订单纬度与用户纬度。

其中订单是贯穿红包发、抢、拆、详情列表等业务的关键信息，属于交易类信息；而用户纬度指的是红

包用户的收红包列表、发红包列表，属于展示类信息。红包系统在架构上，有以下几个方面：

南北分布

1、订单层南北独立体系，数据不同步

用户就近接入，请求发红包时分配订单南北，并在单号打上南北标识。抢红包、拆红包、查红包详情列

表时，接入层根据红包单号上的南北标识将流量分别引到南北系统闭环。根据发红包用户和抢红包用户

的所属地不同，有以下四种情况：

1）深圳用户发红包，深圳用户抢

订单落在深圳，深圳用户抢红包时不需要跨城，在深圳完成闭环。

2）深圳用户发红包，上海用户抢

订单落在深圳，上海用户抢红包，在上海接入后通过专线跨城到深圳，最后在深圳闭环完成抢红包。

3）上海用户发红包，上海用户抢

订单落在上海，上海用户抢红包时不需要跨城，在上海完成闭环。

4）上海用户发红包，深圳用户抢

订单落在上海，深圳用户抢红包，从深圳接入后通过专线跨城到上海，最后在上海闭环完成抢红包。

系统这样设计，好处是南北系统分摊流量，降低系统风险。

2、用户数据写多读少，全量存深圳，异步队列写入，查时一边跨城

用户数据的查询入口，在微信钱包中，隐藏的很深。这决定了用户数据的访问量不会太大，而且也被视

为可旁路的非关键信息，实时性要求不高。因此，只需要在发红包、拆红包时，从订单纬度拆分出用户

数据写入请求，由MQ异步写入深圳。后台将订单与用户进行定时对账保证数据完整性即可。