百度红包架构分析与推测

本文是笔者根据百度今年红包活动运行状况，对于红包内部架构的推测，并非百度具体架构。

2019年百度春晚期间请求量总计在209亿次，其中峰值主要集中在春晚期间四次互动红包活动，预估四次请求总量在160亿次，单次请求量在40亿次。
请求量分布状况假设以标准正态分布计算，超时时间按照3s计算，而整个互动时间大约在2分钟，瞬时最高QPS 1.97 亿次。

CDN加速

百度此次红包的主要形式为应用内直接组件+h5页面+微信小程序。对于cdn要求比较高的地方在于h5页面资源和微信小程序的资源。考虑到第一波参与抢红包用户实际上属于提前缓存好的用户，在第一波之后的应用商店全挂的情况，实际上新用户的涌入并未参与到第一波应用，这时对于cdn服务来说在一定层面上是通过应用商店实现了“服务降级”，实际上从百度app装机量考虑，如果是类似微信第一年红包活动大多数用户首次缓存，则很难应对如此请求量。

从百度云提供的信息来说，百度现在的cdn服务标准单台服务最高50GB，cdn服务一般资源响应在50ms以内。假设单个页面所需要资源在MB级别，按照资源命中70%计算，实际瞬时资源最大请求量应该在TB级别，百度如果要完全承载峰值在CDN加速方面提供的服务器应该需要200台~300台这个级别。

同样也不排除百度在这次活动中使用lvs方案。

网关层

百度使用了自研的网关技术BFE(Baidu Front-End)，基于golang 开发。根据李炳毅在16年公开数据来看，单台服务可以承接50w连接数。目前百度主要还是基于http请求，而单台机器http响应不可能超过百万级别。实际上由于使用golang，在gc方面还是存在一定的压力，虽然百度使用了可控的多线程gc回收机制，取消默认gc机制，而通过线程状态改变主动调用gc回收器。在瞬时大量请求的场景，这种形式的优化实际上并不能正真提高吞吐量，相反在峰值附近还会降低吞吐。不排除百度在这两年间对于gc层面有更细粒度的优化，但总体能承担的连接数应该变化不大。

详细可以参考
go在百度bfe的应用 pdf
go在百度bfe的应用视频

单独考虑此次红包场景来说，由于基于短链接，实际上吞吐量基本应该可以保证在50w。根据峰值计算，实际上需要的机器在400~500台。

服务降级与熔断机制

相较于阿里与腾讯，今年百度最大的提升并不是真正提高了请求的处理效率，而是使用了服务降级和熔断机制。
实际上在今年百度的抢红包峰值有很大概率存在机器不可用状况，由于对于业务流程的优化，在业务层面采用了服务降级和熔断机制的方案，这才得以保证百度此次红包故障无感知。

百度此次的红包前端主要抽取流程如下：

采用这种方案最大的好处在于，实际上后端服务已经处于不可用状态或超时，前端直接显示未抽中红包，但对于用户来说是无感知的，并且对于整体红包分配规则造成的影响非常小。这也是这次百度红包相较于腾讯和阿里红包活动中最大的不同。

服务端的熔断机制相信是这次百度红包重要的背后力量，在很大程度上体现了百度在自动化运维所达成的成就。实际上应对如此流量洪峰必然会有模块出现问题，出现问题之后如果没有熔断机制很容易导致服务雪崩。
从此次红包活动来看，百度应该在内部建立了自己的服务熔断机制和监督机制。对于后端服务，在监督服务发现服务异常之后，主要的策略是快速失败，防止由于失败导致大量重复请求继续涌入，如果服务可用性降低到一定水平，则进行服务熔断。服务熔断后可能造成其他服务请求量增加，有可能会造成其他服务超出负载。因此在监督机制在熔断后，可以自动化服务恢复，保证服务回弹性。

这里来看，百度在自动化运维，服务治理方面已经有了较为成熟的探索与实践。

预分配与缓存

由于红包属于金融相关，必须要求数据一致性，因此在最终数据写入必然要求串行化。不同于阿里和腾讯的红包，百度今年的红包只是单向发放红包，在具体实现方面相较于双向红包，单向红包可以通过预分配和缓存进行优化。

北京时间2月5日凌晨，新年除夕，央视春晚也在互动中发出大量红包。据百度方面发布的信息，作为央视2019春晚独家网络互动平台，百度在今年春晚期间共发出1000万个20.19元的红包，100万个88元红包，10万台小度AI音箱，1万个2019元红包以及若干手气红包。全球观众共同瓜分了9亿现金红包大奖。
http://www.sohu.com/a/293409074_114760

事实上，百度当晚的红包策略是既定策略，每一场根据新闻所述应该每个红包类别数量是固定的。可以根据新闻假定每场有：

250万个 1000个 20.19红包
25万个 88元红包
2.5万个小度AI音箱
0.25万个 2019红包
若干手气红包

假设共有N台机器，每台机器在每一场活动开始前写入数据(50万20.19红包| 5万88元红包| 5千台音箱| 500个2019红包|若干手气红包)，将具体红包标记已占用，写入的数据放入每台机器的内存数据库中。由于数量既定，每台机器可以平均分配各种类型红包的数量是固定的。为了防止红包行为在这种场景下成为手速游戏，因此可以在红包数据库中插入若干空红包。事实上总量在80万条数据在内存数据库，对于资源的占用和响应时间来说都是可控范围之内。而抢红包在后端具体业务流程方面如下：

红包请求是否接受，接受进入2，不接受直接返回错误结果
内存数据库分配红包
红包分配成功，并行执行以下项目
3.1 请求返回结果。
3.2 请求消息队列，同步红包具体分配信息

从根本上来看：

预分配策略本质上是通过hash，将无可避免的串行化平均分配到500台机器上
内存数据库的使用是利用资源增吞吐量，解决吞吐瓶颈
预分配策略遵循最终一致性，通过消息队列完成最终一致

总结

这篇分析到此进入尾声，实际上整个系统的复杂性远比笔者这里分析的更为复杂，由于今年红包提供的形式多变，其中对于AI、音视频分析等都有较高的要求，这里由于笔者能力有限没有进行分析。

对于此次百度红包从整体来看，最大的成功点其实在于业务和技术的结合。事实上，对于服务降级大家的目标都是实现错误无感知，无论是google doc文档的离线合并还是gmail的离线编辑都是这一目标的落地。而百度此次通过巧妙的将错误逻辑简化并且与技术相结合，避免了生硬的错误提示以及使用了预分配策略解决串行化问题，这一点很值得去学习。并且从背后来看，sre的建设同样是保证服务回弹性的基础，如果没有sre的基础，很难保证如此大规模服务的快速恢复，这是百度业务快速拓展的基础。

从架构的角度来看，百度能把涉及到的所有东西都可以串联起来，并且保证了这次服务的平稳，对于百度这个体量来说确实是非常惊人的。虽然百度这几年用屁股做产品，但单从这次红包活动来说，我想说：你大爷终究还是你大爷。

参考：
知乎–BAT春晚发红包，腾讯、阿里连续宕机3年，为何2019年百度挺住了？
《反应式设计模式》罗兰·库恩、布莱恩·哈纳菲、杰米·艾伦
网易新闻–2019春晚红包战报：百度送出9亿现金互动208亿次
百度云–cdn加速服务
百度云–弹性伸缩
百度云–云服务器BBC