前言：
红包是支付的方式, 也是社交的延伸。群红包在这两块领域串联得很好, 表现尤为的浓墨重彩.
承接上两篇技术浅谈:
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
原创文章，作者：stanley，如若转载，请注明出处：http://www.178linux.com/847
评论列表（1条）
看到这算法，隐隐有种高数的感觉~ 😮