會員積分功能模型設計

最近在開發中遇上一個會員（用戶）積分的場景，我在網上查找相關設計文章，并沒有發現合適的方案，所以在此寫下我思考和設計的過程，供程序猿們參考。

積分管理這一功能，已經算是十分常見，夸張點說是爛大街了的場景，但仔細分析后，發現要做好也不容易，得考量多個細節，對初級程序員來說，也算是一個很有意義的練習題目。以下內容，沒有一行代碼，沒有一張圖表，也沒有設計文檔參見的模式套路，對一些人來說，讀之枯燥，但是，如果您對“設計”工作有興趣，相信我，不妨一讀。

因為不是專業做CRM或銷售領域的，對“會員積分”的需求了解并不深，這里僅僅是對一般的需求場景進行分析設計，權當拋磚引玉，如果有更多復雜需求，還請留言，不吝賜教。

需求概要

假設某企業引入會員積分業務。會員有多種渠道獲得積分，另外還可以兌換積分。此外，積分有有效期，每項積分6個月不兌換，則自動失效。

請設計一下數據模型結構和基本業務邏輯。要求能計算會員的總積分、當前有效積分、最近7天內要到期的積分，能統計每月、每季度、每年的積分發放、消費、剩余情況。

接下來，我們來將需求細化，一步步完成對應的設計。

需求一 記錄積分獲取和積分消費

創建一個對象，里面記錄用戶id，獲得積分，原因等等，再記錄時間，就可以了。所以我們有了第一個實體模型：【積分記錄】

同樣的，積分消費，用一個對象記錄消費情況，也記錄消費積分、內容、時間等。然后我們發現積分消費可以用積分記錄模型，只是分數為負數就好。

需求二 積分消費校驗和積分統計

要統計某用戶積分，將他的積分記錄查詢出來，對積分字段求和就好。

在做積分消費時，查詢用戶之前積分合計，如果分數小于要消費的積分，就返回不允許消費。

需求三 積分過期

接下來考慮積分的有效期需求，比如積分以年為固定周期，每年將去年積分失效，或者每筆積分的有效期都是一年。我們先按后面一種情況考慮。

首先積分過期可以使用定期執行的策略，查詢積分記錄，進行過期處理。

很直觀地，在積分記錄里面，增加一個字段，記錄過期時間。定期檢查過期時候，判斷過期就號。但是，如果這筆積分被消費了，那么就不存在過期的概念了，如果繼續按過期處理，那么積分統計時，無法區分這筆是否被消費過，即需求2不能滿足。

一種方案，將消費時消費了之前哪些積分記錄下來，但是這種方式的計算量大，額外增加不少存儲空間，并不好。

另一種方案，在積分記錄里面增減一個“剩余積分”字段，用戶的有效積分改為“剩余積分”字段的合計。積分消費時，按時間順序取積分記錄，逐條扣減剩余積分。積分過期時，簡單地把剩余積分清零就好。

積分統計就改為統計【積分記錄】的“剩余積分”字段。

但是這仍然有個問題，我們看下一條需求。

需求四 求截止上月的積分統計

之前的方案，能解決當前實時的積分統計，但是假設某用戶上個月有條記錄未過期，但這個月過期，剩余積分為0，這時候我們就統計不出上個月的積分情況了。這是因為“剩余積分”里面記錄了被消費扣減的積分和過期的積分，無法區分，“過期時間”這個信息還不足夠，除非我們再增加字段，將消費扣除的積分和過期扣除的積分區分開來，算上個月積分時，排除過期時間晚于1號的過期積分記錄。

但是這樣一來，積分的業務規則就相當復雜了。為此我們調整一下方案。

首先，將積分過期也視為一條【積分記錄】，積分過期就增加一筆“過期”的【積分記錄】。之前引入的“剩余積分”字段取消。然后增加一個【積分賬戶】實體模型，里面有一個指針，指向最后一條被扣減的積分記錄，以及該記錄的剩余積分。比如有某用戶有10條積分獲取記錄，每條積分都是10分（id從1-10），然后消費一筆35積分，那么 記錄最后一次消費積分時，積分指針id=4，該記錄剩余積分等于5。然后，假設第二天前5條都過期了，那么【積分賬戶】里的指針指向id=5，剩余積分0。

同時，我們將用戶的總積分、剩余積分也存在【積分賬戶】里，獲取這個信息時候就不用再從【積分記錄】里面去計算了。

要統計截止上個月的積分，只需要查詢【積分記錄】里截止上個月的記錄，匯總積分字段即可。

要統計近期過期積分，查詢【積分賬戶】里指針之后的記錄，并且滿足近期過期條件的即可。

假設數據有異常，需要調整某個用戶很久以前的一筆積分，那么【積分賬戶】是能被重新計算出來的，取出所有積分獲取記錄，積分消費記錄，按時間順序，逐條執行積分賬戶消費處理和積分過期處理就行。

最后，羅列一下需求，如果你有其他設計思路，看看是否滿足以下需求：

能記錄用戶獲取積分的明細信息并展示；

能記錄用戶獲取積分和消費積分的明細信息并展示；

消費積分時，要檢查積分余額是否大于等于要消費的積分；

積分有有效期，過期失效；

能統計用戶的總積分，剩余積分，能提醒用戶近期過期積分；

能統計之前某個時間點比如上個月的積分情況；

能支持調整之前的積分數據；

能滿足數據量較大或巨大的場景；

補充，高并發大數據量如何處理

高并發場景，可能要引入負載均衡部署，這時候一般的處理邏輯會引入并發問題，對此業內有很多對應方案了，簡單的處理辦法，使用消息隊列，將并發請求轉換為單一隊列（串行）。這里給出一個簡單方案。

首先，所有增加和消費積分的請求，都發送到 redis 里（把 redis 當作消息隊列用）。然后，部署一個應用專門處理積分檢查和持久化操作，按順序執行請求即可，這樣就不會有并發沖突了。如果一個應用處理還是不夠，那么也可以部署多個應用，在處理積分請求時，針對這個用戶id加鎖（把 redis 當作分布式鎖），完成后解鎖。

大數據量場景，可以考慮按年/月將積分記錄轉移到歷史記錄表，降低【積分記錄】表的數量量即可。

總結

以上是生活随笔為你收集整理的会员积分功能模型设计的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。