淺談群紅包的實現



前言:
  紅包是支付的方式, 也是社交的延伸。群紅包在這兩塊領域串聯得很好, 表現尤為的濃墨重彩.
  承接上兩篇技術淺談:
  1). 淺談接龍紅包的技術實現.
  2). 淺談微信紅包搖一搖的技術實現.
  這一次, 讓我們談談群紅包的技術實現. 一為是紅包的分配算法, 二為競搶的技術實現.

分配算法:
  最初玩群紅包的時候, 並沒有意識到分配算法的難度. 下意識的覺得, 不就是個隨機算法嘛? so easy! 后來在知乎上看到很多人在討論, 才意識到該算法或許並不簡單.
  好的東西, 往往讓人覺得簡單, 而其背后默默挨打的小怪獸(精細和縝密), 你是否可曾留意過.
  我們先來看看, 最自然的隨機算法, 為何不合理?
  假設T為總金額, k為紅包個數, 每次獲取先保底(每人至少得最小金額為0.01), 然后取隨機剩余數
  則Ai的迭代公式為:

Ai = random(0.01, T - 0.01 * (k - i) - A0 - … - Ai-1)           (0 <= i < k - 1)
Ak-1 = T - A0 - … - Ak-2                                        (最后玩家所得)

  貌似簡單合理, 殊不知頭重腳輕, 統計概率上, 排前面的值往往大於排后面的值, 當k很大, 最后幾位往往會被收斂為0.01.
  顯然不合理, 這篇<<微信紅包的算法實現探討>>博文也證述了該現象. 

  結合上面的例子, 一個好的分配算法, 必須具備以下幾個條件:
  1). 每個玩家都能領到紅包
  2). 所有玩家的紅包錢數和等於總數
  3). 無論哪個順序位, 在紅包分配上的概率是平等公平的
  對了條件(3)的解讀, 可以這么理解, 每個順序位的預期紅包分配數為N/k (N為紅包總素,k為用戶數). 一次分配差異大, 但統計重復M次, M越大, 預期平均值越接近N/k. 這就是宏觀上的平等.

  有人就以平均值做突破口, 引入截尾正態分布, 達到了非常好的效果.
  
  詳細見<<微信紅包算法探討>>這篇博文, 這邊具體也不展開了.

  工程的角度, 我們可以簡化算法, 用擬合的算法來近似代替.
  概率函數為:

對於第i個玩家而言
隨機生成(k-i)個 Bj (j=0,1,k-i-1), Bj范圍在[0, 100]之間.
則概率函數P(i) = Bi / (B0 + B1 + ... + Bk-i-1)

  對於Ai, 則迭代公式為:

Ti = T - 0.01 * (k - i) - A0 - … - Ai-1
則Ai = Ti * P(i) + 0.01 = Ti * Bi / (B0 + B1 + ... + Bk-i-1) + 0.01

  因為使用加減乘除, 比用高級概率分布的sin/cos/log函數計算效率要高.

競搶技術:
  群紅包的"搶奪", 最重要的還是數據安全問題.說白了就是競態條件下, 如何保證數據完整性和一致性
  業內對該類問題, 有大致三種主流的做法:
  1). 悲觀鎖思路
  2). FIFO隊列思路
  3). 樂觀鎖思路
  悲觀鎖思路, 常見的是借用mysql的SELECT ... FOR UPDATE語句來實現.

begin transaction;	      // (1)開啟事務
select ... for update;	     // (2)鎖定某行記錄
update ... set ... where ...;  // (3)進行記錄更新
commit transaction;	     // (4)事務提交 

  這邊重點講講樂觀鎖機制, 其不光能用於關系數據庫,也能用於NoSQL.
  樂觀鎖的核心思想是, 基於版本號的更新, 前提是操作需保證原子性.
  設計簡化的紅包表:
  
  注釋: total_money為總金額, total_number為紅包數, left_money為剩余金額數, left_number為剩余紅包數
  當用戶拆紅包時, 觸發如下流程
  (1) 查詢群紅包信息

SELECT left_money, left_number, version_id 
FROM tb_hongbao 
WHERE envelope_id = '?';

  (2) 計算所分配的紅包
  通過上述的方法, 通過left_money, left_number計算出具體的紅包: delta_money
  (3) 更新群紅包信息

UPDATE tb_hongbao
SET 
    left_money = left_money - delta_money, 
    left_number = left_number - 1, 
    version_id = version_id + 1
WHERE 
    envelope_id = '?' AND version_id = 'old_version_id'

  SQL是能保證原子性的, 帶着上次查詢回來的version_id去更新, 若version_id一致, 則更新成功, 版本號遞增, 若不一致, 則需要重復1~3步, 直至成功或放棄.
  這邊講述的利用mysql來實現的, 事實上有些Nosql系統也支持(大淘寶的Tair服務).

寫在最后:
  如果你覺得這篇文章對你有幫助, 請小小打賞下. 其實我想試試, 看看寫博客能否給自己帶來一點小小的收益. 無論多少, 都是對樓主一種由衷的肯定.

  

 


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM