前言：
春节的红包大战, 依然硝烟未散, 姑且不谈微信和支付宝谁是最后的大赢家. 让我们谈谈技术, 承接上一篇文章浅谈接龙红包的技术实现, 这次让我们尝试探究下秒杀型红包的技术实现. 假如我们是腾讯的工程师，我们会如何架构和实现微信摇一摇红包这个项目.
本文参考了"谈谈微信红包海量运营--发10亿个红包难在哪里？", "Web系统大规模并发——电商秒杀与抢购", 但还是按自己的理解去架构和实现该项目.
电商秒杀:
摇一摇红包本质上属于秒杀型抢购类型, 因此让我们来先谈一谈传统的"秒杀"技术.
秒杀有多种类别, 各有各的侧重点, 但其共同点也很突出, 那就是瞬间并发量大.
一般的策略是, CDN+复杂业务异步化.
注: 图片来自"Web系统大规模并发——电商秒杀与抢购".
自己造的轮子：
微信摇一摇属于秒杀/抢购的范畴, 但比传统的秒杀/抢购要简化. 借用<<阿甘正传>>的名言: 人生就像巧克力, 你永远不知道下一颗的味道. 微信摇一摇切合了"摇"这种不确定的淘红包思路, 比天猫双11的明确物品的秒杀/抢购, 其背后可操作的余地多了很多.
微信红包: 其基本属性由广告商和钱数这两个属性组成.
其设计的基本思想:
1). 红包独立拆分
红包池拆分为多个子集, 每个子集互相独立, 互不影响.
2). 强调有损服务
服务有降级预案, 能削平流量高峰和具备防作弊功能
3). 以时间换体验
延长时间, 让更多的人能参与, 同时平滑对后台服务的压力
要实现之上的目标, 该如何去设计?
先呈现整体的架构, 再慢慢细讲:
从图中我们可以看到, 一次成功的摇红包请求, 经过红包分配模块, 红包拆分模块, 把红包结果放入消息队列服务, 再返回给用户.
整个架构由调度/计数服务, 红包分配模块, 以及红包拆分模块这三个核心部分组成.
1).红包拆分模块
该模块的作用, 对红包池(广告商+红包总金额)进行拆分为具体的红包(比如, 苏宁易购:10块, 京东商城:11块)
为了提高性能, 做了如下优化工作:
*) 全内存存储和计算, 借鉴redis的实现方式，事件驱动+单线程工作模型(减少因线程切换、加锁导致的CPU消耗).
*) 每个节点数据彼此隔离, 同时预先分配加载红包池(广告商+红包总金额).
按照redis的性能数据: 读请求10万QPS级别 (具体取决于请求响应包大小 和 机器网卡带宽限制).
单个节点的服务能力为10万QPS级别, 若拆分32个独立节点 则集群的服务能力为320万QPS.
2). 红包分配模块
该模块的作用, 获取红包并赋予玩家, 并提交微信钱包服务(间接通过消息队列服务, 服务解耦的思想).
除了完成主逻辑功能,该模块需具备流量控制和反作弊功能.
流量控制策略:
*) 按分钟配额来发放红包
*) 按配额/峰值的概率来划定, 小于则处理请求, 其余按空响应返回.
这种流量控制, 大大提高了服务的高可用性. 该模块为无状态节点, 很方便扩机器进行水平扩展.
3). 调度/计数模块
该模块的作用, 用于调度和简单计数(粗粒度统计).
用于水平扩展红包拆分节点, 同时计算分钟配额给红包分配模块.
该模块可以为单点模块, 请求压力小. 集群中,每个节点每秒汇报自己的状态给它, 由它来汇总计数器和分配配额.
削平峰值流量, 采用按概率拒绝服务, 从接入层做起(实际上客户端也做了限流控制). 流量逐层递减, 保证服务的压力在可控范围内.
服务降级, 能容忍部分服务节点的宕机, 具备服务的切换和功能开关能力.
时间换体验, 有平滑后端服务压力的考量, 但更多的是, 让更多的用户能参与和延长体验时间这个本质的需求.
最后, 我想说的是, 一个产品的好坏, 不在于技术架构, 而在于策划和运营.
我研究生有个同学, 他去网易游戏面试的时候曾问道: "对于游戏外挂, 贵公司有没有什么好的技术方案?" 对方的回答是:"没有特别好的技术方案, 重要的是从游戏策划的角度尽可能地减少外挂出现的可能性".
总结:
这边谈了谈个人的认识和看法, 但毕竟没有实际的电商项目经历. 惶恐有不对的地方, 请轻拍. 欢迎交流和探讨.
写在最后：
如果你觉得这篇文章对你有帮助, 请小小打赏下. 其实我想试试, 看看写博客能否给自己带来一点小小的收益. 无论多少, 都是对楼主一种由衷的肯定.
