原創(chuàng)文章，歡迎轉(zhuǎn)載。轉(zhuǎn)載請注明：轉(zhuǎn)載自IT人故事會，謝謝！
原文鏈接地址：『互聯(lián)網(wǎng)架構(gòu)』軟件架構(gòu)-解密電商系統(tǒng)-秒殺消息隊(duì)列異步下單（79）

上幾次主要說了高并發(fā)大流量項(xiàng)目所涉及到的技術(shù)點(diǎn)和技術(shù)方案，調(diào)優(yōu)需要注意的一些參數(shù)，秒殺訂單接口緩存的概念，通過redis的方式，redis需要進(jìn)行原子性。

秒殺優(yōu)化

使用緩存可以大大的提高我們系統(tǒng)的性能，但是需要考慮到周全，可能帶來數(shù)據(jù)的不一致性，所以要根據(jù)業(yè)務(wù)的場景和業(yè)務(wù)的邏輯，良好的維護(hù)它，如果漏了就會產(chǎn)生服務(wù)的不一致。產(chǎn)生線上的bug。

• 地址信息

正常的下秒殺單子的時候，需要先維護(hù)好地址信息，下單的時候需要提供對應(yīng)的地址信息。也可以將這些地址信息添加到redis中，當(dāng)用戶登錄的時候的默認(rèn)從redis中獲取地址信息，這樣就可以增加性能，但是還有個問題，用戶的地址會登錄后發(fā)生變化，也就是在用戶針對地址發(fā)生變化的時候，維護(hù)當(dāng)前用戶redis的地址。

• 下單校驗(yàn)

如果庫存有50個，請求過來5050個，最后下單成功了50個，但是其他5000個都要走一遍查詢流程是不是不應(yīng)該，應(yīng)該讓他走一半就結(jié)束，不應(yīng)該走到最后的庫存查詢就才結(jié)束，應(yīng)該在庫存查詢之前要走各種session校驗(yàn)，地址校驗(yàn)，信息校驗(yàn)各種。應(yīng)該在前面有個jvm內(nèi)存的校驗(yàn)直接就先告訴他庫存已經(jīng)少于等于0了就不要在往下面請求了，這樣服務(wù)壓力不會很大。也就是在內(nèi)存中jvm中有個變量來進(jìn)行判斷通過hash的方式。

• 下單異步化

下單后，可以進(jìn)行消息處理中，讓消息消費(fèi)端慢慢消費(fèi)消息中間件內(nèi)的消息。使用異步化下單后不能直接跳轉(zhuǎn)到支付頁面，可能訂單還沒生成，還在排隊(duì)，肯定不能直接返回待支付頁面，跟他返回排隊(duì)中。異步隊(duì)列效果最佳就是底層庫存比較大的情況下。這樣吞吐量比較大。

（二）前端控制

原來的時候下單完畢后，直接跳轉(zhuǎn)到支付頁面。如果是做成異步下單，就不能直接跳轉(zhuǎn)到支付頁面了，而是需要在等待頁面，等待頁面有個js方法定時循環(huán)的調(diào)用獲取這個用戶是否在數(shù)據(jù)庫存在單子，如果存在就直接跳轉(zhuǎn)支付頁面，如果不存在就一直等待，在等待的過程中如果庫存為0，說明已經(jīng)搶完了，失敗了，沒有最后落單，就直接通過客戶下單失敗，秒殺結(jié)束。千萬沒查數(shù)據(jù)庫了，查redis就可以了。

PS：BAT這種大公司里面的秒殺系統(tǒng)，一般涉及到7,8個中心，每個中心之前可能有2個開發(fā)人員，一個秒殺系統(tǒng)大概15,16個人員，在加上單元測試人員，功能測試人員。分布式并發(fā)問題就是很復(fù)雜，復(fù)雜就是在細(xì)節(jié)里面，用數(shù)據(jù)庫是可以查詢出來實(shí)時的。