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

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

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

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

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

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

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

1. 發(fā)紅包模塊

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

2. 搶紅包模塊

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

3. 看紅包模塊

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

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

當(dāng)老板要求從1000臺服務(wù)器降本時(shí)，架構(gòu)師需權(quán)衡：

圖片

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

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

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

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

3. 反常識認(rèn)知：

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

隨堂思考

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

圖片