一、微信紅包的業務挑戰

2014年微信紅包上線后，面臨兩大核心復雜度：

1. 質量復雜度：高并發場景下的性能壓力

• 峰值指標：單秒2.5萬紅包被拆、50萬次搶紅包操作、25萬次查看記錄
• 核心矛盾：TPS（每秒事務數）與QPS（每秒查詢數）的爆發式增長

2. 業務復雜度：資金流轉、實時性、數據一致性要求

二、高性能架構設計拆解

通過計算高性能與存儲高性能兩大方向破局：

1. 發紅包模塊

• 存儲設計：分庫分表（Sharding-JDBC）+ 關系型數據庫（MySQL）
• 負載均衡：Nginx輪詢/隨機分發請求
• 關鍵決策：不拆分服務，直接通過數據庫分片橫向擴展

2. 搶紅包模塊

• 緩存層：Redis Cluster存儲領取記錄（Hash結構）
• 削峰設計：Redis List緩存紅包池，LPop/RPush實現原子操作
• 技術選型：放棄純數據庫方案，通過內存數據庫扛住瞬時流量

3. 看紅包模塊

• 復用搶紅包的Redis集群，通過緩存降低數據庫壓力
• QPS依賴TPS業務設計，實現讀寫分離

三、成本約束下的架構博弈

當老板要求從1000臺服務器降本時，架構師需權衡：

圖片

經典取舍案例：搶紅包模塊堅持使用Redis Cluster，雖增加運維成本，但保障了除夕夜千萬級并發下的穩定性。

四、架構師必備思維

1. 性能公式：性能=資源效率×數量 ? 成本=資源單價×數量
2. 決策方法論：

• 自頂向下分析業務指標，自底向上驗證技術方案
• 獨立服務 vs 業務耦合：微信紅包最終作為支付子系統存在

3. 反常識認知：

• 每天1億請求不一定是高性能（關鍵在峰值而非總量）
• 服務拆分未必提升性能（可能增加通信損耗）

隨堂思考

1. 為什么微信紅包實際架構可能比課程方案更復雜？（提示：資金安全、異地多活、灰度發布等生產級需求）
2. 如果讓你設計2025年的紅包系統，會加入哪些新技術？

圖片