千萬使用者禮品發放設計

一、概述

今天我們探討一下使用者禮品發放的問題。

假設1000W使用者，需要儲存使用者資訊。

使用者每天登入隨機贈送10個禮品，連續30天。

這個業務場景的架構會涉及到一定的資料結構和演算法。與之相關的還有很多話題，比如一個檔案儲存1億的手機號碼（QQ號），如何去重等。他們都屬於是一類問題。在進一步討論這個問題之前，我們需要先了解一些基礎常識，例如QPS、PV、UV、TPS、頻寬等。

QPS簡單的講就是1s可以處理的請求數。

一般來講qps在500以下就是普通的專案，如果只是一些OA的話，可能在100左右徘徊。

如果有對外小型商城，普通的專案可能能夠達到200qps。

qps500就是一個高併發的專案了。

它所對應的使用者量一般在1000W左右，峰值qps高一點可能達到1k。

那我們到底應該如何去計算呢？

以專案1000WPV為例，在業界裡有28原則，基於28原則、一天的時間80%使用者訪問集中在20%的時間範圍內，也就是80%的使用者集中在4。8個小時內訪問既一天中有20%的峰值，28原則QPS常用公式如下：

QPS=（PV*0。8）/（86400*0。2）。

既1kwPV的QPS=（1kw*0。8）/（86400*0。2）=462。96。

需要說明下，這是計算一個網站的QPS，既專案平時執行所承載的QPS，並非系統的最高QPS。

網站頻寬對專案併發量會產生非常大的影響。

1M/S的寬頻下載速度多快、假設網頁大小為30kb不計算其他因素、

併發量多大？

通常所說的1M寬頻的理論速度

就是1Mbit/s=1024 Kbit/s=128 KByte/s=128

KB/s；

如果一個網頁的大小在最佳化後為30kb、那麼1M頻寬可支撐4個使用者在1秒內同時打卡網頁，所

以1M頻寬1秒內的併發數為4、根據網站8S的原則（使用者會等待網頁8s時間，如果超過就會關閉網站），

在2s內1M寬頻可支援

8個使用者以此類

推；

理想上一天86400秒，一天可支撐34萬IP、但不現實；

一般網站一天訪問量高峰集中在上午9點到11點、下午3點到5點和

晚上8點到10點，這個時間段併發數4也是不小

的訪問量。

如果網站日均IP20

00左右，使用的就是1M頻寬的雲伺服器基本足夠。

PV、UV、TPS等就不在這裡贅述了。大家可以自行了解下。

二、禮品發放設計

1、概述

假設1000W使用者，需要儲存使用者資訊，使用者每天登入隨機贈送10個禮品，連續30天，資料表應該咋樣設計呢？首先從資料量分析，1000W萬代表的磁碟儲存空間大約為1000W*10*30*60=180億位元組大約需要17G的磁碟儲存空間。其中60是預估

使用者禮品關聯表

一條儲存記錄大概需要的位元組數。使用者禮品關聯表user_gift［id，uid，gid，uname，gname］中，只有領取到禮品的使用者才可以記錄進去，這個表會是一個上億的資料表，所以這個id肯定是唯一的。每一個欄位預估的位元組數為id［

16byt

e

］、使用者uid［

16byt

e

］、禮品gid［

4

byte

］、使用者名稱稱uname［

1

6byte

］、禮品名稱gname［

16

b

yte

］，所以一條記錄的位元組數約為60byte。

如上以1000W使用者為例，一天能產生1000W的資訊嗎？

如果我們以28原則來算，實際上僅有200W的使用者量。

我們給的高一點，假設每天的資訊量為500W。

一個專案中一半的使用者都會來領取。

則實際儲存量為90億位元組，約佔8。5G磁碟空間大小。

在實際的業務場景中我們可能還需要考慮如下幾點：

使用者列表中那些是否領取和領取詳情，未領取的需要提醒領取下等；

根據活動統計，某一天領取禮品使用者量和未領取量；

統計從未參加活動的使用者等。

2、設計

使用者表user［id，username］的設計大體如下：

這裡我們僅僅探討的是元資料的儲存。一個分庫分表只有一個方案，所以這裡不一定是id取模，也可以用常見的使用者名稱取模。那如果有其他的查詢咋辦呢？我們可以用資料異構，拿空間換時間，否則就會產生全表掃描的問題。同樣的思維，訂單表可以根據商家異構。也可以根據使用者異構。這是在很多專案中常會用到的策略。

使用者禮品關聯表設計

關聯表

user_gift

的設計可以透過uid進行取模進行資料異構儲存，這裡最好是異構儲存在mongodb中，每個user下面有多個gift，這樣效能會更好。

2。2、某一天領取禮品統計

既某一天領取禮品使用者量和未領取量，這裡會涉及到記錄表record【id、時間time、使用者資訊uids】，他佔用的空間比較高，所以這裡最好儲存的是點陣圖bitmaps。業務大體流程如下：

參與活動使用者的uid透過位運算得到一個二進位制01的點陣圖標識，用1標識該使用者參與過贈送禮品活動。最終我們需要儲存的是一組01標識的點陣圖。用int32基本上可以解決這個問題。點陣圖也可以有多個，第一次就是計算在下面的按個位圖裡面，第二次計算在點陣圖的那個細節。這樣儲存就基本上搞定了。磁碟空間也省下來了。1億的儲存大約需要12M的空間。當判斷每一天使用者的領取情況時，可以按照天查詢使用者後，把uid放在位圖裡，看這個uid是否在位圖裡。如果是1就領取，否則就沒有領取。當統計從未參加活動的使用者的時候，同樣是位運算。不過這裡需要使用的是異或位運算。到此我們前面提出的幾個業務場景問題就能夠得以解決了。

當然針對禮品發放業務場景和細節可能還有很多，也還有很多方案和解決策略，這裡只是針對其中的幾個點闡述了一些觀點，仁者見仁智者見智，

我這裡就不贅述了。總之

適合大家實際業務場景和具體情況的策略就是最好的策略。