上一篇主要分析了數據庫表結構這塊，這一篇就直接分析解決方案這塊吧。主要分為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、后面移植到專門的服務托管框架中去，讓數據庫盡量不參與業務邏輯運算，也就是數據庫只負責數據存儲。