紅包復雜度總體分析

圖片

紅包業務應該屬于質量復雜度

圖片

紅包高性能復雜度分析

圖片

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

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

對照復雜度

圖片

進程模型：主從模型、生產者-消費者模型、管道模型...

網絡模型：TCP/IP模型、五層模型、OSI模型...

緩存模型：應用程序緩存模型、數據庫緩存模型、內存緩存模型...

紅包高性能復雜度應對思路-發紅包:

圖片

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

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

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

發紅包架構圖：

圖片

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

看紅包

圖片

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

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

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

看紅包：

圖片

看紅包架構= 搶紅包架構

圖片

紅包高性能方案  整體架構

圖片

紅包整體架構圖-單機房示意圖：

圖片

紅包高性能方案 - 更高一級的架構決策

圖片

高性能架構的成本優化思路：

圖片

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

優化：

1. 服務器改為 Go 實現？

2. 發紅包的時候拆分？

3. 紅包業務和其它業務共用服務器？

創新:

1. 開發紅包數據庫？

2. 彈性擴容/縮容？

紅包架構 - 全部用數據庫存儲

圖片

其中的變化是：去掉了RedisCluster

優化方案-發紅包拆分:這還是比較投機取巧的

圖片

【小結】

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