今天想和大家談談類似餘額寶功能的體系設計，用支付寶的人基本都知道餘額寶這個功能體系，簡單的來說就是，你把錢從餘額轉到餘額寶中去的話，過幾天之後就可以得到對應的收益。今天和大家介紹的，就有點型別這個模式。下們我們具體來看看是怎麼設計實現的。

返還功能背景：

現在大部分商城平臺的積分，大多數都很雞肋，使用者對積分的敏感程度也特別低，為了提升積分的價值，這邊我們設計一個，型別餘額寶分潤功能，積分可以用來每天返現，返現的金額既可以用來購買商品，也可以提出出來。

返還需求：

使用者在商城平臺消費之後，會獲得對應的積分，這個時候使用者可以將賬戶裡的積分轉入到返還賬戶中（類似餘額轉餘額寶），轉入的積分都會有個收益生效時間，每天凌晨就會開始跑批，給平臺所有使用者分潤對應的現金，分潤的現金可以提現到銀行卡中，也可以進行購買消費。返還賬戶中的積分也可以轉出到賬戶中。大致的功能就這些，過程中返還比例之類都要求是可控的，原型圖如下所示：

app功能就簡單一點了，只有轉入、轉出、檢視分潤明細的功能。

返還流程圖：

我們先來看一下積分返還現金流程圖，這裡面的應分等同於積分。

這裡面有三個部分，一個是使用者原有積分賬戶，一個是專門返還的賬戶，最後一個就是運營平臺配置模組了。使用者將積分轉入返還賬戶中（會有一個最低轉入金額），然後到達跑批時間時候，系統會去獲取全域性的返還配置資訊和個人的返還配置資訊，將對應的收益跑批到對應的使用者中，最後流程結束。

返還功能設計：

根據需求和流程圖，我們需要設計：一個表來儲存返還賬戶資訊，一個表用來儲存返還配置資訊，一個表用來儲存返還分潤明細資訊，最後一個比較特殊：用來儲存返還分潤資料資訊，因為每天凌晨我們會去跑每天積分對應的返還收益，這些資料需要從返還賬戶中快照到返還跑批任務表中，跑批完成後隔天刪除這部分的資料。鑑於上面的分析，我們可以設計如下的表：

返還技術要點：

因為涉及到錢，所以技術分析的時候要全方位、各種可能的考慮。介面我們這邊可以分為：查詢型別介面、修改型別介面、跑批型別介面，下面我們來一一介紹。

1.查詢型別介面

關於查詢類介面，第一階段我們主要考慮效率和資料正確性就可以，查詢效率主要體現在app響應速度上面，這邊我們可以先把對應索引加上去，如果資料量特別大的情況下可以採用分庫分表來解決。

2.修改型別介面

修改型別介面一定要考慮介面的冪等，還有就是修改介面會不會有關聯操作，需不需要加併發鎖進行控制。比如上面流程中轉入和轉出操作就必須有這些限制，轉入的時候需要判斷賬戶餘額是否夠轉入，還有轉入的時候賬戶積分需要加鎖凍結，不能同時有其它的操作。

3.跑批型別介面：

跑批型別介面一般指的是定時任務介面，我們這邊有一個最核心的介面，就是上面的分潤介面，我們需要計算平臺所有使用者的返還積分，算成錢之後，再給到對應的使用者上面，如果平臺有10w個使用者，我們就必須執行10w次分潤。如果資料量大的情況下，一臺服務肯定跑不完，所以我們需要用分散式排程模式，起多個服務同時進行任務排程，這邊大家可以參考elastic-job這個分散式任務排程框架。

總結：

大家在設計這個方案的時候一定要注意分潤跑批執行的時候，要進行轉入、轉出限制，跑批時間內，不然會對增加專案複雜度和不可控性。複雜的操作可以放在後期優化升級中完成，一開始可以在產品上面做一些限制。還有就是轉入、轉出是，一定要進行先查詢對應賬戶是否數值夠扣，先select在update，千萬不要拿app傳過來的賬戶總額來判斷。好了今天的內容就介紹到這邊了，謝謝大家的閱讀～

要更多幹貨、技術猛料的孩子，快點拿起手機掃碼關注我，我在這裡等你哦~