系统介绍
一元夺宝项目,前段时间非常火;出现了很多夺宝平台,最近由于市场的监管,确实少了很多;夺宝模式其实非常简单,类似于彩票;就跟有个段子说的:大家每人给我发10元,每满50元将抽出一名幸运用户,奖励40元;搏一搏,单车变摩托;
一个价值1000元的商品,平台将价格提高到1100元;然后大家一起来凑钱买,满了1100元后,抽取一个人获得此商品;平台的盈利模式也简单明了;直接获取市场价差额,另外夺宝量大也可以获得更加低廉的进货渠道;同时,有些夺宝中奖用户也会通过低价折现的方式,将商品回购给平台;
我们也打算做了一个类似的项目,当然我们的目的更加纯粹一些,并不是为了赚钱,目的在于活跃社区用户氛围,将用户在社区活跃所赚取的虚拟货币用来夺宝投注,通过夺宝的方式反馈给部分用户;
整体架构
数据结构包含了夺宝配置、夺宝信息、夺宝记录、夺宝号码、夺宝期号等数据结构,详情见图:
一些数据结构的简要说明:
1、夺宝配置:因为夺宝是一个系列,从第一期开始一直往后开,第一期完了开第二期,第二期完了开第三期,如此往复;此时,一个基础配置也就显得十分必要了,基础配置相当于一个母体,可以产生无数的夺宝信息;夺宝配置包括了夺宝标题、图标、购买货币类型,需要购买的总份数等基础数据;夺宝配置状态决定了是否继续开启下一期,当配置禁用后,不会影响当前正在夺宝的项目,但在本期结束后,不开启新的夺宝;
2、夺宝信息:通过夺宝配置派生出来的夺宝详情、开启第一期夺宝时,首先从夺宝配置表里面读取基础数据,填充到夺宝信息表里面;当一期夺宝买满以后,自动根据奖品类型发放奖励,如果是平台虚拟币,直接发放到用户账户中,如果是商城实物,自动产生一个已付款的订单,待用户填写收货地址;处理完毕以后,继续读取配置,开启下一期的夺宝,夺宝期数+1;
3、夺宝记录:记录了用户的夺宝概览信息、乍一看可能有些同学会觉得这个数据结构有些多余,当你看到复杂的前端设计,你就会知道它的好处了;此表主要记录:夺宝记录以用户ID、夺宝ID作为唯一索引,也就是说,一期夺宝一个用户只有一条记录,主要用于统计用户是否中奖,用户购买的份数;
4、夺宝编号:类似于彩票序列号,每一个份额一个序列号;如:1000元的夺宝项目,会产生1000个不重复的序列号,供用户购买;用户支付后,自动给用户一个序列号;序列号作为开奖的依据,表面上看也提高了中奖的真实性;
5、夺宝期号:期号独立做一个表,看起来确实有点多余了;主要是因为当时在设计时候,需求经常变化,如夺期号夺宝的购买类型分组(人民币和虚拟平台币),后来又按商品ID来区分;总之经过了很多需求的变化,最后衍生出来的;同学们也可以忽略此表;直接将期号写入夺宝配置表,每开一起,期号+1即可;
夺宝流程:
数据结构:
t_conf:夺宝配置表
t_dobo:夺宝信息表
t_dobo_record:夺宝记录表
t_dobo_code:夺宝号
t_dobo_period:夺宝期号记录
注意事项:
1、人民币支付夺宝时,可能会存在时间差问题;比如,用户购买时100份,当第三方支付成功回调时,发现只剩下50份了;这时候该怎么处理?提供几个参考思路:
1.1、充值成平台货币,如(夺宝币),充值成功以后再按实际的金额扣除、剩下的钱遗留在用户账户里;用户可以用于下次夺宝或提现;
1.2、比较暴力的方法,直接将剩下的金额用于参与下一期夺宝;
2、事务控制务必完善,支付、扣减夺宝数量、写入夺宝信息、发放奖励这些行为必须保证在一个事务里面执行,避免出现数据错乱;