這么做，一方面為了體現(xiàn)產(chǎn)品體驗(yàn)的稀缺性，鼓勵用戶搶購，造成供不應(yīng)求的輿論影響。這點(diǎn)小米做的尤為突出，效果也是相當(dāng)不錯的。另一方面，先讓一部分比較有熱情的早期種子用戶進(jìn)來，也能夠充分的對產(chǎn)品的易用性和體驗(yàn)流程進(jìn)行早期的驗(yàn)證，方便手機(jī)用戶的反饋之后迭代修改。·

我們首先來看看根據(jù)需求邀請碼服務(wù)需要提供出哪些接口：

 

單個或批量的生成邀請碼，要求六位，數(shù)字與字符的混合，供運(yùn)營和用戶使用；

給用戶激活邀請碼；

校驗(yàn)用戶是否已經(jīng)激活邀請碼；

批量給已注冊用戶綁定幾個可用的邀請碼，方便二次傳播；

查詢用戶名下已經(jīng)綁定的邀請碼和其被激活的情況，驗(yàn)證二次傳播的效果

 

根據(jù)需求，現(xiàn)有的技術(shù)實(shí)現(xiàn)方案有很多，核心來講的話主要有兩點(diǎn)：

 

邀請碼生成算法與唯一性保證

邀請碼高效查詢與激活

 

另外還有一些其他的點(diǎn)，會在文中慢慢道來。

邀請碼的生成方式

產(chǎn)品的要求是六位，同時字母和數(shù)字混合的方式，一共會發(fā)放10000個左右。一開始的思路是使用純算法的方式實(shí)現(xiàn)，通過生成唯一的ID，增加一些共性的信息，再根據(jù)信息摘要的方式，映射成字母與數(shù)字的混合，不過試了一下，算法實(shí)現(xiàn)的成本比較高，而且還有借助額外的唯一ID生成的工具，所以有些得不償失。

另外由于不能是純數(shù)字，所以十六進(jìn)制映射的方案也無法進(jìn)行。而且也不能是一長串的字符，這樣md5的方案也無法實(shí)施了。

所以在這樣的前提之下，決定使用簡單算法+redis來做整個方案。

首先是邀請碼的生成，由于生成的過程一般是后臺或者手動觸發(fā)，所以對性能的要求并不太高，也就是說，允許一定程度的碰撞。所謂的碰撞，就是算法算出來的邀請碼，和已經(jīng)生成的邀請碼重復(fù)了。所以我們來算一下概率：

一共是六位的邀請碼，每一位的組成是大小寫字母+阿拉伯?dāng)?shù)字，也就是26+26+10=62種可能性。所以六位也就是一共能夠產(chǎn)生出62^6=56,800,235,584即560億個邀請碼，產(chǎn)品的要求是一共放出去一萬個，所以即使現(xiàn)在已經(jīng)有一萬個邀請碼被生成了，那么生成一個邀請碼和現(xiàn)有邀請碼重復(fù)的概率只是10000/560億, 非常低的概率，如果真的中了大獎，那么就進(jìn)行二次生成，再次碰撞的概率，恐怕就更低了。

同時為了保證邀請碼看起來更真實(shí)，再增加一個連續(xù)兩位不能重復(fù)的驗(yàn)證，同時每次生成結(jié)束之后，使用redis驗(yàn)證是否唯一，即可實(shí)現(xiàn)整個邀請碼的生成過程。

數(shù)據(jù)結(jié)構(gòu)的設(shè)計(jì)

上文說到為了保證邀請碼的唯一性，必須使用redis，redis中的集合數(shù)據(jù)結(jié)構(gòu)就提供了很好支持。每次生成完成后，只需要調(diào)用isMember validatorSet方法，即可根據(jù)返回判斷是否已經(jīng)生成了邀請碼。

同時使用集合存儲邀請碼，也能夠滿足統(tǒng)計(jì)的需求，只需要定時執(zhí)行smembers validatorSet，即可統(tǒng)計(jì)出所有生成出來的邀請碼。

另外，由于存在用戶激活邀請碼，和查詢是否已經(jīng)激活邀請碼的尋求，所以必須對此設(shè)計(jì)專門的數(shù)據(jù)結(jié)構(gòu)。查詢需求是高頻需求，在用戶量比較大的情況下，會有比較大的訪問壓力。同時為了擴(kuò)展可能存儲的用戶其他信息，所以使用散列的數(shù)據(jù)類型進(jìn)行存儲。

每次查詢用戶是否已經(jīng)激活，只需要執(zhí)行hget user:$guid validator 即可獲取其中的邀請碼信息，從而判斷出用戶是否已經(jīng)激活。

而用戶激活的過程，涉及的數(shù)據(jù)結(jié)構(gòu)稍多，每次激活的過程，都需要分成幾步：

第一步是查詢這個邀請碼是否是合法有效的邀請碼，需要使用ismember validatorSet進(jìn)行判斷;

如果合法有效，第二步是設(shè)置用戶的激活狀態(tài)，即上文中所用到的這個散列hset user:$guid validator {$validator};

第三步則是設(shè)置邀請碼本身的狀態(tài)，即這個邀請碼被哪個用戶用了，方便之后查詢 set validator:{$validator}:status {＇userName＇:ted,＇avatar＇:＇http://test.com＇}

由于第二步和第三步必須保證數(shù)據(jù)的冪等性，因此需要使用redis的事務(wù)來進(jìn)行執(zhí)行，保證兩者能夠同時成功的被執(zhí)行：

$redis->Multi()

->set validator:{$validator}:status {＇userName＇:ted,＇avatar＇:＇http://test.com＇}

->hset user:$guid validator {$validator}

->exec()

 

但是除了使用事務(wù)，還需要規(guī)避的就是兩個用戶同時取到了同一個邀請碼，在同一時間進(jìn)行了激活的操作，在高并發(fā)的情況下，會有原子性的問題。所以必須引入redis中的watch命令，監(jiān)控邀請碼的status這個key，保證一旦它被變更了，那么當(dāng)前的事務(wù)就不再執(zhí)行，從而避免給用戶帶來錯誤的反饋：

redis->watch validator:{$validator}:status

由此，就完成了用戶邀請碼的激活過程。

除此之外，還有個小功能，那就是給一批種子用戶綁定幾個邀請碼，并在邀請碼被激活之后，展示出相應(yīng)的狀態(tài)。剛剛說到了用戶為維度的那個哈希表結(jié)構(gòu)，是時候給它再加一個field了，這個field就叫boundValidators，專門用來存儲用戶名下被綁定的邀請碼：

hset user:$guid boundValidators $validator1|$validator2...

那么查詢的時候只需要進(jìn)行兩次查詢：

// 查詢用戶名下綁定的邀請碼

hset user:$guid boundValidators

// 查詢邀請碼是否以及被誰激活了

mget $boundValidators

 

為了降低網(wǎng)絡(luò)延時，完全可以通過一個pipeline實(shí)現(xiàn)，從而使得網(wǎng)絡(luò)交互從兩次變成一次。

接口性能驗(yàn)證

由此已經(jīng)大功告成，簡單的使用wrk測試一下性能，服務(wù)器相比之前的差一些，一共是4核16G內(nèi)存。使用wrk -t12 -c100 -d10s http:ip:port/queryActivate，

海外內(nèi)網(wǎng)、同步的redis調(diào)用：

 

QPS在5000左右，完全滿足了本次邀請碼的需求，事實(shí)上，如果能超過這個量，估計(jì)睡覺都要笑醒了:)