mysql在電子商務**使用越來越多，做為第一梯隊做mysql的從業人員，也經常被問到mysql對於減庫存在這塊有什麼好的處理方法？對於這個問題，想想在課上分享及朋友中交流講的不下百次。所以也有了把這個總結一下的想法。
對於減庫存的操作，我們需要先從乙個更高的level來看一下，先不用討論update減1的問題。我們可以把減庫存行為簡單的分成以下幾種：
當然還別的形式，可能有的減訂單操作是乙個複合型的業務：如12306這樣的業務，含秒殺，搶購，限時活動於一身，難度空前絕後：）
那麼我們再來看一下訂單系統裡幾個難題：
那麼我再回過來看一下減庫存的形式，我們可以把減庫存，分為兩種：
問題分為：是否允許超賣，要不要考慮羊毛黨的一些行為。處理好這些問題的情況下支撐高併發業務。另外給老闆們提個醒，系統優化是乙個全面工作，不只是這裡有瓶頸。
我分成幾種情況來討論：
使用者下單減庫存如果允許超賣的情況下，外加乙個預警商品下架（缺貨）邏輯來處理，基本可以很快速的跑起來。業務邏輯最簡單適合正常商品邏輯。庫存大於多少可以上架之類的一些處理（後台人工調配）如果不允許超賣，例如車票這類，處理的辦法不在是簡單的庫存結構設計，可以把每個坐位做為乙個商品上架構，只是車票商品上的屬性有自已是那個車，挨著誰之類的資訊即可。下單後鎖定30分鐘…可以目前各大電商的主流邏輯，只是不同的平台，鎖時時間不一樣。防止使用者下單後幾天後還不支付，讓商品可以回歸庫存，不支付訂單的失效過程。下單減庫存也是大家最容易接受的乙個行為，但這裡把最難的問題拋給了平台，乙個商品多少沒支付返回庫存，目前來看不同平台處理的形為不一樣。不適用於搶購，秒殺點業務。
支付減庫存
搶購，秒殺，誰先付款誰得的邏輯。這樣可以避免羊毛黨下單後不支付的行為，例如，本來只有10個**產品，羊毛黨手快，下單成功，但種種原因沒支付，提示商品已售完，但活動結束了，乙個商品也沒賣出去，老闆花的活動費白花了。
高併發的搶購業務
例如某公尺周二中午的搶購，10萬個商品，可能是100萬人在搶購，這種行為，如果都打到db，可能是對db的鎖也是乙個挑戰，可能出現的行為就是不該慢的也慢了，去除檢查也是乙個好辦法。
現在聰明的人類想好了更好的辦法，利用nginx+lua引入接入在接層引入搖號方法，基於cookie在nginx層拿到了可以購買的資格再往後面放，如果沒拿到這個資格就在nginx上看看，提示你商品已經售完就行。這樣每次擴容，只用擴一下nginx接入層就ok了，其它不用擴了。
問題分類後，現在來看，對於減庫存，如果分類處理後，你會發現，還是挺容易處理的，這裡面裡也不要再來找我聊用mysql的樂觀鎖控制來減庫存了，如果你在知數堂的課上學習過，一定會知道多點寫入的樂觀鎖控制會造成更新丟失的現象，同樣來講，單節點的同時併發，不是序列的情況，這事沒戲，我確實見過有的公司在這塊用了序列事務，他們也跑的挺好，業務量不大。祝你玩的開心。也祝願你們早日在減庫存這塊遇到瓶頸，讓老闆高興痛苦的給你加薪。
精彩的內容要和朋友分享哦
資料庫的課堂討論（二）
今天，參加資料庫線上討論的問題 每次都得花我好多時間 問下面三者的關係，一開始我很懵，沒學過 實體型 和 實體集，因為看的是 浙大的課，而不是人大的課，書也不一樣，書裡莫得提及這個概念 實體 entity 客觀存在並可相互區別的事物稱為實體。可以是具體的人 事 物或抽象的概念。例如 學生 學生學號 ...
多個資料庫管理 的討論
場景 1 dba 人少,1 2人 2 資料庫種類 數量多 db2有10來套,並有hadr oracle 有近30套,其中有20套左右有dataguard mssql 有2000,2005,2008,並有多個logshipping 除mssql外，db2 oracle 執行在多種os平台 需求 終極目...
將查詢的資料匯出來 資料庫的基礎概述
資訊 共享性，有用性，知識性，它是客觀事件的反應。使用資料庫管理資料可以保證資料的共享性，安全性，和完整性。資料 用來承載資訊的物理符號，資料是資訊的一種表現形式，資料通過能書寫的編碼表示資訊 資料擁有四大特徵 型 資料的結構，即資料的內部構成和對外聯絡。例如 學生的資料 學號，姓名，年齡，性別，所...