微信产品经理和架构师们是靠什么扛住了10亿个红包？.pdfVIP

微信产品经理和架构师们是靠什么扛住了10亿个红包 ？ Nancy导读 ：微信这么大的流量 尤其是瞬间的峰值 对于任何团队和架构师都是一个极大 的挑战 我们也在想 微信团队会用什么样的办法扛住了抢红包的流量 ？ 微信这么大的流量 ，尤其是瞬间的峰值 ，对于任何团队和架构师都是一个极大的挑 ，我们也 在想 ，微信团队会用什么样的办法扛住了抢红包的流量 ，正巧今天腾讯大讲堂的公共账号就分发出 了这篇文章 ，尽管没有从具体的技术细节上介绍 ，但在宏观策略上还是相当地有学习的价值,分享给 大家。 4 00倍的挑 今年微信红包方式与去年用户与用户之间互发红包相比 摇红包的方式对业务量来说是一个极大的 爆发 光是除夕10 ：30送出的一波红包就达到了1.2亿个 已经是2014年除夕夜峰值的4 00倍之 巨 （2014年峰值每分钟被拆开红包数量仅2.5W个 ）！ 进入抢红包环节 后台数据瞬间飙升 发10亿红包 ，难在哪里 ？ 微信团队总结下来有三大难点 ： 快——如何保证用户快速摇到红包 ？ 准——如何保证摇到的红包能成功拆开 ？ 稳——如何保证拆开的红包能分享出去 ？ 大量用户在同一时间摇红包 瞬间产生每秒千万级的请求 这个量级的请求如果不加以疏导处理直 接到达后台 必定会导致后端服务过载甚至崩溃。上文中除夕当天后台监控数据曲线便能说明一 切——在前台重重的分流减压下 后台服务器负载仍然瞬间飙升十倍以上。 三大应对策略齐上阵 对于以上三个难点 微信后台开发团队主要通过三大应对策略应对 ：有损服务 ，柔性可用 ，大系统 小做 有损服务-追求高可用和快速响应。 什么是有损服务 ？有损服务是通过精心拆分产品流程 选择性牺牲一部分数据一致性和完整性从而 保证核心功能绝大多数运行。这是腾讯在PC时代积累下来的一种特色运营策略——在资源一定的前 提下 互联网条件千变万化的场景中 量力而为 满足用户的核心需求。 微信红包的核心点是摇 拆 分享红包 整个系统设计时必须尽最大可能保证这三个步骤一气呵成 任何关联系统出现异常的时候马上进行系统降级 防止引起系统雪崩。 系统降级可以分为两个方面 一是把核心功能进行分拆和简化 通过辅助轻量化的服务实现 确保 最短关键路径的可行 比方说在接入层置入摇红包逻辑 将每秒千万级请求转化为每秒万级的红包 请求 再传到红包服务的后端逻辑 降低雪崩的可能性。 点评 ：有损服务就是让重要的事情先做 重要的人物先行。这在现实中也很常见 军人买票优先 领导视察封路 让领导车先行 我等小民等待也是这个路子。 同时后端采用异步分拆 接收到用户请求时仅进行合法性验证 验证完成后直接告知成功 后续业 务逻辑进入异步队列进行处理 减少了用户的等待时间 也极大降低了峰值雪崩的概率。 耗时最长的入账操作 直接跳过 异步处理 另外一方面是采取过载保护措施 ： 微信红包的过载保护在客户端已提前预埋了策略 在连接失败或超时情况下会有相应提示 减少用 户重复请求次数。接入层面也会进行自我保护 针对频繁发出请求的客户端限制响应速度 并对系 统负载划分出若干等级 达到不同阈值时引导客户端使用不同限速速率 ；在异常情况出现时 采取 减少红包数 异步限流降低拆/分享红包的速率等措施减轻服务器端压力 ；与此同时 微信红包还有 全程压测流程 对整个业务链接进行自动提前评估 防止过载。 点评 ：在前端挡住对后端流量的进入 比如出现通信失败时 当前这个用户 对后台已经不会有什 么压力了。 这画面你可能没见过 它其实早已在手机待命 在有损服务思想的重重保护下 第一波的摇红包体验活动中 微信红包几乎满分通过考验 其中过 载保护的作用相当明显 在客户端、接入层层减压、过滤 最终仅把十万级压力传递到后台。 柔性可用-细化场景把握核心需求。 柔性可用是在有损服务价值观支持下的方法 重点在于实际上会结合用户使用场景 根据资源消耗 调整产品策略 设计几个级别不同的用户体验场景 保证尽可能成功返回关键数据 并正常接受 请求 绝不轻易倒下。 柔性服务更具有产品的思维性质 意义在于深刻理解产品每一个场景的核心价值 把握用户在每一 个场景中的核心需求 设计不同层次的满足核心诉求的办法 对柔性服务在微信红包中的实践 红 包团队也有相应的措施 主要可以分为几大类。 1、系统容灾 ：面对大规模的请求量 系统容灾必不可少 容灾一般可分为逻辑层容灾和数据层 容灾 这次微信后台开发团队在容灾布置中采用30%切换的逻辑层方案 即核心服务都能做到最 多1/3服务器出问题的情况下自动容灾切换以保证服务质量