現(xiàn)在的互聯(lián)網(wǎng)用戶越來越很多，互聯(lián)網(wǎng)服務的高并發(fā)的場景也變得越來越多。Himall限時購功能則是一個典型的短時間高并發(fā)搶購場景。雖然我們解決問題的具體技術方案可能千差萬別，但是遇到的挑戰(zhàn)卻是相似的，因此解決問題的思路也異曲同工。
什么是限時購?限時購跟大部分電商搶購業(yè)務相同,即限時且限量搶購。不管小米還是華為，或是其它電商公司，對搶購業(yè)務運營總是最為火爆，每發(fā)一款新品，都 限量發(fā)售，每次搞的大家心里癢癢的。搶購太火爆有時引起站點打不開，崩潰了;還有就是賣出的數(shù)量比設置可購買的數(shù)量要多。那么問題來了：我們如何在設計中 如何解決。通常我們需要從設計中考慮以下問題:
* 針對高并發(fā)，我們如何解耦后端壓力，特別是數(shù)據(jù)庫的壓力。
* 如何保障庫存可靠。
我們可以試想一下?lián)屬彆r哪些頁面會請求最多。搶購之前人們通常會通常刷頁面等待，一般在搶購開始前一點時間會頻繁刷新?lián)屬彽箶?shù)的頁面或購買詳情頁 面。搶購開始以后前一段時間下單的人會很多。付款并發(fā)量相對較小，通常訂單在下單后幾小時內都能付款，緩解了并發(fā)壓力。針對以上問題及場景，我們做了以下 處理，增加限時購緩存訂單系統(tǒng)，去支持限時購高并發(fā)處理，并保持限時購業(yè)務的可靠性。
Hiamll在2.3版本做了如下改進:
1.引入Redis做緩存。
2.在用戶搶購開始前頻繁刷頁面時,系統(tǒng)只從緩存中取商品數(shù)據(jù)，解耦了數(shù)據(jù)庫查詢的壓力。
3.用戶下單時系統(tǒng)只把訂單數(shù)據(jù)存入訂單緩存隊列后然后告訴用戶你的訂單正在處理。然后由Redis Pub/Sub服務通知Web服務器，服務器把庫存訂單進行串行化處理，解耦數(shù)據(jù)庫并發(fā)下單壓力，保證庫存可靠。
4.支付功能保持原來實現(xiàn)不變。
具體實現(xiàn)如下:
買家前端查詢限時購商品數(shù)據(jù)時只走緩存。
賣家后臺更新限時購或庫存信息時需同步更新數(shù)據(jù)庫及緩存。
系統(tǒng)為每個正在開賣的限時購商品庫存創(chuàng)建鎖，買家對某庫存下單時鎖住該庫存的下單操作，每一個商品庫存只允許一個會員下單，下單的訂單數(shù)據(jù)直接加入訂單緩 存后告訴買家[您的訂單正在處理,請稍等]。然后通過Redis Pub/Sub服務通知服務器處理訂單，將訂單按庫存串行化處理，訂單處理完成后，則更新限時購訂單緩存的處理狀態(tài)。
買家得知訂單正在處理后，則不斷查詢緩存的訂單處理狀態(tài)。直到獲取訂單處理結果，下單成功則進行支付頁面，失敗則提示失敗原因并引導買家重新下單。
最后就是在Web服務啟動時，需要對限時購訂單緩存系統(tǒng)初始化，把商品數(shù)據(jù)加入緩存中，并處理上次未處理完成的訂單。
總結:無論你用什么方式處理性能問題，性能優(yōu)化的核心思想是分治。這種思想在日常生活中無處不在，大家都知道一次做不了的事，就分多次做，這就是分治。
