浅谈群红包的实现

前言:
红包是支付的方式, 也是社交的延伸。群红包在这两块领域串联得很好, 表现尤为的浓墨重彩. 
承接上两篇技术浅谈:
1). 浅谈接龙红包的技术实现.
2). 浅谈微信红包摇一摇的技术实现.
这一次, 让我们谈谈群红包的技术实现. 一为是红包的分配算法, 二为竞抢的技术实现.

分配算法:
最初玩群红包的时候, 并没有意识到分配算法的难度. 下意识的觉得, 不就是个随机算法嘛? so easy! 后来在知乎上看到很多人在讨论, 才意识到该算法或许并不简单. 
好的东西, 往往让人觉得简单, 而其背后默默挨打的小怪兽(精细和缜密), 你是否可曾留意过.
我们先来看看, 最自然的随机算法, 为何不合理?
假设T为总金额, k为红包个数, 每次获取先保底(每人至少得最小金额为0.01), 然后取随机剩余数
则Ai的迭代公式为:

1
2
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. 这就是宏观上的平等.

有人就以平均值做突破口, 引入截尾正态分布, 达到了非常好的效果.
浅谈群红包的实现
详细见<<微信红包算法探讨>>这篇博文, 这边具体也不展开了.

工程的角度, 我们可以简化算法, 用拟合的算法来近似代替.
概率函数为:

1
2
3
对于第i个玩家而言
随机生成(k-i)个 Bj (j=0,1,k-i-1), Bj范围在[0, 100]之间.
则概率函数P(i) = Bi / (B0 + B1 + … + Bk-i-1)

对于Ai, 则迭代公式为:

1
2
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语句来实现.

1
2
3
4
begin transaction;        // (1)开启事务
select … for update;       // (2)锁定某行记录
update … set … where …;  // (3)进行记录更新
commit transaction;      // (4)事务提交

这边重点讲讲乐观锁机制, 其不光能用于关系数据库,也能用于NoSQL.
乐观锁的核心思想是, 基于版本号的更新, 前提是操作需保证原子性.
设计简化的红包表:
浅谈群红包的实现
注释: total_money为总金额, total_number为红包数, left_money为剩余金额数, left_number为剩余红包数
当用户拆红包时, 触发如下流程
(1) 查询群红包信息

1
2
3
SELECT left_money, left_number, version_id
FROM tb_hongbao
WHERE envelope_id = ‘?’;

(2) 计算所分配的红包
通过上述的方法, 通过left_money, left_number计算出具体的红包: delta_money
(3) 更新群红包信息

1
2
3
4
5
6
7
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服务).

写在最后:
如果你觉得这篇文章对你有帮助, 请小小打赏下. 其实我想试试, 看看写博客能否给自己带来一点小小的收益. 无论多少, 都是对楼主一种由衷的肯定.

转自: http://www.cnblogs.com/mumuxinfei/p/4305979.html

相关新闻