redis+mysql+quartz 一種紅包發(fā)送功能的實現(xiàn)
概要：
這篇文章主要是對半年前開發(fā)的紅包模塊進行整理，把其中主要的設(shè)計思想以及具體的實現(xiàn)方案進行介紹，如有設(shè)計以及實現(xiàn)上的缺陷，或是存在漏洞，請大家批評指正！
紅包功能大家都很熟悉了，那在這里就簡單的對紅包功能進行描述...
功能描述：紅包業(yè)務(wù)主要的功能包括四部分，分別是紅包發(fā)送，紅包接收，紅包回收，以及紅包記錄查詢。
1）紅包發(fā)送：發(fā)送者賬戶->紅包中間層
2）紅包接收：紅包中間層->接收者賬戶
3）紅包回收：紅包中間層中若存在紅包留存超過24小時，則將其回收，紅包中間層->發(fā)送者賬戶
功能描述大體了解之后，那接下來就是實現(xiàn)方案了...
首先給出設(shè)計流程，這部分將依次對紅包發(fā)送、紅包接收、紅包回收的流程進行分析...
1. 設(shè)計流程
首先是紅包發(fā)送功能，以群紅包為例，其流程圖如下所示：
圖1 紅包發(fā)送流程圖
首先，采用基于高斯分布的方法，將金額100隨機的分配成8份，然后將這8份數(shù)據(jù)存入到redis緩存隊列(list)中，同時將隊列的過期時間設(shè)置成24h；考慮到在搶紅包的時候會出現(xiàn)重復(fù)搶的問題，那在這里采用的去除重復(fù)的方案是在redis緩存中維護一個已分配集合（set），集合里面存儲的是已經(jīng)接收過紅包的用戶ID；另外，在大量的用戶同時搶紅包的 情況，出于優(yōu)化方面的考慮，為了起到一定的限流作用，同時減少對數(shù)據(jù)庫的訪問壓力（考慮這種情況：一個時間段內(nèi)，大量的用戶在搶紅包，在紅包已經(jīng)分配完的時刻之后 到來的請求，會給數(shù)據(jù)庫帶來一定的訪問壓力），那做法是在redis緩存中維護一個紅包已分配完的標(biāo)記（key-value）,有0（為分配完）/1（已分配完）兩種狀態(tài)，從而起到一定的限流作用。
繼緩存層面之后，接下來是數(shù)據(jù)庫層面，那在MySQL中的紅包發(fā)送表（account_coin_records_user_coin_package_send）中生成一條記錄，同時呢在把上面經(jīng)高斯分布方法得到的8份金額插入到紅包分配表（account_coin_records_user_coin_package_assign）中，初始化分配標(biāo)記為0（未分配），至此，紅包發(fā)送的整個流程完成。
然后是紅包接收功能，其流程圖如下所示：
圖2 紅包接收流程圖
紅包接收者發(fā)起請求（請求中包含紅包ID、請求人的用戶ID）去搶紅包，首先需要一系列的驗證，這個驗證操作要同時基于redis緩存以及MySQL數(shù)據(jù)庫中的數(shù)據(jù)進行 驗證，主要是驗證紅包ID對應(yīng)的紅包是否存在、紅包是否已經(jīng)分配完了、紅包是否已經(jīng)過期了、紅包接收者是否重復(fù)接收紅包等。如果驗證通過，那么這個用戶是允許接收到紅包的，接下來就是賬戶同步（紅包中間層->用戶賬戶，事務(wù)處理），若數(shù)據(jù)庫操作成功，則紅包接收成功，否則失敗，至此，紅包接收整體流程完成。
最后就是紅包回收功能，其流程圖如下所示：
圖3 紅包回收流程圖
紅包回收是采用定時調(diào)度策略發(fā)起的，時間間隔為5min不間斷的輪詢訪問MySQL數(shù)據(jù)庫，查詢是否有待回收的紅包（紅包在紅包中間層留存已經(jīng)超過24h，且紅包 未 分配完），若有需要回收的紅包，這個時候基于效率方面的考慮，采用多線程方案來進行回收操作，每個紅包對于一個線程，策略是：一個線程，一個請求，一個事務(wù)（這 個 方案只適用于待回收的紅包個數(shù)不是很多的情況）。（注意：若需要回收的紅包很多，若不斷的申請線程，可能造成內(nèi)存溢出問題，這時候具體問題具體分析，可以考慮生產(chǎn)者-消費者模式）；分布式架構(gòu)，遠程調(diào)用，接下來處理紅包回收的服務(wù)器接收到紅包回收請求后，進行賬戶同步以及紅包狀態(tài)標(biāo)記（標(biāo)記為已回收），若數(shù)據(jù)庫事務(wù)出現(xiàn)異常，那么事務(wù)回滾，此時，這個紅包沒有回收成功，只能等待下一個5min后再次被回收。
到這里，流程基本介紹完了，那接下來介紹一下數(shù)據(jù)模型...
2. 數(shù)據(jù)模型
數(shù)據(jù)庫用的是MySQL。將紅包記錄進行持久化存儲，用于查詢紅包分配記錄以及后期的歷史記錄查詢。紅包分配的數(shù)據(jù)模型如下圖所示：
圖4 紅包分配數(shù)據(jù)模型
圖4中展示了部分的比較重要的數(shù)據(jù)信息，表之間的關(guān)聯(lián)是靠紅包ID建立起來的，紅包記錄以及狀態(tài)標(biāo)記圖中已經(jīng)標(biāo)識出來了，就不一一介紹了。
在數(shù)據(jù)庫層面，接收紅包功能存在高并發(fā)問題，那接下來就簡單介紹下是如何處理并發(fā)的...
3. 并發(fā)處理
是如何處理高并發(fā)問題的呢？
分析：
首先，由于紅包的金額存放在redis緩存隊列中，由于redis是單線程的，那么在獲取紅包的階段不存在并發(fā)問題...
然后，下一步是MySQL數(shù)據(jù)庫一系列的update操作，存在高并發(fā)問題...
最后，是記錄保存，insert操作，也不存在并發(fā)問題...
數(shù)據(jù)庫中update操作，主要應(yīng)用樂觀鎖和X鎖兩種方式來保證數(shù)據(jù)一致性的。
4. 并發(fā)測試
在一段時間的并發(fā)測試中，測試通過，不會出現(xiàn)數(shù)據(jù)不一致問題，紅包回收功能也能正常進行。
目前在并發(fā)方面，至少支持同一時刻并發(fā)量為3000的搶紅包操作不會出現(xiàn)問題。
總結(jié)，由于能力以及技術(shù)有限，目前的方案基本適用用戶量不是很大的應(yīng)用場景，后期隨著用戶量的增大，會進一步的進行優(yōu)化...
感謝閱讀，希望能幫助到大家，謝謝大家對本站的支持！
相關(guān)文章
這篇文章主要介紹了Redis 緩存刪除機制(源碼解析)，文中通過示例代碼介紹的非常詳細，對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價值，需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧2021-03-03
大家應(yīng)該都知道,Redis持久化方式主要有兩種：RDB（Redis DataBase）和AOF（Append-only file）,但是他們各自存儲了什么內(nèi)容？有什么差異呢？今天我來給大家做個小試驗,需要的朋友可以參考下2024-03-03
RedisTemplate是SpringData Redis提供的一個類,本文主要介紹了RedisTemplate常用方法大全,具有一定的參考價值,感興趣的可以了解一下2024-05-05
下面小編就為大家?guī)硪黄獪\談redis在項目中的應(yīng)用。小編覺得挺不錯的，現(xiàn)在就分享給大家，也給大家做個參考。一起跟隨小編過來看看吧2016-12-12
這篇文章主要介紹了Redis批量刪除key的命令詳解,本文給大家介紹的非常詳細，對大家的學(xué)習(xí)或工作具有一定的參考借鑒價值，需要的朋友可以參考下2023-03-03
本文主要介紹了Redis RDB快照持久化及寫操作禁止問題排查與解決,由于?stop-writes-on-bgsave-error?選項處于啟用狀態(tài),所以寫操作被禁止,下面就來介紹一下,感興趣的可以了解一下2025-04-04
本文主要介紹了Redis實現(xiàn)排名功能的示例代碼，文中通過示例代碼介紹的非常詳細，具有一定的參考價值，感興趣的小伙伴們可以參考一下2022-02-02
RedLock?是一種分布式鎖的實現(xiàn)算法,由?Redis?的作者?Salvatore?Sanfilippo（也稱為?Antirez）提出,本文主要為大家詳細介紹了紅鎖RedLock的實現(xiàn)原理,感興趣的可以了解下2024-02-02
這篇文章主要介紹了Redis安裝教程(Windows和Linux),本文通過圖文并茂的形式給大家介紹的非常詳細，對大家的學(xué)習(xí)或工作具有一定的參考借鑒價值，需要的朋友可以參考下2022-03-03
分布式鎖是控制分布式系統(tǒng)不同進程共同訪問共享資源的一種鎖的實現(xiàn)。如果不同的系統(tǒng)或同一個系統(tǒng)的不同主機之間共享了某個臨界資源，往往需要互斥來防止彼此干擾，以保證一致性2022-12-12