一元夺宝系统整体架构概览

 

系统介绍

一元夺宝项目，前段时间非常火；出现了很多夺宝平台，最近由于市场的监管，确实少了很多；夺宝模式其实非常简单，类似于彩票；就跟有个段子说的：大家每人给我发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、事务控制务必完善，支付、扣减夺宝数量、写入夺宝信息、发放奖励这些行为必须保证在一个事务里面执行，避免出现数据错乱；