這個問題是我們當時開發時遇到的乙個難點，超賣的原因主要是下的訂單的數目和我們
要**的商品的數目不一致導致的，每次總是訂單的數比我們的**商品的數目要多，當時
我們的小組討論了好久，給出了好幾個方案來實現：
第一種方案是：①在每次下訂單前我們判斷**商品的數量夠不夠，不夠不允許下訂單，
更改庫存量時加上乙個條件，只更改商品庫存大於 0 的商品的庫存，當時我們使用 ab 進行
壓力測試，當併發超過 500，訪問量超過 2000 時，還是會出現超賣現象。所以被我們否定
了。第二種方案是：②使用 mysql 的事務加排他鎖來解決，首先我們選擇資料庫的儲存引擎
為 innodb，使用的是排他鎖實現的，剛開始的時候我們測試了下共享鎖，發現還是會出現
超賣的現象。有個問題是，當我們進行高併發測試時，對資料庫的效能影響很大，導致資料
庫的壓力很大，最終也被我們否定了。
第三種方案是：③使用檔案鎖實現。當使用者搶到一件**商品後先觸發檔案鎖，防止其
他使用者進入，該使用者搶到**品後再解開檔案鎖，放其他使用者進行操作。這樣可以解決超賣
的問題，但是會導致檔案得 i/o 開銷很大。
最後我們使用了 redis 的佇列來實現。將要**的商品數量以佇列的方式存入 redis 中，
每當使用者搶到一件**商品則從佇列中刪除乙個資料，確保商品不會超賣。這個操作起來很
方便，而且效率極高，最終我們採取這種方式來實現
專案經驗（一）
最近做了個不大不小的專案，積累了小小的一點經驗，今記錄下來，雖然很少，但是很寶貴。進入了這個公司，剛開始接手這個專案，第乙個感覺就是業務邏輯好重要，我是乙個工作經驗不是很豐富的新手。其實看起來設計表結構很簡單，無非是按照業務需要，將業務物件抽象出來放到資料庫當中去，可是隨著專案真正的進入編碼階段，我...
ERP專案經驗 一
有幸接觸到化妝品行業，今天來總結一下，這些行業的特點以及erp的使用經驗 能力有限，如有錯誤還望多加指教 有些功能其他行業也可能適用。比如 化工行業，食品行業，醫藥等 1.生產日期和限用日期的限制 2.安全和衛生的國家標準 3.批號管理 4.成分管理 5.法務管理 正是因為這些行業的特性，所以就會與...
專案經驗小結
專案內容 專案目的 傳統的日誌，記錄的是系統訊息流，控制流或資料流方面的資訊，尤其關注出錯狀態。從而為我們分析問題提供現場，得以知道問題發生的前因後果。分析日誌之後，可以知道整個故事的情節 時間 地點 事件等等。但我們不太容易從海量的日誌中提取重要的系統效能指標或引數，以實現垂直衡量系統效能和評估系...