劉磊，陳華溢，姚文輝

（廣東開放大學(xué)（廣東理工職業(yè)學(xué)院），廣東 廣州 510091）

0 引 言

據(jù)統(tǒng)計(jì)，2018年春節(jié)微信參與搶紅包的峰值達(dá)到8.1 億次/分鐘，2019年春節(jié)支付寶搶紅包的峰值達(dá)到每秒4.4 萬筆，2022年春節(jié)搶紅包大戰(zhàn)總額超80 億，搶紅包已蔚然成為一種中國人特有的社交潮流，在全民狂歡的背后，強(qiáng)大、高效的搶紅包系統(tǒng)作為基礎(chǔ)架構(gòu)支撐起了海量紅包數(shù)據(jù)處理，筆者從搶紅包系統(tǒng)的業(yè)務(wù)分析出發(fā)，嘗試設(shè)計(jì)和實(shí)現(xiàn)一種基于B/S 架構(gòu)的通用搶紅包系統(tǒng)，能同時(shí)適用于手機(jī)端、桌面端、平板端，而不僅局限于APP 內(nèi)部。

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

圖1 搶紅包示意圖

1 系統(tǒng)設(shè)計(jì)

1.1 功能設(shè)計(jì)

為著重驗(yàn)證搶紅包功能，筆者設(shè)計(jì)了一個(gè)業(yè)務(wù)具有典型性的搶紅包系統(tǒng)，功能設(shè)計(jì)為：

（1）用戶注冊(cè)登錄：發(fā)紅包用戶和搶紅包用戶都要注冊(cè)賬號(hào)，使用賬號(hào)登錄系統(tǒng)。

（2）發(fā)紅包：用戶填寫紅包個(gè)數(shù)、總金額等信息發(fā)出紅包。

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

（4）搶紅包：用戶查看列表，點(diǎn)擊搶紅包，后端執(zhí)行紅包分配過程，返回前端搶到的結(jié)果。

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

（6）紅包排行榜：降序顯示單個(gè)紅包被搶到的數(shù)據(jù)明細(xì)。

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

（8）我發(fā)出的紅包：以列表形式展示用戶發(fā)出的紅包數(shù)據(jù)。

1.2 數(shù)據(jù)庫設(shè)計(jì)

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

圖2 數(shù)據(jù)庫模型圖

1.3 流程設(shè)計(jì)

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

圖3 系統(tǒng)交互流程圖

1.3.1 紅包分配算法

大量用戶搶有限的紅包金額，實(shí)質(zhì)是把一個(gè)大數(shù)根據(jù)一定算法分解成個(gè)小數(shù)的過程，小數(shù)的范圍是[min，max]?？紤]搶紅包的高并發(fā)性，在兼顧公平的同時(shí)，紅包分配算法越簡(jiǎn)單則越高效，運(yùn)行越快則“資源競(jìng)爭(zhēng)排隊(duì)時(shí)間”越短，系統(tǒng)性能和并發(fā)處理能力則越高。從不同角度設(shè)計(jì)有不同紅包算法，本方案設(shè)計(jì)了一種快速生成隨機(jī)紅包的算法。

算法原理：

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

（2）若紅包個(gè)數(shù)是一個(gè)，則生成紅包金額直接使用總金額。

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

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

假設(shè)剩余紅包總金額為，剩余紅包個(gè)數(shù)為，每輪生成的紅包金額為，算法公式為：

使用Java 實(shí)現(xiàn)以上算法，關(guān)鍵代碼為：

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

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

1.3.2 發(fā)紅包結(jié)構(gòu)設(shè)計(jì)

發(fā)紅包用戶（簡(jiǎn)稱發(fā)包者）的動(dòng)作是封一個(gè)紅包拋出去，封裝的紅包關(guān)鍵數(shù)據(jù)包括發(fā)包者ID、紅包ID、個(gè)數(shù)、總金額等，為應(yīng)對(duì)同時(shí)發(fā)紅包的請(qǐng)求超過系統(tǒng)的并發(fā)處理能力，可在流量高峰階段使用隊(duì)列技術(shù)減緩對(duì)服務(wù)器的沖擊。發(fā)紅包的實(shí)現(xiàn)結(jié)構(gòu)設(shè)計(jì)為：

（1）發(fā)包者在前端填寫紅包數(shù)據(jù)并向服務(wù)器提交。

（2）若同時(shí)發(fā)包提交請(qǐng)求超過一定量級(jí)，可先將請(qǐng)求放入發(fā)包隊(duì)列。

（3）服務(wù)器先將紅包數(shù)據(jù)存入緩存，緩存模塊基于內(nèi)存運(yùn)行，因?yàn)閮?nèi)存的存取性能遠(yuǎn)遠(yuǎn)大于硬盤，將搶紅包的過程放在內(nèi)存完成性能是很高的，為保證緩存模塊中單個(gè)紅包數(shù)據(jù)的全局唯一性，這時(shí)可以通過Random 提前生成全局唯一ID 作為紅包主鍵。

（4）紅包數(shù)據(jù)在緩存之后，進(jìn)入入庫隊(duì)列，被推送到數(shù)據(jù)庫進(jìn)行持久化存儲(chǔ)。

（5）同時(shí)，紅包數(shù)據(jù)進(jìn)入紅包廣播隊(duì)列，被推送到眾多搶包者客戶端，搶包者拿到紅包ID 準(zhǔn)備發(fā)起搶紅包流程。發(fā)紅包實(shí)現(xiàn)結(jié)構(gòu)設(shè)計(jì)如圖4所示。

圖4 發(fā)紅包實(shí)現(xiàn)結(jié)構(gòu)

1.3.3 搶紅包結(jié)構(gòu)設(shè)計(jì)

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

（1）搶包者發(fā)出搶紅包的請(qǐng)求。

（2）當(dāng)并發(fā)量比較大時(shí)，請(qǐng)求先放入隊(duì)列，通過計(jì)數(shù)器統(tǒng)計(jì)，超過紅包個(gè)數(shù)直接返回。

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

（4）當(dāng)紅包被搶完時(shí)，將搶到紅包的用戶數(shù)據(jù)數(shù)組放入入庫隊(duì)列。

（5）入庫隊(duì)列里的數(shù)據(jù)異步批量存入數(shù)據(jù)庫。搶紅包實(shí)現(xiàn)結(jié)構(gòu)設(shè)計(jì)如圖5所示。

圖5 搶紅包實(shí)現(xiàn)結(jié)構(gòu)

2 技術(shù)實(shí)現(xiàn)

本系統(tǒng)實(shí)現(xiàn)方案采用業(yè)界流行的技術(shù)組合：Linux+Tomcat/Nginx+SSM+Bootstrap+MySQL+Redis+Mav en，這套組合被阿里、京東等互聯(lián)網(wǎng)公司廣泛應(yīng)用于大中型Web應(yīng)用，非常適于開發(fā)高并發(fā)、高性能、高擴(kuò)展的Web系統(tǒng)。本方案涉及的技術(shù)點(diǎn)為：

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

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

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

圖6 緩存的紅包數(shù)據(jù)

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

2.1 集群化部署架構(gòu)

理論上，一臺(tái)服務(wù)器若能頂住1 000 的并發(fā)量，兩臺(tái)服務(wù)器就能頂住2 000 的并發(fā)量，一般來說，當(dāng)上線的Web 系統(tǒng)并發(fā)量達(dá)到一定數(shù)量級(jí)時(shí)，都可以通過大規(guī)模服務(wù)器集群化部署提高系統(tǒng)的抗壓能力，也就是常說的“當(dāng)一頭牛拉不動(dòng)時(shí)，那就用三頭?！薄１痉桨冈O(shè)計(jì)的系統(tǒng)架構(gòu)、選用的開發(fā)框架都非常適于以集群的方式運(yùn)行，對(duì)于實(shí)際線上的搶紅包系統(tǒng)，通過不斷增加服務(wù)器可以快速提高系統(tǒng)的并發(fā)處理能力。本系統(tǒng)線上集群化部署可以分為五層：

（1）CDN 緩存層：緩存靜態(tài)化資源。

（2）負(fù)載均衡層：根據(jù)訪問量，負(fù)責(zé)將請(qǐng)求智能轉(zhuǎn)發(fā)到不同服務(wù)器。

（3）Web 應(yīng)用層：在Tomcat 集群上部署相同的Web應(yīng)用。

（4）Redis 緩存層：在內(nèi)存緩存搶紅包過程產(chǎn)生的數(shù)據(jù)。

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

圖7 搶紅包系統(tǒng)集群化部署方案

2.2 系統(tǒng)測(cè)試

為了測(cè)試本文設(shè)計(jì)的搶紅包系統(tǒng)的性能，筆者在PC機(jī)上進(jìn)行了兩組模擬實(shí)驗(yàn)，硬件配置為：CPU Core i5 3.3 GHz、內(nèi)存8 GB；軟件配置為：Tomcat 7.0、JDK 1.7、Redis 3.0、MySQL 5.5。

2.2.1 測(cè)試紅包分配算法

為了測(cè)試本文設(shè)計(jì)的紅包分配算法的公平性，筆者模擬10 人搶100 元紅包，每輪產(chǎn)生10 個(gè)小紅包數(shù)據(jù)，執(zhí)行1 000 000 輪，每人產(chǎn)生了1 000 000 條紅包數(shù)據(jù)，將每個(gè)人的紅包數(shù)據(jù)求平均值和標(biāo)準(zhǔn)差，得到的數(shù)據(jù)為表2所示。

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

由實(shí)驗(yàn)數(shù)據(jù)可知：

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

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

2.2.2 測(cè)試搶紅包性能

使用Java 編程模擬高并發(fā)搶紅包場(chǎng)景，紅包個(gè)數(shù)為100 000 個(gè)，總金額為1 000 000 元，紅包數(shù)據(jù)和明細(xì)都存儲(chǔ)在Redis，搶紅包過程在內(nèi)存完成，同時(shí)啟動(dòng)30 個(gè)線程運(yùn)行搶紅包程序。通過搶完的紅包總個(gè)數(shù)除以總耗時(shí)可得到搶紅包速度，經(jīng)多次測(cè)算，每毫秒可以搶23 個(gè)，也就是每秒大致可以搶2.3 萬個(gè)紅包，可見在內(nèi)存完成搶紅包過程性能是很高的，能滿足絕大多數(shù)場(chǎng)景需求。另外，本方案實(shí)現(xiàn)的搶紅包系統(tǒng)作為筆者參與的電商平臺(tái)核心模塊已經(jīng)上線運(yùn)行，通過生產(chǎn)環(huán)境中的性能優(yōu)化和集群化部署，在多次的促銷活動(dòng)中，頂住了上萬的并發(fā)壓力，表現(xiàn)穩(wěn)定。

3 結(jié) 論

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