一種紅包發送功能的實現（redis+mysql+quartz）

標籤：標記   分享   key   賬戶   隨機   pre   情況   階段   sign   

這篇文章主要是對半年前開發的紅包模組進行整理，把其中主要的設計思想以及具體的實現方案進行介紹，如有設計以及實現上的缺陷，或是存在漏洞，請大家批評指正！

紅包功能大家都很熟悉了，那在這裡就簡單的對紅包功能進行描述... 

功能描述：紅包業務主要的功能包括四部分，分別是紅包發送，紅包接收，紅包回收，以及紅包記錄查詢。

1）紅包發送：寄件者賬戶->紅包中介層

2）紅包接收：紅包中介層->接收者賬戶

3）紅包回收：紅包中介層中若存在紅包留存超過24小時，則將其回收，紅包中介層->寄件者賬戶

功能描述大體瞭解之後，那接下來就是實現方案了... 

首先給出設計流程，這部分將依次對紅包發送、紅包接收、紅包回收的流程進行分析...

1. 設計流程

首先是紅包發送功能，以群紅包為例，其流程圖如下所示：

圖1 紅包發送流程圖

首先，採用基於高斯分布的方法，將金額100隨機的分配成8份，然後將這8份資料存入到redis緩衝隊列(list)中，同時將隊列的到期時間設定成24h；考慮到在搶紅包的時候會出現重複搶的問題，那在這裡採用的去除重複的方案是在redis緩衝中維護一個已指派集合（set），集合裡面儲存的是已經接收過紅包的使用者ID；另外，在大量的使用者同時搶紅包的 情況，出於最佳化方面的考慮，為了起到一定的限流作用，同時減少對資料庫的訪問壓力（考慮這種情況：一個時間段內，大量的使用者在搶紅包，在紅包已經分配完的時刻之後 到來的請求，會給資料庫帶來一定的訪問壓力），那做法是在redis緩衝中維護一個紅包已指派完的標記（key-value）,有0（為分配完）/1（已指派完）兩種狀態，從而起到一定的限流作用。

繼緩衝層面之後，接下來是資料庫層面，那在MySQL中的紅包發送表（account_coin_records_user_coin_package_send）中產生一條記錄，同時呢在把上面經高斯分布方法得到的8份金額插入到紅包分配表（account_coin_records_user_coin_package_assign）中，初始化分配標記為0（未分配），至此，紅包發送的整個流程完成。

然後是紅包接收功能，其流程圖如下所示：

圖2 紅包接收流程圖

紅包接收者發起請求（請求中包含紅包ID、請求人的使用者ID）去搶紅包，首先需要一系列的驗證，這個驗證操作要同時基於redis緩衝以及MySQL資料庫中的資料進行 驗證，主要是驗證紅包ID對應的紅包是否存在、紅包是否已經分配完了、紅包是否已經到期了、紅包接收者是否重複接收紅包等。如果驗證通過，那麼這個使用者是允許接收到紅包的，接下來就是賬戶同步（紅包中介層->使用者賬戶，交易處理），若資料庫操作成功，則紅包接收成功，否則失敗，至此，紅包接收整體流程完成。

最後就是紅包回收功能，其流程圖如下所示：

圖3 紅包回收流程圖

紅包回收是採用定時調度策略發起的，時間間隔為5min不間斷的輪詢訪問MySQL資料庫，查詢是否有待回收的紅包（紅包在紅包中介層留存已經超過24h，且紅包 未 分配完），若有需要回收的紅包，這個時候基於效率方面的考慮，採用多線程方案來進行回收操作，每個紅包對於一個線程，策略是：一個線程，一個請求，一個事務（這 個 方案只適用於待回收的紅包個數不是很多的情況）。（注意：若需要回收的紅包很多，若不斷的申請線程，可能造成記憶體溢出問題，這時候具體問題具體分析，可以考慮生產者-消費者模式）；分布式架構，遠程調用，接下來處理紅包回收的伺服器接收到紅包回收請求後，進行賬戶同步以及紅包狀態標記（標記為已回收），若資料庫事務出現異常，那麼交易回復，此時，這個紅包沒有回收成功，只能等待下一個5min後再次被回收。

到這裡，流程基本介紹完了，那接下來介紹一下資料模型...

2. 資料模型

資料庫用的是MySQL。將紅包記錄進行持久化儲存，用於查詢紅包分配記錄以及後期的記錄查詢。紅包分配的資料模型如所示：

圖4 紅包分配資料模型

圖4中展示了部分的比較重要的資料資訊，表之間的關聯是靠紅包ID建立起來的，紅包記錄以及狀態標記圖中已經標識出來了，就不一一介紹了。

在資料庫層面，接收紅包功能存在高並發問題，那接下來就簡單介紹下是如何處理並發的...

3. 並發處理

是如何處理高並發問題的呢？

分析：

首先，由於紅包的金額存放在redis緩衝隊列中，由於redis是單線程的，那麼在擷取紅包的階段不存在並發問題...

然後，下一步是MySQL資料庫一系列的update操作，存在高並發問題...

最後，是記錄儲存，insert操作，也不存在並發問題...

資料庫中update操作，主要應用樂觀鎖和X鎖兩種方式來保證資料一致性的。

4. 並發測試

在一段時間的並發測試中，測試通過，不會出現資料不一致問題，紅包回收功能也能正常進行。

目前在並發方面，至少支援同一時刻並發量為3000的搶紅包操作不會出現問題。

總結，由於能力以及技術有限，目前的方案基本適用使用者量不是很大的應用情境，後期隨著使用者量的增大，會進一步的進行最佳化...

一種紅包發送功能的實現（redis+mysql+quartz）