Hi there 👋

你好，Blog。

简介 虽然红包雨复杂度低，但是是 C 端典型（或者说少有）的大流量写业务场景，且需要保障资金安全，根据业务形态和宣传资源，QPS 可达数万至数千万不等，可借由方案的推敲和设计一窥 C 端大流量核心场景系统设计的原则，和互联网后端工程师的核心能力模型 —— 大流量高并发下的系统设计和稳定性与容灾保障。 本文不会涉及具体的方案设计，只能泛泛而谈，希望能给读者一些启发。 需求概述 活动期内，每天定时领取红包。 业务价值 通过玩法将用户导量到入口和出口的场景。 比如免登录态参与玩法引导用户注册。比如玩完红包雨后跳转到春节活动主会场引导用户玩其他玩法。比如在聊天玩红包雨提升群聊活跃度。 流量预估 峰值流量取决于入口流量和玩法漏斗转化率，进而取决于： 宣传入口：如春晚口播、全局弹窗、feed 流强插、挂件等，其中最有效的是春晚口播和全局弹窗 用户数量：一般按高峰活跃用户数量估计，如有往年数据可以直接以 DAU 比例计算，如果定向圈人则需考虑圈人比例 是否打散：打散是削峰的关键，需要除以打散时长，一般推崇向前打散 玩法转化：如有往年数据可直接参考，如无则需依赖产品估算各级漏斗转化率给口径 流量预估会进行多次，一般是需求评审后 RD 会拍个粗估的峰值去做技术方案，开发期间 RD 和产品经过多轮讨论才能给出细化的预估，最终会通过演练场次算出精确的流量预估。此外对于红包雨这种玩法，在初期是无法确定真实的流量范围的，是否有春晚口播、是否使用全局弹窗，这些都不是前期能定下来的，所以初期技术方案设计上得按高估计。 不过如果产品往年做过类似玩法，可以参考往年数据进行粗估。 如有春晚口播，初期流量预估可以直接按该玩法普通导流方式的流量乘以十倍。 技术方案 技术挑战 大流量与高并发 应对挑战： 开始时会瞬间涌入大量用户 配置下发、玩法产生大量请求，对机房带宽产生压力 与秒杀不同，红包雨需要尽量保证用户能领取到奖励，大量请求能走完领奖的完整流程 解决方案： 入口打散 减少网络交互，接口简单 限流 提前建连保活 稳定性与容灾 应对挑战： 高并发下的玩法体验，保证服务稳定性 故障时的快速止损，恢复玩法体验 解决方案： 简化玩法，链路尽可能短，强依赖尽可能少 合理的重试、超时、限流配置 热备异构存储，设计合理的存储一致性维护方案 资金安全保障 应对挑战： 预算充足时正常发放，预算不足时发放兜底 每个用户的奖励需由策略算出，不能提前拆红包 保证各种情况下，不超发 解决方案： 合理设计预算控制模块抗超高流量的预算检查和扣除 梳理各种异常情况的兜底表现 幂等入账 对账、熔断、一致性校验 决策分歧点 附加需求 不展开 边缘机房 or 核心机房 机房分为核心机房和边缘机房，流量一般由边缘机房流向核心机房，边缘机房的特点是离用户更近，带宽承载能力更强，基础设施建设相对不完善。 选择流量终结在边缘机房的原因可能是： 极高稳定性和延迟要求 不希望超高流量打到核心机房影响核心业务 边缘机房到核心机房的带宽建设不足，可能无法承载超高流量 物理机 or 容器 在极端性能敏感或极致服务设计的情况下可以使用物理机，物理机的好处是：...