前言
但凡商户搞点营销活动，为了能触达更多的顾客，来点儿抽奖的把戏，应该是极好的，什么“刮刮乐”、“砸金蛋”、“大转盘”等等，换汤不换药，屡试不爽。从微客多营销平台各种活动的使用情况也能看出，抽奖活动一直是商户用得最多的线上活动，正所谓无利不起早，给点“花蜜”犒劳下“蜜蜂”也是应该的。
需求分析
那么问题来了，发奖机制怎么玩？作为一个服务商户的营销平台，怎样将商户配置的奖品发出去才能起到比较好的效果呢？
先来看目标，什么是比较好的效果，也就是用户（商户）的需求是什么：
- 抽奖活动期间奖品数量是固定的
- 稀有的奖品尽量靠后被抽中
- 物尽其用，奖品不希望有剩余
- 每个奖品可以设置被抽中的概率
场景模拟
为了讨论方便，我们先把场景假设一下：
抽奖活动时间：
00:00:00-23:59:59
奖品设置：
| 奖品级别 | 奖品名称 | 奖品数量 |
| 一等奖 | A | 2 |
| 二等奖 | B | 3 |
| 三等奖 | C | 4 |
具体分析
第一种能想到的做法就是给每种奖品设置中奖概率，每次按设置好的中奖概率派奖，但是问题又来了：
奖品数量固定，但是参与抽奖的人数不可预知，根本无法控制奖品的消耗速度，如果概率设置高了，抽奖者一拥而上奖品很快就没了，设置低了，奖品可能到最后都发不完。另外，概率这个偏技术的术语用户理解起来肯定五花八门，使用时沟通成本非常高。
而实际上“每个奖品可以设置被抽中的概率”是个十分模糊的说法，说它模糊，主要是因为你并不知道这个设置的概率用在什么地方，这些概率设置需要满足什么条件，总样本数量（总抽奖次数）是多少。
所以最好的做法应该是用户不必关心所谓的“奖品被抽中的概率”，只关注前三个预期效果即可。
经过分析，我们发现，要达到用户上面的那三个效果，只要奖品在活动期间陆续被抽走即可，那能不能给每件奖品设置一个允许被抽走的时间呢？对！如果控制好每件奖品的发放时间点，再安排好各类奖品的发放顺序，大奖不会一开始就抽走，直到活动最后阶段都能保证有奖。
具体设计
顺着这个想法，我们来看具体的设计：
将奖品均匀地埋在整个活动时间（3600*24=86400秒）里，如上面假设场景，一共有9个奖品，则把活动时间均匀的分成9份
以奖品剩余数量作为权重，陆续随机选择每个时间段里的奖品类型（颜色对应的奖品见上表）
在每个时间段里随机选择奖品的“释放”时间点，一是为了均匀，二是避免直接暴露精确的时间点
|
1 |
releaseTime(n)=startTime+(n-1)× ∆t+random(∆t) |
实现方案
说完思路，我们再看实现：在奖品释放时间点之后的抽奖用户就有机会（这个概率可配置，如100%或者80%）拿到该时间段的奖品，如果奖品未被抽走，将继续等待抽奖者的到来。
思路一
直观的做法是建立三张表
t_award_batch（奖品描述表，用于记录各种奖品的配置信息），
| ID | 名称(name) | 奖品总量(amount) |
| 1 | A | 2 |
| 2 | B | 3 |
| 3 | C | 4 |
t_award_pool（奖池表，用于生成每一次奖品释放的时间点），
| ID | 奖品ID(award_id) | 释放时间(release_time) | 剩余数(balance) |
| 1 | 3 | 1:03:27 | 0 |
| 2 | 2 | 3:15:13 | 1 |
| 3 | 3 | 5:29:57 | 1 |
| 4 | 2 | 9:35:34 | 1 |
| 5 | 1 | 12:57:20 | 1 |
| 6 | 2 | 13:47:03 | 1 |
| 7 | 3 | 17:31:50 | 1 |
| 8 | 1 | 18:13:26 | 1 |
| 9 | 3 | 22:28:40 | 1 |
t_record（抽奖记录表，用于记录每次抽奖者的抽奖记录）
| ID | 奖品ID(award_id) | 中奖时间(hit_time) | 用户ID(owner_id) |
| 1 | 3 | 1:03:45 | peteryan |
活动开始前，根据t_award_batch中的奖品配置信息，初始化t_award_pool中的数据，把每种奖品的释放时间初始化好，用户来抽奖时，根据当前时间在t_award_pool表中的查询到一条已经释放而且未被抽掉的奖品
|
1 |
select id from t_award_pool where release_time <= now() and balance > 0 limit 1 ; |
查询到后对其进行更新，如果被他人抢走，则未中奖
|
1 |
update t_award_pool set balance = balance – 1 where id = #{id} balance > 0 ; |
同时留下抽奖情况到t_record中。
思路二
在思路一中，为了方便抽奖时判断当前是否有可中奖品，进行了初始化每件奖品的释放时间，当奖品数量比较小的时候，情况还好，对于奖品数非常多的时候，抽奖的查询耗时会增加，初始化奖池也是耗时的动作，是否可以不依赖这个表之间通过实时计算判断当前是否有奖品释放。
在t_award_batch表中添加两个字段，奖品总剩余量balance和上一次中奖时间last_update_time。
| ID | 名称(name) | 奖品总量(amount) | 奖品余量(balance) | 更新时间(last_update_time) |
| 1 | A | 2 | 2 | 1:03:45 |
| 2 | B | 3 | 3 | 0:00:00 |
| 3 | C | 4 | 3 | 0:00:00 |
这样具体实现上仅需要依赖奖品配置信息即可，示例代码如下（点击图片全屏查看）：
其中awardBatch表示一类奖品，如上表中提到的一等奖。上面代码中，随机选出下一个待释放的奖品逻辑如下：
通过这套发奖机制，很好地满足了营销商户的目标，同时减少了对复杂概率计算的纠结，再也不用担心奖品被提前抢光了。
转载自：微客多 – 腾讯 | KM平台
long detaTime = (endTime – startTime) / currentamount; 为什么是除以currentamount, 不是应该除以各种商品的总数吗?
还有long releaseTime = startTime + (currentamount – currentBalance) * detaTime + Math.abs(rand.nextLong())%detaTime 中间的这个时间因子 (currentamount – currentBalance) 好像取值在[0,4]之间吧，而奖品的总数是9个。你会有4个奖品发不出去？
坑爹啊，差点被你误导了
还有long releaseTime = startTime + (currentamount – currentBalance) * detaTime + Math.abs(rand.nextLong())%detaTime 应该是* detaTime。 这里写错了吧
感觉实现的思想很灵性，用时间去控制用户抽奖，但是如果奖品种类和数量较多时，性能不是很好。
有没有JAVA的DEMO？
感觉自己在这里的触发条件始终不能找到一个合理的方式
思路二中的执行是靠什么触发呢？每次抽奖后还是定时任务呢？
这个有php版本的demo么？
木有哦
仔细研究了一下楼主的算法，发先楼主对语法的一些使用技巧是如此精湛，佩服楼主在编程方面的造诣。！赞
很好，原来就有这个想法，但是比较模糊，看到这个顿时悟了
微信功能越来越强大了
如果一个时间段结束了还没有人抽到奖品，那这个时间段的奖品会不会留到下一个时间短呢