一、微信红包的业务挑战
2014年微信红包上线后，面临两大核心复杂度：
- 质量复杂度：高并发场景下的性能压力
- 峰值指标：单秒2.5万红包被拆、50万次抢红包操作、25万次查看记录
- 核心矛盾：TPS（每秒事务数）与QPS（每秒查询数）的爆发式增长
- 业务复杂度：资金流转、实时性、数据一致性要求
二、高性能架构设计拆解
通过计算高性能与存储高性能两大方向破局：
1. 发红包模块
- 存储设计：分库分表（Sharding-JDBC）+ 关系型数据库（MySQL）
- 负载均衡：Nginx轮询/随机分发请求
- 关键决策：不拆分服务，直接通过数据库分片横向扩展
2. 抢红包模块
- 缓存层：Redis Cluster存储领取记录（Hash结构）
- 削峰设计：Redis List缓存红包池，LPop/RPush实现原子操作
- 技术选型：放弃纯数据库方案，通过内存数据库扛住瞬时流量
3. 看红包模块
- 复用抢红包的Redis集群，通过缓存降低数据库压力
- QPS依赖TPS业务设计，实现读写分离
三、成本约束下的架构博弈
当老板要求从1000台服务器降本时，架构师需权衡：
图片
经典取舍案例：抢红包模块坚持使用Redis Cluster，虽增加运维成本，但保障了除夕夜千万级并发下的稳定性。
四、架构师必备思维
- 性能公式：性能=资源效率×数量 ↔ 成本=资源单价×数量
- 决策方法论：
- 自顶向下分析业务指标，自底向上验证技术方案
- 独立服务 vs 业务耦合：微信红包最终作为支付子系统存在
- 反常识认知：
- 每天1亿请求不一定是高性能（关键在峰值而非总量）
- 服务拆分未必提升性能（可能增加通信损耗）
随堂思考
- 为什么微信红包实际架构可能比课程方案更复杂？（提示：资金安全、异地多活、灰度发布等生产级需求）
- 如果让你设计2025年的红包系统，会加入哪些新技术？
图片
