新人初来乍到，先谢谢观看问题的人。下面开始说问题。
我现在要做一个类似夺宝类的东西
大概 业务需求是这样的
比如一个手机价格是6800元，大家众筹的方式进行购买，1元起底，1元就是1份。可以购买多份，买一份给一个code码，code码是随机发放的，买多份就给多个code码，众筹够6800以后开始倒计时开奖。支付满商品的价格后立马开始新的一期，买满的商品开始倒计时等待开奖，开奖后从奖池中摇到一个号码作为中奖用户，要保证首页的商品永远可购买。（这也就是我下面为什么做成用户去触发新一期的原因。）
我现在是这么做的
所有商品的第一期商品的所有code码是用脚本生成的，存在redis里面。整个购买分两部分，第一部分提交购物车的商品服务器返回给订单号码，第二部分客户端提交订单号码进行支付操作，这个接口要及时的给用户购买商品价格的code码个数，比如一个用户买了388份，就在支付完成的界面给388个code码，因为用户每次购买成功以后必须及时显示购买的code码，所以我把异步排除掉了。我在这个接口中还会判断某用户是不是付完这个手机6888元开始倒计时的最后一个用户。如果是，开始在逻辑里面生成该商品新的一期，并且生成新的一期的code码。没有用乐观锁去做，用的悲观锁，在用户进行购买的时候会把奖池里的号码锁住，购买交易完成后再解锁，如果没有给号码的话整个购买直接回滚，抛出异常。（这样貌似导致并发也不是很高，初期想法也是交给客户端如果拿到异常的状态多请求几次）。
用户在主界面在点购买时永远一直是最新的一期的，所以暂时交给最后一个用户去触发了。感觉不太对劲。如果用异步队列做，就不能保证用户在进行支付时及时的看到code码。（能想到非要用异步的话就是客户端进行打支付的第二部分的时候拆分成请求两次，第一次去支付，第二次去请求订单的code码。但是这样返回速度会慢。）求教大神的思路。
我理解这样的，首先提到几个关键性流程就是，下单，支付，发码，下单其实是独立的一个没有支付的订单完全可以不用去锁码，也就是说支付和发码才是一个原子操作，然后分析并发，首先订单的并发就随便玩吧异步同步全看你的并发是否已经到了令人发指的地步否则的话订单的调用后端系统的逻辑应该不会太耗时，然后支付和发码才是关键，首先据我了解任何一个支付系统都是很多流程的基本都是异步的，然后您说的发码不能及时看到的问题，其实如果并发不是太大就放在支付完去redis 随机拿个code 无太大问题，但是如果说并发又是令人发指我有一个用户体验不太好的想法不确定是否能适合，就是放开始支付之时支付异步不管其结果先去拿个码然后和这个订单关联起来发出来，当然如果这个异步结果出来了，支付失败的话码收回放回去，这样就会很快，然后有个疑问就是这个最后的抽奖环节应该是在所有码发完了再开始的吧，所以我觉得前面的用户购买还是能让他们等等的，这样才会有更多的惊喜嘛！能力有限只能理解到这里，还有你们这玩意有点众筹赌博的意思嘛！挺好的一想法蛮厉害的
我做过类似的。我是抢完之后自动进入下一期，你为什么不采用memcache锁呢