雙11天貓、淘寶網的超賣問題是如何產生

　　這會導致淘寶的雙11活動賣出的金額191億元很水啊

　　情況是這樣的嗎?而且大多發生在零點10分以內的?

　　當商家的存貨趨近于0的時候，大量買家共同買入，當其中交易完成時，存貨減1。如果這時存貨數量到達0了，可還是有大量買家沒有完成付款，從而生成超賣的訂單了?

　　子柳，淘寶打雜的 碼農

　　有一個CAP理論，擴展性、一致性、可用性和成本之間形成了相互制約的關系，可以理解成下圖的三角形邊長是收益、面積是成本，如果三個邊都很長的話，成本是最大的。

　　在雙十一這種最極端的場景下，要滿足三個條件，成本更是高到無法承受。那我們縮小哪一條邊長呢?可用性不能缺(不能宕機)、擴展性不能缺(要支持大規模的并發訪問)，只能犧牲一部分一致性了。這里采用異步通知、分布式事務等操作，來保證數據盡可能多的“最終一致”，但不可避免的會產生少量數據的不一致，這是在計劃中可以容忍的。

　　另外還有一個業務方面的邏輯問題，這可能比技術方面出現超賣的概率更加大一些。

　　需要解釋一下交易減庫存的兩種方式：

　　一，拍下減庫存

　　描述：下單之后，商品的庫存就減一，減庫存失敗 下單就失敗，然后再去付款

　　問題：惡拍，惡人會把賣家的商品都拍光，商品下架了，然后不付款

　　二，付款減庫存

　　描述：下單之后不立即減庫存，跳轉到支付寶付款，淘寶接收到付款成功消息后，才去減商品庫存

　　問題：超賣，熱銷商品尤其是秒殺商品，同時會有n多人同時付款成功，然后去減庫存時，發現庫存不夠減了

　　最后，也不排除個別賣家借這個機會來推卸責任的可能性。

　　岳天，互聯網從業者，挨踢農民工，半碼農

　　技術方面上面@子柳已經說的很明確了，超賣再交易量很大的情況下，出于對可用性和擴展性的需要，嚴格控制一致性成本無法滿足，所以超賣還是有小部分。

　　下面從影響方面說說，首先，無論國內國外的網站都有超賣的情況發生，像現在正在進行的 黑色星期五，很多商品都有超賣，而國內外網站處理超賣大部分采取 “砍單”(砍單不一定全部是因為超賣)，作為海淘一族，大部分已經形成概念“低價商品砍單時正常，不砍單是走運。”，亞馬遜比較少砍單，也是因為其系統支持強大，較少發生超賣，京東等B2C也有超賣砍單情況。

　　此次天貓居然沒有像 “團購寶事件”那樣 全部進行退款砍單，而是進行了 30%的補償，也是非常不錯的。

　　應該可以預見造成的影響 是正面大于負面。

　　然后說一說一致性的問題，所有網站里，一致性要求最高的當屬金融類網站，再具體點就是銀行的交易系統。

　　有知道關于銀行系統的知友可以講一講。

　　剛研究了下 銀行業的一些資料，發現 實時的轉賬匯款有個20秒的概念，分2部分，一是發起交易確認付款，而是返回交易回執，交易才算完成。沒有返回交易回執，則認為匯款失敗，錢退回來。

　　淘寶的交易系統應該借鑒這樣的操作，訂單下后確認付款，同時確認庫存，一旦發現超賣，即刻顯示付款失敗。

　　不要等到過了好幾天才告訴別人，超賣了，貨發不了，很傷人的。

　　張磊，學生淺薄，望諸師雅正。。。

　　可以從產品和運營兩個角度，同步操作改善這個問題。

　　但是在產品角度上，需要評估投入產出比，如果投入產出比較低、那么不一定會得到執行。

　　一、產品角度：混合減庫存方案

　　1.設立一個庫存數闕值，比如50件。

　　--達到闕值之前，采用付款減庫存的方案。

　　--達到闕值之后，自動轉為拍下減庫存的方案。

　　2.當然這個闕值需要根據并發訂單數、“下單未付款”狀態單數、總庫存數等參數(也許還有其他參數)進行配置。

　　--在平時，并發訂單數可能只是2件，平均會有最多10單左右處于“已下單但未付款”的狀態。那么，這個闕值設為10件(或者12件?還沒深入思考)。

　　--在促銷時，并發訂單數可能達到50，同時處于“下單未付款”狀態的可能達到500單，那么這個闕值就可以考慮設為500件。

　　3.考慮到商品數量、高并發下系統的響應速度等因素，這個闕值可能還要再上調一部分比例，比如10%。

　　4.如果這個闕值可以自動調整，那就更完善了。但是在大數據量面前，這有點科幻了。

　　5.如果自動切換出現異常，則系統自動彈窗提示管理員手動切換。如果彈窗也崩了，那就放棄執行，允許按付款減庫存的方案銷售商品直到庫存為零商品下架。

　　二、運營角度：縮短付款等待期的時間窗長度 +超量備貨或減量上架。

　　0.縮短時間窗長度很好理解，在系統里調整一個時間參數就可以了。

　　1.超量備貨：如果，庫存系統的數據可以與實際庫存量不一致。那么在促銷時，比如系統庫存數是1W件，那么實際備貨數量就按闕值的兩倍，進行超量備貨。

　　2.減量上架：如果，庫存系統的數據與實際庫存數量必須一致。那么在設置參加活動商品的數量時，比如庫存是1W件，那么活動商品就設成9000件。

　　三、但是這兩種方案并行之后，作用只能是減少超賣的規模而非杜絕。

　　由于網購的特點，非常受制于商品、時間、用戶結構等因素，而這些因素很難在一個大型活動前進行全部的、完全精準的預估，所以很難完全杜絕超賣。

　　四、將開發成本、系統成本，與產品效果對比，判斷投入產出比。如果投入產出比不高，就只在運營方面進行調整吧。。。

　　樂游，總是很想吐槽

　　超賣一般是秒殺系統設計得不完美。具體來說就是因為短時間內對數據庫的操作過于頻繁，并發的操作太多，可能有兩個或以上的操作同時處理同一件庫存，這樣就會賣超。

　　因為秒殺活動的環境跟一般出售商品不同，減庫存這種方法是不能依賴的，所以現在設計的秒殺系統基本都不會像上邊兩位說的靠減庫存(這樣的話幾乎全部會賣超)。一些B2C的秒殺架構是給每個庫存一條單獨的數據庫記錄，用一個字段表示“是否售出”。這樣很多操作同時進來數據庫，只要遍歷所有庫存，找一個未售出的庫存上鎖，然后慢慢處理即可?？梢源蟠鬁p少超賣的情況。

原文轉自：http://www.anti-gravitydesign.com