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

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

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

　　如何保障庫存可靠。

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

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

　　1.引入Redis做緩存。

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

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

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

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

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

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

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

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

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

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