一、微信紅包的業(yè)務挑戰(zhàn)

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

1. 質(zhì)量復雜度：高并發(fā)場景下的性能壓力

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

2. 業(yè)務復雜度：資金流轉(zhuǎn)、實時性、數(shù)據(jù)一致性要求

二、高性能架構(gòu)設計拆解

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

1. 發(fā)紅包模塊

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

2. 搶紅包模塊

• 緩存層：Redis Cluster存儲領取記錄（Hash結(jié)構(gòu)）
• 削峰設計：Redis List緩存紅包池，LPop/RPush實現(xiàn)原子操作
• 技術選型：放棄純數(shù)據(jù)庫方案，通過內(nèi)存數(shù)據(jù)庫扛住瞬時流量

3. 看紅包模塊

• 復用搶紅包的Redis集群，通過緩存降低數(shù)據(jù)庫壓力
• QPS依賴TPS業(yè)務設計，實現(xiàn)讀寫分離

三、成本約束下的架構(gòu)博弈

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

圖片

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

四、架構(gòu)師必備思維

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

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

3. 反常識認知：

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

隨堂思考

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

圖片