2.Web伺服器叢集層,縮小鎖範圍. 每次秒殺活動開始之前.先計算活動推出的商品數量,然後分配一個限額到每個Web伺服器. 比如一個活動推出秒殺商品 電視,手機,衣服各1000件,那麼每臺伺服器的限額就是125件. 將這個限額寫入ZooKeeper,Web伺服器監聽到限額的變化,就會重新初始化各自的商品剩餘數量.


模擬例項
private static ConcurrentHashMap<String,Integer> map=new ConcurrentHashMap<String, Integer>();    
    private void zooKeeperHandle(){
        //將ZooKeeper的變化,初始化到Web伺服器全域性容器
        map.put("電視機", 125);
        map.put("手機", 125);
        map.put("衣服", 125);
}

假設使用者請求秒殺電視機,它只是鎖了該Web伺服器電視機的數量。(該Web伺服器手機和衣服還可以繼續併發處理,當然其他的Web伺服器也在同時處理電視機的秒殺請求) 這樣縮小了鎖定的範圍,增加了系統處理的吞吐量.

如果這個剩餘數量大於零,則將使用者ID放入電視機購買佇列, 
然後告知使用者秒殺成功如果這個剩餘數量等於零,則告知使用者秒殺失敗. 
即便別的Web伺服器還有電視機的剩餘配額.

3.ZooKeeper層,ZooKeeper變更庫存資訊 假設活動期間,需要修改庫存資訊。 兩種可能, 第一種,該商品已經賣了500件,電商不想繼續賣了. 第二種,從倉庫中又找到了一些積壓庫存..

兩種情況,都直接修改ZooKeeper中相應商品的配額. 
Web伺服器會監聽變化,並重新初始化全域性容器.

4.訊息佇列層,多消費者處理 
消費者主要是從佇列獲取購買請求,傳送至資料庫 
扣減資料庫庫存 
寫訂單明細記錄

5.資料庫層,使用儲存過程代替JDBC呼叫 由於使用了多消費者處理同一佇列,增加吞吐量,避免佇列堆積過大. 但是多消費者,必然導致資料庫出現單行更新問題(不推薦）

單行更新問題就是多個執行緒,併發修改同一條記錄,導致事務相互阻塞.浪費了資料庫寶貴的處理能力.


以上轉載 
http://m.blog.itpub.net/29254281/viewspace-1800617/