紅包復雜度總體分析

圖片

紅包業(yè)務應該屬于質(zhì)量復雜度

圖片

紅包高性能復雜度分析

圖片

做性能分析，我們計算的都是按峰值來計算，上圖是我們得出的一些數(shù)據(jù)。軟件系統(tǒng)的性能都是用峰值TPS/QPS來衡量的，其時間單位是秒。

紅包高性能復雜度應對思路：

對照復雜度

圖片

進程模型：主從模型、生產(chǎn)者-消費者模型、管道模型...

網(wǎng)絡模型：TCP/IP模型、五層模型、OSI模型...

緩存模型：應用程序緩存模型、數(shù)據(jù)庫緩存模型、內(nèi)存緩存模型...

紅包高性能復雜度應對思路-發(fā)紅包:

圖片

因為你不是新開發(fā)一個系統(tǒng)，那進程模型、網(wǎng)絡模型、緩存模型基本都是跑在原有的框架之上，基本不要改，用springboot就用springboot。

存儲模型考慮點是紅包的讀寫業(yè)務還是比較復雜的，不是一個簡單的查詢模型，所以暫時用B+樹，B+樹的高度保持平衡，使查找操作效率高，在插入和刪除操作時性能相對穩(wěn)定，支持范圍查詢，因為它的葉子節(jié)點有序排列

集群方面：計算高性能 發(fā)紅包是個簡單的業(yè)務，任務分配就行了。存儲方面，關(guān)系數(shù)據(jù)庫的分片存儲 一個數(shù)據(jù)庫支持2.5萬個紅包， 還是比較吃力的。

發(fā)紅包架構(gòu)圖：

圖片

上面是一個初步的架構(gòu) 草稿紙也能畫得出來。

看紅包

圖片

存儲不用 Redis List   用數(shù)據(jù)庫是否可以？其實也是可以，性能要關(guān)注 ，Mysql的成本比較高，同等的條件范圍下，一般來說數(shù)據(jù)庫的服務器的成本要比負責運算的機器要高。

為啥 hash ？搶紅包分配在一個機器，業(yè)務會簡單，實現(xiàn)簡單不要分布式的消費

不過中間增加機器，hash的過程肯定會變。

看紅包：

圖片

看紅包架構(gòu)= 搶紅包架構(gòu)

圖片

紅包高性能方案  整體架構(gòu)

圖片

紅包整體架構(gòu)圖-單機房示意圖：

圖片

紅包高性能方案 - 更高一級的架構(gòu)決策

圖片

高性能架構(gòu)的成本優(yōu)化思路：

圖片

假設現(xiàn)在紅包業(yè)務總共部署了1000臺服務器，老板覺得運營成本太高，希望能夠節(jié)省一些成本。

優(yōu)化：

1. 服務器改為 Go 實現(xiàn)？

2. 發(fā)紅包的時候拆分？

3. 紅包業(yè)務和其它業(yè)務共用服務器？

創(chuàng)新:

1. 開發(fā)紅包數(shù)據(jù)庫？

2. 彈性擴容/縮容？

紅包架構(gòu) - 全部用數(shù)據(jù)庫存儲

圖片

其中的變化是：去掉了RedisCluster

優(yōu)化方案-發(fā)紅包拆分:這還是比較投機取巧的

圖片

【小結(jié)】

1. 紅包的復雜度主要體現(xiàn)在質(zhì)量復雜度
2. 每天1億的請求量不一定是高性能
3. 將發(fā)紅包、拆紅包分為不同的服務，可以提升性能
4. 紅包業(yè)務可以作為支付業(yè)務的功能，也可以按照獨立業(yè)務來看
5. 降本不只是主要靠提升單機處理性能