微信紅包高性能架構(gòu)復(fù)雜度分析
紅包復(fù)雜度總體分析
圖片
紅包業(yè)務(wù)應(yīng)該屬于質(zhì)量復(fù)雜度
圖片
紅包高性能復(fù)雜度分析
圖片
做性能分析，我們計(jì)算的都是按峰值來計(jì)算，上圖是我們得出的一些數(shù)據(jù)。軟件系統(tǒng)的性能都是用峰值TPS/QPS來衡量的，其時(shí)間單位是秒。
紅包高性能復(fù)雜度應(yīng)對(duì)思路：
對(duì)照復(fù)雜度
圖片
進(jìn)程模型：主從模型、生產(chǎn)者-消費(fèi)者模型、管道模型...
網(wǎng)絡(luò)模型：TCP/IP模型、五層模型、OSI模型...
緩存模型：應(yīng)用程序緩存模型、數(shù)據(jù)庫(kù)緩存模型、內(nèi)存緩存模型...
紅包高性能復(fù)雜度應(yīng)對(duì)思路-發(fā)紅包:
圖片
因?yàn)槟悴皇切麻_發(fā)一個(gè)系統(tǒng)，那進(jìn)程模型、網(wǎng)絡(luò)模型、緩存模型基本都是跑在原有的框架之上，基本不要改，用springboot就用springboot。
存儲(chǔ)模型考慮點(diǎn)是紅包的讀寫業(yè)務(wù)還是比較復(fù)雜的，不是一個(gè)簡(jiǎn)單的查詢模型，所以暫時(shí)用B+樹，B+樹的高度保持平衡，使查找操作效率高，在插入和刪除操作時(shí)性能相對(duì)穩(wěn)定，支持范圍查詢，因?yàn)樗娜~子節(jié)點(diǎn)有序排列
集群方面：計(jì)算高性能 發(fā)紅包是個(gè)簡(jiǎn)單的業(yè)務(wù)，任務(wù)分配就行了。存儲(chǔ)方面，關(guān)系數(shù)據(jù)庫(kù)的分片存儲(chǔ) 一個(gè)數(shù)據(jù)庫(kù)支持2.5萬個(gè)紅包， 還是比較吃力的。
發(fā)紅包架構(gòu)圖：
圖片
上面是一個(gè)初步的架構(gòu) 草稿紙也能畫得出來。
看紅包
圖片
存儲(chǔ)不用 Redis List 用數(shù)據(jù)庫(kù)是否可以？其實(shí)也是可以，性能要關(guān)注 ，Mysql的成本比較高，同等的條件范圍下，一般來說數(shù)據(jù)庫(kù)的服務(wù)器的成本要比負(fù)責(zé)運(yùn)算的機(jī)器要高。
為啥 hash ？搶紅包分配在一個(gè)機(jī)器，業(yè)務(wù)會(huì)簡(jiǎn)單，實(shí)現(xiàn)簡(jiǎn)單不要分布式的消費(fèi)
不過中間增加機(jī)器，hash的過程肯定會(huì)變。
看紅包：
圖片
看紅包架構(gòu)= 搶紅包架構(gòu)
圖片
紅包高性能方案 整體架構(gòu)
圖片
紅包整體架構(gòu)圖-單機(jī)房示意圖：
圖片
紅包高性能方案 - 更高一級(jí)的架構(gòu)決策
圖片
高性能架構(gòu)的成本優(yōu)化思路：
圖片
假設(shè)現(xiàn)在紅包業(yè)務(wù)總共部署了1000臺(tái)服務(wù)器，老板覺得運(yùn)營(yíng)成本太高，希望能夠節(jié)省一些成本。
優(yōu)化：
1. 服務(wù)器改為 Go 實(shí)現(xiàn)？
2. 發(fā)紅包的時(shí)候拆分？
3. 紅包業(yè)務(wù)和其它業(yè)務(wù)共用服務(wù)器？
創(chuàng)新:
1. 開發(fā)紅包數(shù)據(jù)庫(kù)？
2. 彈性擴(kuò)容/縮容？
紅包架構(gòu) - 全部用數(shù)據(jù)庫(kù)存儲(chǔ)
圖片
其中的變化是：去掉了RedisCluster
優(yōu)化方案-發(fā)紅包拆分:這還是比較投機(jī)取巧的
圖片
【小結(jié)】
- 紅包的復(fù)雜度主要體現(xiàn)在質(zhì)量復(fù)雜度
- 每天1億的請(qǐng)求量不一定是高性能
- 將發(fā)紅包、拆紅包分為不同的服務(wù)，可以提升性能
- 紅包業(yè)務(wù)可以作為支付業(yè)務(wù)的功能，也可以按照獨(dú)立業(yè)務(wù)來看
- 降本不只是主要靠提升單機(jī)處理性能
