百度红包架构分析与推测

百度红包架构分析与推测

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

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响