微信红包系统设计分享 如何扛住100亿次请求？.pdf

微信红包系统设计分享 | 如何扛住100亿次请求？ 春晚摇一摇活动形式 在了解这个系统之前 ，先看看羊年春晚有哪些活动形式？春晚摇一摇复 用了摇一摇入口，但提供了全新的界面和交互内容。 在羊年春晚摇一摇界面里 ，用户摇动手机后 ，可以看到明星拜年、全家 福、好友贺卡等精彩纷呈的活动页 ；也会有温馨的 “休息一下”，或让很多 误以为中奖的 “挂服务器”等特殊用途的页面。 大家最期待的肯定是摇红包 ，摇中红包的幸运用户除了自己领到一份红 包（种子红包）外 ，还可以领到若干份用于分享给其他好友的红包（分裂红 包）。 围绕这些活动，下面将会通过4个处于项目不同阶段的里程碑版本来介 绍我们设计、实现这一系统过程中的一些思考和做法 ，特别是标题里提到的 “有把握”是由何而来。 V0.1原型系统 原型系统很简单 ，但已经基本实现了春晚摇一摇的需求。原型系统的架 构见下图。 相关的处理流程如下： o 用户摇动手机后，客户端产生摇一摇请求，请求发到接入服务后，会被转发到 摇一摇服务； o 摇一摇服务会根据现场节目的流程，经过一系列的逻辑判断，给客户端返回一 个结果：明星拜年、红包或者其他活动； o 假设是摇到了红包，由于红包都是企业赞助的，需要对企业形象进行展示，客 户端会从CDN拉回这个企业的LOGO等资源，最终展示出一个完整的红包 ； o 随后用户拆红包时，请求会进入红包系统，再到支付系统，最后到财付通系统 完成一系列复杂的账务处理，最终拿到红包； o 用户还可以分享红包，被分享的红包通过消息系统发给好友或群，其他人可以 再抢一轮；在这一过程中，安全系统保障红包活动的业务安全。 o 上述数据的流动可以分下类：资源流、信息流、业务流和资金流。本文将主要 聚焦在资源流和信息流。 面临的挑战 原型系统看起来已经足够简单 ，功能也基本完备 ，是不是可以稍加修改 后直接用在春晚现场呢？答案肯定是不行。那么问题来了：为什么不行？ 回答这一问题前，我们先看一下看似简单的活动背后，面临着哪些挑 战？ 海量用户请求，预计请求峰值1000万/秒 1000万/秒究竟是多大的规模，可以通过下图更直观地感受下： 注：抢火车票数据引用自公开数据 春晚全程互动，不确定因素多 这个系统需要跟羊年春晚全程紧密互动 ，从项目开始到结束 ，有一系列 的不确定因素会加大系统实现的复杂度 ：在开发阶段 ，针对节目与活动形式 如何配合这个问题的讨论有可能持续到春晚前 ，如何使系统能服务多变的需 求？在春晚现场 ，节目数量多 ，节目时长甚至顺序都有可能调整 ，如何做到 现场节目与摇一摇活动无缝衔接？ 系统深度定制，成败在此一举 作为专为春晚设计的系统 ，部署上线后真正能运行的时间就只有几个小 时 ，这几个小时内 ，常规系统所提倡的灰度发布、先扛住再优化等做法并不 是太适用。在这短暂的时间内，只有一次机会：要么成功，要么失败。 全民高度关注，必须成功 春晚会有7亿左右的观众 ，大家对这一活动抱有很大期望 ，全民瞩目之 下，只能成功，不能失败。 l缺少历史经验，把握不大 如此大型的活动 ，对我们而言是史无前例的 ，并没有太大的信心。前边 提到的1000万/秒的峰值是如何估算出来？各个环节会有多少用户参与？ 系统需要预留多少资源？这些问题不会有现成的答案，都需要摸索与思考。 可见 ，在看似简单的活动背后 ，隐藏了巨大的挑战 ，之前假设的原型系 统不太可能胜任，需要做更深入的优化。 需要优化哪些环节？比较显而易见的有三个： 流量带宽 春晚摇一摇需要用到大量的多媒体资源 ，这些资源都需要从CDN下载。 经过评估 ，带宽峰值需求是3Tb/s，会带来巨大的带宽压力。即使我们有无 限的资源 ，带宽需求能被满足 ，客户端在摇一摇后下载资源所需的等待时间 也会带来很大的用户体验损害，是不可接受的。 接入质量 接入是后台系统的第一道关 ，所有请求都会到达接入。预计当晚会有3.5 亿的在线 ，如何尽可能保障外网接入质量？甚至在外网波动时也不受太大影 响？ 海量请求 1000万/秒的请求从外网涌进来后 ，都被路由给摇一摇服务 ，也就是说 摇一摇服务也将有1000万/秒的请求量。