redis+mysql+quartz 一種紅包發(fā)送功能的實現

更新時間：2017年01月19日 11:34:33 投稿：lqh

這篇文章主要介紹了redis+mysql+quartz 一種紅包發(fā)送功能的實現的相關資料,需要的朋友可以參考下

概要：

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

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

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

1）紅包發(fā)送：發(fā)送者賬戶->紅包中間層

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

3）紅包回收：紅包中間層中若存在紅包留存超過24小時，則將其回收，紅包中間層->發(fā)送者賬戶

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

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

1. 設計流程

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

圖1 紅包發(fā)送流程圖

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

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

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

圖2 紅包接收流程圖

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

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

圖3 紅包回收流程圖

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

到這里，流程基本介紹完了，那接下來介紹一下數據模型...

2. 數據模型

數據庫用的是MySQL。將紅包記錄進行持久化存儲，用于查詢紅包分配記錄以及后期的歷史記錄查詢。紅包分配的數據模型如下圖所示：