上一篇主要分析了数据库表结构这块，这一篇就直接分析解决方案这块吧。主要分为3大块，分别为夺宝整体流程，缓存流程，定时任务流程。
一、夺宝整体流程
备注：A、普适性流程。
B、目前是单站点，IIS服务器，对IIS进行了优化，参考链接:http://www.cnblogs.com/xiongnanbin/p/3676350.html。
C、后面会设Ngnix专题，也就是后面会用Ngnix做负载均衡代理服务器，不过在这之前可以用多域名来实现负载均衡。
二、缓存流程
备注：A、缓存采用memcached1.4.13版本。
B、运用其CAS特性，内部实现锁机制，无需外部加锁。主要是防止并发时，且剩下最后几注号码，多人抢注。单最后只会允许有一人成功。
C、购物车数量、下单数量等全部从缓存中拿。
D、首页列表需要展示商品可用夺宝数、剩余夺宝数。对于这种实时性高的数据，采取缓存1分钟。等到购物车或者下单会重新判断数量是否充足。
E、类似秒杀，这里没有采取排队机制，而是锁机制。系统允许有人在下单时失败，这种情况除了缓存之外，就是多人同时修改缓存数据，CAS版本号不一致。
ps：所有的被发送到memcached的单个命令是完全原子的。如果您针对同一份数据同时发送了一个set命令和一个get命令，它们不会影响对方。它们将被串行化、先后执行。即使在多线程模式，所有的命令都是原子的。然是，命令序列不是原子的。如果首先通过get命令获取了一个item，修改了它，然后再把它set回memcached，系统不保证这个item没有被其他进程（process，未必是操作系统中的进程）操作过。
memcached 1.2.5以及更高版本，提供了gets和cas命令，它们可以解决上面的问题。如果使用gets命令查询某个key的item，memcached会返回该item当前值的唯一标识。如果客户端程序覆写了这个item并想把它写回到memcached中，可以通过cas命令把那个唯一标识一起发送给memcached。如果该item存放在memcached中的唯一标识与您提供的一致，写操作将会成功。如果另一个进程在这期间也修改了这个item，那么该item存放在memcached中的唯一标识将会改变，写操作就会失败。
三、定时任务
备注：A、这里采用了Sql2008的代理任务实现定时任务，其实还是蛮方便的。
B、后面移植到专门的服务托管框架中去，让数据库尽量不参与业务逻辑运算，也就是数据库只负责数据存储。