關於秒殺的系統架構優化思路

解決方案1：

將存庫從MySQL前移到Redis中，全部的寫操做放到內存中，因爲Redis中不存在鎖故不會出現互相等待，而且因爲Redis的寫性能和讀性能都遠高於MySQL，這就解決了高併發下的性能問題。而後經過隊列等異步手段，將變化的數據異步寫入到DB中。

優勢：解決性能問題

缺點：沒有解決超賣問題，同時因爲異步寫入DB，存在某一時刻DB和Redis中數據不一致的風險。

 

解決方案2：

引入隊列，而後將全部寫DB操做在單隊列中排隊，徹底串行處理。當達到庫存閥值的時候就不在消費隊列，並關閉購買功能。這就解決了超賣問題。

優勢：解決超賣問題，略微提高性能。

缺點：性能受限於隊列處理機處理性能和DB的寫入性能中最短的那個，另外多商品同時搶購的時候須要準備多條隊列。

 

解決方案3：

將寫操做前移到MC中，同時利用MC的輕量級的鎖機制CAS來實現減庫存操做。

優勢：讀寫在內存中，操做性能快，引入輕量級鎖以後能夠保證同一時刻只有一個寫入成功，解決減庫存問題。

缺點：沒有實測，基於CAS的特性不知道高併發下是否會出現大量更新失敗？不過加鎖以後確定對併發性能會有影響。

 

解決方案4：

將提交操做變成兩段式，先申請後確認。而後利用Redis的原子自增操做（相比較MySQL的自增來講沒有空洞），同時利用Redis的事務特性來發號，保證拿到小於等於庫存閥值的號的人均可以成功提交訂單。而後數據異步更新到DB中。

優勢：解決超賣問題，庫存讀寫都在內存中，故同時解決性能問題。

缺點：因爲異步寫入DB，可能存在數據不一致。另可能存在少買，也就是若是拿到號的人不真正下訂單，可能庫存減爲0，可是訂單數並無達到庫存閥值。

 

總結

擴容+限流+內存緩存+排隊

轉載自：http://www.cnblogs.com/chenpingzhao/p/6195788.html