一元夺宝开发方案-1.ppt

* 一元夺宝开发方案 宜昌树牙科技有限公司 以小博大 01 随众心理 03 追随大众的心理，一件商品，买的人越是少，那么越少人去买，相反，一件商品，买的人越多，那么销量很快飙升。一元云购就是利用消费者这样的心理，大家都投了一块钱，我也不特殊，投一块钱试一把。 侥幸心理 02 拼人品的时代，这个社会青年一族推动者商品交易的主旋律，拼爹、拼耐力、拼人品，大伙都是各种各样拼，把这种社会的风气带入到商品交易中，这又是一元云购的另一大特色。 积少成多 04 积少成多，一元云购，也就是一块钱，对于消费者，一块钱就是晒晒水的事儿，但是每个人一块钱，人多了可就不是一个小数目，一元云购能够迅速筹集大伙的资金，也就是从众筹引申来的。 01 一人一份 02 一人多份 一件产品每人可以购买多份 03 虚拟抵扣 4、一元夺宝的规则 01 每件商品参考市场价平分成相应“等份”，每份1元，1份对应1个夺宝码。 02 同一件商品可以购买 多次或一次购买多份。 03 当一件商品所有“等份”全部售出后计算出“幸运夺宝码”，拥有“幸运夺宝码”者即可获得此商品。 5、一元夺宝开奖计算公式 = ( ＋ ) “老时时彩”开奖号码 % 6488 该商品总需求人次 ＋ 100000001 原始数 6、一元夺宝设计流程 开始 浏览商品 页面 加入清单 立即夺宝 提交 清单 支付 支付成功修改缓存、数据库数据 返回投注号码 结束 7、一元夺宝缓存流程 备注： A、缓存采用memcached1.4.13版本。 B、运用其CAS特性，内部实现锁机制，无需外部加锁。主要是防止并发时，且剩下最后几注号码，多人抢注。单最后只会允许有一人成功。 C、购物车数量、下单数量等全部从缓存中拿。 D、首页列表需要展示商品可用夺宝数、剩余夺宝数。对于这种实时性高的数据，采取缓存1分钟。等到购物车或者下单会重新判断数量是否充足。 E、类似秒杀，这里没有采取排队机制，而是锁机制。系统允许有人在下单时失败，这种情况除了缓存之外，就是多人同时修改缓存数据，CAS版本号不一致。 8、一元夺宝定时任务 开始 查找已经完成的夺宝期数 根据投注记录计算出开奖号码与中奖用户，并且修改夺宝期开奖信息 结束 生成下一期投注号码；生成中奖未中奖通知记录；删除上一期投注明细。 备注： A、这里采用了Sql2008的代理任务实现定时任务，运作起来比较方便。 　　　B、后面移植到专门的服务托管框架中去，让数据库尽量不参与业务逻辑运算，也就是数据库只负责数据存储。 9、一元夺宝前端设计 说明： A、总需多少人次，已经参与多少人次，剩余多少人次。 B、根据夺宝的价位可以分为一元专区、五元专区、十元专区等等。 9、一元夺宝前端设计 ● 夺宝商品详情页 说明： A、显示夺宝期号 B、显示投注基本单位（即为参与人次，投注越多，人次显示越多） C、产品基本信息 9、一元夺宝前端设计 ● 商品夺宝参与记录 说明： A、显示夺宝支付时间。 B、显示夺宝用户信息，头像、昵称或者账号。 C、显示夺宝者的网络IP信息。 D、显示参与了多少人次，系统随机分配的夺宝号码。 9、一元夺宝前端设计 ● 往期夺宝记录列表 说明： A、显示最后50名夺宝者信息，可以理解成为产品订单。 10、一元夺宝模块说明 整个一元夺宝中主要分为商品(后台、前台)、夺宝订单、夺宝期、开奖4大模块。 一、商品模块 对于商品这块区分前台与后台的理由是： A、后台主要是管理商品的基本属性参数，例如ID、名称、所属名牌品类，颜色尺码SKU等，当然这里是分主子表。 B、 前台在后台的数据基础上记录一些扩展行为参数，例如设定该商品进行到多少期就停止夺宝、总共需要多少人次参与、基本夺宝人次单位等。 这样做的好处就是严格区分本身基本属性与后续扩展的行为熟悉，互不干扰但存在关联关系。 *