原創(chuàng)文章滞诺，歡迎轉(zhuǎn)載。轉(zhuǎn)載請注明：轉(zhuǎn)載自IT人故事會，謝謝！
原文鏈接地址：『互聯(lián)網(wǎng)架構(gòu)』軟件架構(gòu)-解密電商系統(tǒng)-秒殺消息隊列異步下單（79）
上幾次主要說了高并發(fā)大流量項目所涉及到的技術(shù)點和技術(shù)方案谴忧，調(diào)優(yōu)需要注意的一些參數(shù)，秒殺訂單接口緩存的概念，通過redis的方式沾谓，redis需要進行原子性委造。
秒殺優(yōu)化
使用緩存可以大大的提高我們系統(tǒng)的性能，但是需要考慮到周全均驶，可能帶來數(shù)據(jù)的不一致性争涌，所以要根據(jù)業(yè)務(wù)的場景和業(yè)務(wù)的邏輯，良好的維護它辣恋，如果漏了就會產(chǎn)生服務(wù)的不一致。產(chǎn)生線上的bug模软。
- 地址信息
正常的下秒殺單子的時候伟骨，需要先維護好地址信息，下單的時候需要提供對應(yīng)的地址信息燃异。也可以將這些地址信息添加到redis中携狭，當用戶登錄的時候的默認從redis中獲取地址信息，這樣就可以增加性能回俐，但是還有個問題逛腿，用戶的地址會登錄后發(fā)生變化，也就是在用戶針對地址發(fā)生變化的時候仅颇，維護當前用戶redis的地址单默。
- 下單校驗
如果庫存有50個，請求過來5050個忘瓦，最后下單成功了50個搁廓，但是其他5000個都要走一遍查詢流程是不是不應(yīng)該，應(yīng)該讓他走一半就結(jié)束耕皮，不應(yīng)該走到最后的庫存查詢就才結(jié)束境蜕，應(yīng)該在庫存查詢之前要走各種session校驗，地址校驗凌停，信息校驗各種粱年。應(yīng)該在前面有個jvm內(nèi)存的校驗直接就先告訴他庫存已經(jīng)少于等于0了就不要在往下面請求了，這樣服務(wù)壓力不會很大罚拟。也就是在內(nèi)存中jvm中有個變量來進行判斷通過hash的方式台诗。
- 下單異步化
下單后，可以進行消息處理中舟舒，讓消息消費端慢慢消費消息中間件內(nèi)的消息拉庶。使用異步化下單后不能直接跳轉(zhuǎn)到支付頁面，可能訂單還沒生成秃励，還在排隊氏仗，肯定不能直接返回待支付頁面，跟他返回排隊中。異步隊列效果最佳就是底層庫存比較大的情況下皆尔。這樣吞吐量比較大呐舔。
（二）前端控制
原來的時候下單完畢后，直接跳轉(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ù)雜就是在細節(jié)里面淆两，用數(shù)據(jù)庫是可以查詢出來實時的。
