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

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

　　針對高并發(fā)，我們?nèi)绾谓怦詈蠖藟毫?，特別是數(shù)據(jù)庫的壓力。

　　如何保障庫存可靠。

　　我們可以試想一下?lián)屬彆r哪些頁面會請求最多。搶購之前人們通常會通常刷頁面等待，一般在搶購開始前一點時間會頻繁刷新?lián)屬彽箶?shù)的頁面或購買詳情頁面。搶購開始以后前一段時間下單的人會很多。付款并發(fā)量相對較小，通常訂單在下單后幾小時內(nèi)都能付款，緩解了并發(fā)壓力。針對以上問題及場景，我們做了以下處理，增加限時購緩存訂單系統(tǒng)，去支持限時購高并發(fā)處理，并保持限時購業(yè)務(wù)的可靠性。

　　Hiamll在2.3版本做了如下改進(jìn):

　　1.引入Redis做緩存。

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

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

　　4.支付功能保持原來實現(xiàn)不變。

　　具體實現(xiàn)如下:

　　買家前端查詢限時購商品數(shù)據(jù)時只走緩存。

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

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

　　買家得知訂單正在處理后，則不斷查詢緩存的訂單處理狀態(tài)。直到獲取訂單處理結(jié)果，下單成功則進(jìn)行支付頁面，失敗則提示失敗原因并引導(dǎo)買家重新下單。

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

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