現在的互聯網用戶越來越很多，互聯網服務的高并發的場景也變得越來越多。Himall多用戶商城系統限時購功能則是一個典型的短時間高并發搶購場景。雖然我們解決問題的具體技術方案可能千差萬別，但是遇到的挑戰卻是相似的，因此解決問題的思路也異曲同工。

　　什么是限時購?限時購跟大部分電商搶購業務相同,即限時且限量搶購。不管小米還是華為，或是其它電商公司，對搶購業務運營總是最為火爆，每發一款新品，都限量發售，每次搞的大家心里癢癢的。搶購太火爆有時引起站點打不開，崩潰了;還有就是賣出的數量比設置可購買的數量要多。那么問題來了：我們如何在設計中如何解決。通常我們需要從設計中考慮以下問題:

　　針對高并發，我們如何解耦后端壓力，特別是數據庫的壓力。

　　如何保障庫存可靠。

　　我們可以試想一下搶購時哪些頁面會請求最多。搶購之前人們通常會通常刷頁面等待，一般在搶購開始前一點時間會頻繁刷新搶購倒數的頁面或購買詳情頁面。搶購開始以后前一段時間下單的人會很多。付款并發量相對較小，通常訂單在下單后幾小時內都能付款，緩解了并發壓力。針對以上問題及場景，我們做了以下處理，增加限時購緩存訂單系統，去支持限時購高并發處理，并保持限時購業務的可靠性。

　　Hiamll在2.3版本做了如下改進:

　　1.引入Redis做緩存。

　　2.在用戶搶購開始前頻繁刷頁面時,系統只從緩存中取商品數據，解耦了數據庫查詢的壓力。

　　3.用戶下單時系統只把訂單數據存入訂單緩存隊列后然后告訴用戶你的訂單正在處理。然后由Redis Pub/Sub服務通知Web服務器，服務器把庫存訂單進行串行化處理，解耦數據庫并發下單壓力，保證庫存可靠。

　　4.支付功能保持原來實現不變。

　　具體實現如下:

　　買家前端查詢限時購商品數據時只走緩存。

　　賣家后臺更新限時購或庫存信息時需同步更新數據庫及緩存。

　　系統為每個正在開賣的限時購商品庫存創建鎖，買家對某庫存下單時鎖住該庫存的下單操作，每一個商品庫存只允許一個會員下單，下單的訂單數據直接加入訂單緩存后告訴買家[您的訂單正在處理,請稍等]。然后通過Redis Pub/Sub服務通知服務器處理訂單，將訂單按庫存串行化處理，訂單處理完成后，則更新限時購訂單緩存的處理狀態。

　　買家得知訂單正在處理后，則不斷查詢緩存的訂單處理狀態。直到獲取訂單處理結果，下單成功則進行支付頁面，失敗則提示失敗原因并引導買家重新下單。

　　最后就是在Web服務啟動時，需要對限時購訂單緩存系統初始化，把商品數據加入緩存中，并處理上次未處理完成的訂單。

　　總結:無論你用什么方式處理性能問題，性能優化的核心思想是分治。這種思想在日常生活中無處不在，大家都知道一次做不了的事，就分多次做，這就是分治。