简介

虽然红包雨复杂度低，但是是 C 端典型（或者说少有）的大流量写业务场景，且需要保障资金安全，根据业务形态和宣传资源，QPS 可达数万至数千万不等，可借由方案的推敲和设计一窥 C 端大流量核心场景系统设计的原则，和互联网后端工程师的核心能力模型 —— 大流量高并发下的系统设计和稳定性与容灾保障。

本文不会涉及具体的方案设计，只能泛泛而谈，希望能给读者一些启发。

需求概述

活动期内，每天定时领取红包。

业务价值

通过玩法将用户导量到入口和出口的场景。

比如免登录态参与玩法引导用户注册。比如玩完红包雨后跳转到春节活动主会场引导用户玩其他玩法。比如在聊天玩红包雨提升群聊活跃度。

流量预估

峰值流量取决于入口流量和玩法漏斗转化率，进而取决于：

  • 宣传入口：如春晚口播、全局弹窗、feed 流强插、挂件等，其中最有效的是春晚口播和全局弹窗
  • 用户数量：一般按高峰活跃用户数量估计，如有往年数据可以直接以 DAU 比例计算，如果定向圈人则需考虑圈人比例
  • 是否打散：打散是削峰的关键，需要除以打散时长，一般推崇向前打散
  • 玩法转化：如有往年数据可直接参考，如无则需依赖产品估算各级漏斗转化率给口径

流量预估会进行多次，一般是需求评审后 RD 会拍个粗估的峰值去做技术方案，开发期间 RD 和产品经过多轮讨论才能给出细化的预估，最终会通过演练场次算出精确的流量预估。此外对于红包雨这种玩法，在初期是无法确定真实的流量范围的，是否有春晚口播、是否使用全局弹窗，这些都不是前期能定下来的，所以初期技术方案设计上得按高估计。

不过如果产品往年做过类似玩法，可以参考往年数据进行粗估。

如有春晚口播，初期流量预估可以直接按该玩法普通导流方式的流量乘以十倍。

技术方案

技术挑战

大流量与高并发

应对挑战：

  • 开始时会瞬间涌入大量用户
  • 配置下发、玩法产生大量请求，对机房带宽产生压力
  • 与秒杀不同，红包雨需要尽量保证用户能领取到奖励，大量请求能走完领奖的完整流程

解决方案：

  • 入口打散
  • 减少网络交互，接口简单
  • 限流
  • 提前建连保活

稳定性与容灾

应对挑战：

  • 高并发下的玩法体验，保证服务稳定性
  • 故障时的快速止损，恢复玩法体验

解决方案：

  • 简化玩法，链路尽可能短，强依赖尽可能少
  • 合理的重试、超时、限流配置
  • 热备异构存储，设计合理的存储一致性维护方案

资金安全保障

应对挑战：

  • 预算充足时正常发放，预算不足时发放兜底
  • 每个用户的奖励需由策略算出，不能提前拆红包
  • 保证各种情况下，不超发

解决方案：

  • 合理设计预算控制模块抗超高流量的预算检查和扣除
  • 梳理各种异常情况的兜底表现
  • 幂等入账
  • 对账、熔断、一致性校验

决策分歧点

附加需求

不展开

边缘机房 or 核心机房

机房分为核心机房和边缘机房，流量一般由边缘机房流向核心机房，边缘机房的特点是离用户更近，带宽承载能力更强，基础设施建设相对不完善。

选择流量终结在边缘机房的原因可能是：

  • 极高稳定性和延迟要求
  • 不希望超高流量打到核心机房影响核心业务
  • 边缘机房到核心机房的带宽建设不足，可能无法承载超高流量

物理机 or 容器

在极端性能敏感或极致服务设计的情况下可以使用物理机，物理机的好处是：

  • 无容器带来的开销，对 CPU 调度器更友好
  • 无在离线混部、容器超卖的影响，服务更稳定不容易抖动
  • 容易在单机内部署多个进程，做本地基于共享内存的本地调用，省去网络开销
  • 容易实现有状态服务
  • 流量终结在物理机单机，符合超高流量服务的实践经验（关键路径无 RPC / 减少 RPC）

物理机的坏处是：

  • 技术栈相对不通用
  • 一般和有状态服务设计强绑定，无法 scale out
  • 单机丢数据即数据丢失，无法利用底层存储的冗余能力兜底