一種高性能搶紅包系統的設計與實現

劉磊，陳華溢，姚文輝

（廣東開放大學（廣東理工職業學院），廣東 廣州 510091）

0 引 言

據統計，2018年春節微信參與搶紅包的峰值達到8.1 億次/分鐘，2019年春節支付寶搶紅包的峰值達到每秒4.4 萬筆，2022年春節搶紅包大戰總額超80 億，搶紅包已蔚然成為一種中國人特有的社交潮流，在全民狂歡的背后，強大、高效的搶紅包系統作為基礎架構支撐起了海量紅包數據處理，筆者從搶紅包系統的業務分析出發，嘗試設計和實現一種基于B/S 架構的通用搶紅包系統，能同時適用于手機端、桌面端、平板端，而不僅局限于APP 內部。

搶紅包系統涉及發紅包用戶和搶紅包用戶，一個典型的搶紅包業務為：一個發紅包用戶填寫紅包個數、總金額等信息發出紅包，紅包數據存入數據庫，系統并將消息推送給搶紅包的用戶；多個搶紅包用戶收到紅包消息，點擊開始搶紅包，發送搶的請求到服務端，服務端根據紅包分配算法，從總金額生成一個小金額給搶到紅包的用戶，總金額值減小，紅包個數減一，當大紅包被用戶搶完，紅包個數和總金額減到零，搶到的紅包明細數據存入數據庫，這樣就完成了一個搶紅包過程，示意圖如圖1所示。搶紅包業務通常規定，紅包有效期為24 小時，同一用戶對同一紅包只能搶一次。通過分析可知，一個紅包發出往往會被瞬間搶完，超過24 小時紅包即為失效，系統具有“短時間”特點；一次搶紅包活動搶到的人等于紅包個數，這個數字在發紅包時可以確定，不會太大，但參與搶的人通常大于紅包個數，假設有1 億人同時發出紅包，按發和搶比例為1：9 計算，則有9 億人幾乎同時參與搶紅包，系統要承載海量的“高并發”請求；一個用戶發出紅包，多個用戶搶紅包，實質是有限資源的瞬時競爭，是將一個大金額數字生成多個小金額數字，數據的存取和金額計算都需要耗時，用戶發出搶紅包請求是搶成功了、還是搶完了、或者是已搶過，都要最快響應，系統有“高性能”的需求。綜上所述，設計一個魯棒的搶紅包系統在功能上要具備搶和發的能力，在性能上要達到高性能、高并發的要求。

圖1 搶紅包示意圖

1 系統設計

1.1 功能設計

為著重驗證搶紅包功能，筆者設計了一個業務具有典型性的搶紅包系統，功能設計為：

（1）用戶注冊登錄：發紅包用戶和搶紅包用戶都要注冊賬號，使用賬號登錄系統。

（2）發紅包：用戶填寫紅包個數、總金額等信息發出紅包。

（3）紅包列表：用戶登錄成功后，可以查看所有能夠參與的搶紅包列表，以標記區別顯示正在搶、已搶過、已搶完、已失效四種狀態。

（4）搶紅包：用戶查看列表，點擊搶紅包，后端執行紅包分配過程，返回前端搶到的結果。

（5）手氣最佳：顯示單個紅包被搶到的最大金額。

（6）紅包排行榜：降序顯示單個紅包被搶到的數據明細。

（7）我收到的紅包：以列表形式展示用戶搶到的紅包數據。

（8）我發出的紅包：以列表形式展示用戶發出的紅包數據。

1.2 數據庫設計

圍繞紅包業務和功能分析，本方案數據庫設計三個核心實體對象：用戶、紅包、清單。用戶實體記錄注冊登錄信息，用戶ID 設置為主鍵；紅包實體記錄一個紅包的發包者、紅包個數、總金額、附言、創建時間等信息，紅包ID 設置為主鍵；清單記錄用戶搶紅包的明細，即哪個用戶搶了哪個紅包，搶到的金額是多少，字段包括搶包者ID、紅包ID、搶到的金額、搶到的時間等。根據業務分析，一個用戶可以發多個紅包，一個紅包只能被一個用戶發出，用戶與紅包是一對多的關系，同時業務要求同一用戶對同一紅包不能重復搶，也就是清單表不能插入用戶ID和紅包ID兩者都相同的記錄，解決策略是只需要將紅包ID 與用戶ID 組成清單表的聯合主鍵即可。本紅包系統數據庫模型設計如圖2所示。

圖2 數據庫模型圖

1.3 流程設計

用戶發紅包的流程是：用戶在前端錄入數據，點擊發出紅包，系統后端推送通知消息給搶紅包的用戶。用戶搶紅包的流程是：用戶在前端收到紅包提示信息，查看紅包列表，點擊搶紅包，發送請求到后端服務器，服務器通過計算判斷返回前端響應信息，若剩余金額和剩余紅包個數為0，返回“已搶完”；若搶到的用戶隊列包含該用戶ID，則返回“已搶過”；若剩余金額和剩余紅包個數不為0，且不包含該用戶ID，則從剩余金額分配出一個小金額給該用戶，返回“搶紅包成功”，顯示搶到的金額。系統交互流程設計如圖3所示。

圖3 系統交互流程圖

1.3.1 紅包分配算法

大量用戶搶有限的紅包金額，實質是把一個大數根據一定算法分解成個小數的過程，小數的范圍是[min，max]。考慮搶紅包的高并發性，在兼顧公平的同時，紅包分配算法越簡單則越高效，運行越快則“資源競爭排隊時間”越短，系統性能和并發處理能力則越高。從不同角度設計有不同紅包算法，本方案設計了一種快速生成隨機紅包的算法。

算法原理：

（1）規定，因人民幣最小金額為1 分，生成紅包的金額最小為0.01 元。

（2）若紅包個數是一個，則生成紅包金額直接使用總金額。

（3）若紅包個數是多個，則取0.01 與2 倍紅包均值之間的隨機數，紅包均值=剩余總金額/剩余個數，即每輪生成的隨機紅包金額最小為0.01，最大為2 倍紅包均值，使用2 倍紅包均值做最大值可以保證每輪生成的紅包金額不會相差太大。

（4）每生成一次紅包，總金額減去生成的金額，紅包個數減一，直至紅包個數值為一，也就是最后一個紅包，金額使用剩余的金額，不再隨機生成。

假設剩余紅包總金額為，剩余紅包個數為，每輪生成的紅包金額為，算法公式為：

使用Java 實現以上算法，關鍵代碼為：

以10 人搶100 元大紅包為例，一開始紅包的數量為10、金額為100，同一個用戶對同一個紅包只能搶一次，也就是要經過10 輪才能搶完，10 位不同用戶搶到的金額經過算法隨機計算得到，經測試，其中一種分配情況如表1所示，本案例在筆者機器上經100 000 次運行，計算平均耗時約為7 微秒，可見使用本算法在內存生成紅包的速度是很快的。

表1 以10 人搶100 元紅包為例

1.3.2 發紅包結構設計

發紅包用戶（簡稱發包者）的動作是封一個紅包拋出去，封裝的紅包關鍵數據包括發包者ID、紅包ID、個數、總金額等，為應對同時發紅包的請求超過系統的并發處理能力，可在流量高峰階段使用隊列技術減緩對服務器的沖擊。發紅包的實現結構設計為：

（1）發包者在前端填寫紅包數據并向服務器提交。

（2）若同時發包提交請求超過一定量級，可先將請求放入發包隊列。

（3）服務器先將紅包數據存入緩存，緩存模塊基于內存運行，因為內存的存取性能遠遠大于硬盤，將搶紅包的過程放在內存完成性能是很高的，為保證緩存模塊中單個紅包數據的全局唯一性，這時可以通過Random 提前生成全局唯一ID 作為紅包主鍵。

（4）紅包數據在緩存之后，進入入庫隊列，被推送到數據庫進行持久化存儲。

（5）同時，紅包數據進入紅包廣播隊列，被推送到眾多搶包者客戶端，搶包者拿到紅包ID 準備發起搶紅包流程。發紅包實現結構設計如圖4所示。

圖4 發紅包實現結構

1.3.3 搶紅包結構設計

大量用戶爭搶一個紅包，實質是有限資源在高并發情況下的搶占，這就存在高并發競爭的問題，紅包在發出時是有個數限制的，也就是說在發出時就能估算有效搶到紅包用戶的個數，超過紅包個數的用戶訪問請求，紅包已經分配完，再去爭搶是無意義的，所以當搶紅包的請求并發量比較大時，可以設置一層請求過濾隊列，通過計數器統計，在紅包個數內的請求直接放入，一旦紅包已經搶完，紅包個數減為零，后面的請求不再放入，直接返回“紅包已搶完”，搶紅包的過程在內存完成，紅包數據和搶到的用戶列表都暫存在緩存，這樣可保證最快的響應性能，等紅包搶完，則將搶到紅包的用戶ID 和金額批量入庫。搶紅包的實現結構設計為：

（1）搶包者發出搶紅包的請求。

（2）當并發量比較大時，請求先放入隊列，通過計數器統計，超過紅包個數直接返回。

（3）放入有效的搶紅包請求，搶紅包過程在內存完成，根據紅包ID 從緩存拿到紅包剩余數量和剩余金額，通過紅包分配算法隨機生成一個金額給搶包者，這個計算是在內存實時完成的，更新紅包剩余金額，紅包剩余數量減1，將更新后的紅包數據再放回緩存以備下次搶紅包使用，同時將搶到紅包的用戶ID 和金額也放入緩存，可維護一個搶到用戶的數據數組，記錄所有搶到用戶的ID 和金額。

（4）當紅包被搶完時，將搶到紅包的用戶數據數組放入入庫隊列。

（5）入庫隊列里的數據異步批量存入數據庫。搶紅包實現結構設計如圖5所示。

圖5 搶紅包實現結構

2 技術實現

本系統實現方案采用業界流行的技術組合：Linux+Tomcat/Nginx+SSM+Bootstrap+MySQL+Redis+Mav en，這套組合被阿里、京東等互聯網公司廣泛應用于大中型Web應用，非常適于開發高并發、高性能、高擴展的Web系統。本方案涉及的技術點為：

（1）開發框架：后端使用SpringMVC、Spring、Mybatis 三大框架（SSM），主流的J2EE 企業級開發框架，具有輕量級、代碼侵入性低、技術成熟的特點，支持典型的三層架構：DAO（數據層）、Service（業務層）、Web（表示層）。Mybatis 是數據層框架，支持定制SQL 語句，傳參自由、靈活，結果集自動賦值，接口設計和SQL 語句分離。Spring 提供了一個統一托管對象的容器工廠，允許通過一致的訪問接口，訪問工廠里的任意實例。SpringMVC 是Web層框架，支持restful 風格的URL 和MVC 開發模式。前端使用Bootstrap 框架，基于HTML5、CSS3、JQuery 技術構建，提供了導航、分頁、面板等可復用的靜態組件，下拉菜單、標簽頁、彈出框等動態插件，強大靈活的柵格布局系統，使用Bootstrap 可以快速、高效的開發健壯和優雅的響應式靜態頁面。

（2）隊列技術：當并發請求達到一定量級時，超過系統接納能力，有可能壓垮系統，這時可以使用隊列技術對并發請求限流，隊列能將同時發出的請求進行排隊處理，從而達到異步處理、流量削峰的目的。本方案使用請求隊列應對同時發紅包和搶紅包的并發數；為保證高性能，搶紅包的過程是在內存完成，搶完后的紅包數據明細使用任務隊列批量異步入庫；發紅包的過程完成后，使用消息隊列及時推送通知給客戶端。

（3）緩存模塊：使用基于內存的NoSQL 型數據庫Redis，Redis 性能非常高，經測試每秒鐘SET 操作可執行110 000 次、GET 操作可執行81 000 次，Redis 支持原子性操作，也可將一組命令封裝以事務的方式執行，即事務包括內的命令要么都執行，要么都不執行，保證數據一致性。本方案使用Redis 緩存紅包數據，Redis 支持以鍵值（Key-Value）存儲數據，每個紅包維護兩組數據，大紅包數據使用紅包ID 標識，記錄剩余個數和剩余金額，小紅包數據使用同樣的紅包ID 標識（為避免重復，可取反），記錄搶包者ID 和搶到的金額，大紅包經過算法分配生成小紅包明細，過程都在內存完成，保證了高性能，存儲結構如圖6所示。

圖6 緩存的紅包數據

（4）原子計數：一個紅包發出時，小紅包的數量決定了有多少人能搶到紅包，也就是有效搶紅包的請求是可以確定的，對同一個紅包，可能有非常多的搶包者同時發送搶紅包請求，在能夠確定紅包數量的基礎上，對放入的請求進行原子計數，當數目和紅包個數相等時，即紅包被搶完，后面的請求無須再放入，直接返回“已搶完”，既能提高響應速度又能減輕系統壓力。本方案使用Redis 兩個原子性的操作命令incr、decr 完成計數，以紅包ID 為key，每次放入一個搶紅包請求，計數就加1，在Redis 中使用代碼：redis>incr key，在Spring 環境中使用代碼：Long incrementId= redisTemplate.opsForValue().increment(key,1)。

2.1 集群化部署架構

理論上，一臺服務器若能頂住1 000 的并發量，兩臺服務器就能頂住2 000 的并發量，一般來說，當上線的Web 系統并發量達到一定數量級時，都可以通過大規模服務器集群化部署提高系統的抗壓能力，也就是常說的“當一頭牛拉不動時，那就用三頭牛”。本方案設計的系統架構、選用的開發框架都非常適于以集群的方式運行，對于實際線上的搶紅包系統，通過不斷增加服務器可以快速提高系統的并發處理能力。本系統線上集群化部署可以分為五層：

（1）CDN 緩存層：緩存靜態化資源。

（2）負載均衡層：根據訪問量，負責將請求智能轉發到不同服務器。

（3）Web 應用層：在Tomcat 集群上部署相同的Web應用。

（4）Redis 緩存層：在內存緩存搶紅包過程產生的數據。

（5）數據存儲層：數據落地，使用主從庫同步、讀寫庫分離、分庫分表等技術增強抗壓能力。線上搶紅包系統集群化部署方案參考如圖7所示。

圖7 搶紅包系統集群化部署方案

2.2 系統測試

為了測試本文設計的搶紅包系統的性能，筆者在PC機上進行了兩組模擬實驗，硬件配置為：CPU Core i5 3.3 GHz、內存8 GB；軟件配置為：Tomcat 7.0、JDK 1.7、Redis 3.0、MySQL 5.5。

2.2.1 測試紅包分配算法

為了測試本文設計的紅包分配算法的公平性，筆者模擬10 人搶100 元紅包，每輪產生10 個小紅包數據，執行1 000 000 輪，每人產生了1 000 000 條紅包數據，將每個人的紅包數據求平均值和標準差，得到的數據為表2所示。

表2 模擬10 人搶100 元（執行1 000 000 次）

由實驗數據可知：

（1）10 人的平均值大致相等，都在100/10 ＝10 附近波動，從統計學角度看，說明每人搶到紅包的期望值是大致相等的，也就是大家搶到的紅包面額在概率上是大致均勻分布的，都接近于理論平均值（總金額/總個數）。

（2）10 人的標準差存在差異，從第1 人到第10 人逐漸增大，這表明，先生成的紅包數據波動較小，后生成的紅包數據波動較大，也就是后搶的人有較大概率拿到“手氣最佳”或者“手氣最差”，增加了搶紅包的趣味性。

2.2.2 測試搶紅包性能

使用Java 編程模擬高并發搶紅包場景，紅包個數為100 000 個，總金額為1 000 000 元，紅包數據和明細都存儲在Redis，搶紅包過程在內存完成，同時啟動30 個線程運行搶紅包程序。通過搶完的紅包總個數除以總耗時可得到搶紅包速度，經多次測算，每毫秒可以搶23 個，也就是每秒大致可以搶2.3 萬個紅包，可見在內存完成搶紅包過程性能是很高的，能滿足絕大多數場景需求。另外，本方案實現的搶紅包系統作為筆者參與的電商平臺核心模塊已經上線運行，通過生產環境中的性能優化和集群化部署，在多次的促銷活動中，頂住了上萬的并發壓力，表現穩定。

3 結 論

本文設計和實現的搶紅包解決方案，使用SSM 框架實現高擴展性，基于Redis 緩存實現高性能紅包分配算法，使用集群化部署增強系統并發處理能力，試驗表明本方案具有典型性，對于解決搶紅包、秒殺這類“瞬時高并發搶資源”的需求有較普遍的參考價值，本文沒有更多討論搶紅包系統的安全性，有待進一步研究。當然搶紅包系統的線上實現方案不止一種，從不同角度也可以設計不同的紅包分配算法，沒有最佳和一勞永逸的方案，只有最適應業務需求的方案，讀者可以根據場景靈活選用。