Java生鮮電商平台-商城系統庫存問題分析以及產品設計對邏輯/物理刪除思考
說明：在生鮮電商的庫存設計，是后台的重點，也是難點，關乎商品是否存在超賣。商品的庫存增加方式倒不難，直接在后台添加即可，而扣減方式就尤為重要，用戶在前端提交訂單減庫存，還是在支付成功后減庫存，兩種方案各有利弊，對后台庫存數據的變化影響也很大。
這里且先不說兩種方案的利弊，先看看淘寶是如何做的，淘寶是將兩種方案都做了，給賣家選擇。
12306是怎么做的呢，小編大膽的猜想，是支付成功后，減的庫存，而且一定是。
下面來分析下兩種方案的利弊：
第一種，提交訂單的時候減庫存：加入A商品庫存數為100，采用下單后，減庫存的方案，常規商品系統，下單歸下單，支付歸支付，是區分開的，例如在10分鍾內，有99個人下單了並且支付，身下一個訂單，同一個時間，有兩個人同時下單，比如都是2019.10.10 12:32:12 這個時間點，由於系統在這個時間點判斷都還有一個庫存，所以他們兩個都完成了下單操作，此時庫存為商品庫存為0，但是實際上是101個人下了單，而且這101個人都可以支付成功，這時候就出現了超賣現象。
出現這種情況的場景有兩個：一個是商品火爆，短時間內被下單，還有一個是商品庫存量小。
優點：實時減庫存，避免付款時應庫存不足，減庫存問題
弊端：存在說在短時間內，很多人都下單了，但是沒有支付，一直鎖定着庫存數據。真正的買家買不到
第二種，在支付成功的時候減庫存：案例同第一種方案中的案例，也是存在同樣的問題，在同一個時間點：比如都是2019.10.10 12:32:12 這個時間點，100件庫存，有101人同時支付，產品依然存在超賣現象
優點：防止有人惡意下單，占用庫存
弊端：在並發量很高的情況下，依然會存在超賣現象。買家認為已經下單了，但是告知不能付款
解決方案
關於超賣問題，根本上是不可解決的，但是可以通過一些優化方案，將風險降低
方案一：限制用戶下單數量
方案二：對惡意下單的做標識
方案三：后台庫存預警
方案四：備用庫存
關於秒殺活動對庫存問題的分析
數據庫最基本的增刪改查，一套最基本的完整的流程：數據的創建-->數據的修改-->數據刪除，其中數據的刪除，又分為邏輯刪除和物理刪除。
那么什么是邏輯刪除，物理刪除呢，他們又有什么區別，在軟件設計過程中為什么有些數據只能設計成邏輯刪除，不能物理刪除？
簡單的說：作為用戶，在軟件上將數據刪除，而實際上在數據庫中沒有刪除，只是從用戶層顯示數據已經刪除了。而物理刪除，用戶在軟件上將數據刪除了，數據庫中的數據也被徹底的刪除了。
邏輯刪除/物理刪除
舉一個例子，關於訂單的刪除，你是一個淘寶買家用戶，你在淘寶上購買了一件商品，付款成功，並且也收到貨，確認收貨了，整個訂單的狀態已經完成了，你把這個訂單刪除了，這時候的刪除只是邏輯刪除了。也就是數據庫中，這個訂單還是存在，但是你手機上不會顯示這個訂單了。為什么數據庫中的訂單還是存在，不一並刪除了？這就設計到數據的關聯問題：
這個訂單是你下單，支付成功並完成刪除動作，沒有錯，單單從你的角度考慮，它已經完成了。我們先不考慮系統層面為什么不能刪除，1 從賣家角度考慮，賣家要統計他的銷售情況，不能因為買家將訂單刪除了，這條訂單就不統計了吧，2 從商品角度考慮，a，商品是有商品庫存的，例如100件商品，你購買了一件，變成99件；b 商品的評分評星。等等。3 從物流的角度考慮，由於訂單是訂單，物流單是物流單，但是物流單和訂單是有關聯的，且不討論是單項關聯還是雙向關聯，把訂單刪除了，物流單關聯訂單為null，這時候是不是會報錯呢。等等各方面因數，以及后期新功能的開發，牽連到訂單，都會受到影響。
那有人會說，那我設計系統，所有的數據均設計為邏輯刪除，不是可以了，從邏輯上講，是的，但是有些又可以物理刪除，比如你創建一個數據，這條數據沒有和他的業務有關聯，僅僅是一條數據，這時候刪除，就可以物理刪除了，有人會問，系統設計，數據都是有關聯的，如果沒有關聯，就不是系統了，是的，我是說這條數據還沒和他其他業務有關聯，不代表沒有關聯，一旦數據關聯了，有時候邏輯刪除都不行的，例如一級目錄，二級目錄，而且目錄已經和其他業務產生了關聯關系，這時候要刪除一級目錄，由於二級目錄是寄托在一級目錄下的，所以一級目錄連邏輯刪除都不可以，刪除了，二級目錄就沒有了寄托了哈
談一談本地刪除和雲端刪除
舉一個的例子：現在很多人會把通訊錄備份到雲端，在換手機的時候，已經從雲端同步下來即可，在刪除通訊錄聯系人的時候，手機經常回提示，是否要同步刪除雲端數據，如果同步刪除，則是雲端刪除。此時有人會問，本地刪除，雲端也刪除了，是不是就是邏輯刪除呢。不一定，看系統是如何設計，如果還是設計成物理刪除，那么數據庫中你的數據其實還是存在的，所以雲端刪除和物理刪除沒有直接的關系。
再談一談后台產品關於禁用的概念
禁用又是什么，禁用后又可以啟用，這里在對賬號體系經常用到，由於賬號關聯的東西很多，所以賬號在原則上設計是不能物理刪除的（這里強調是原則上，由於又有賬號注銷一說，所以賬號不是不能物理刪除的）賬號用來禁用啟用，限用時段，例如你在用一個系統，由於現實因數，你不能在用這個系統了，系統管理員要把你賬號封了，這時候就是禁用操作，禁用后不可登。為什么不能物理刪除，前文已經說過了，那么為什么這時候賬號是禁用，而不是邏輯刪除了，因為存在一種場景，你后面又回來了，又要用這個賬號，從業務角度，你用之前的賬號才是對的，而不是重新在鍵一個新的賬號。禁用后一鍵啟用就可以了。另外就是to c 產品禁用到的禁用時段，比如大家經常玩的王者榮耀，賬號被限制1小時不能玩，這時候就是對你賬號禁用一小時，一小時后重新恢復正常。
說了這么多，產品在設計的時候，什么情況下考慮物理刪除，什么情況下考慮邏輯刪除，以及本地刪除和雲端刪除，需要從整個系統層面考慮，刪除后會影響什么業務，另外在不確定的情況線下，不要輕易物理刪除，因為后期也可能會關聯到，這些后端開發會考慮到的，但是作為一個產品，要懂得刪除這些道理，不要被后端認為一個小白，只會提“無腦需求”，這樣一來，溝通也好了，業務的開展也方便了。
關於賬號注銷
最后的最后，聊一下關於賬號的注銷，好像國家有規定，用戶可以創建賬號，也可以自行注銷賬號，像qq，支付寶等均有賬號注銷功能，那么賬號注銷，從用戶角度，徹底清空了賬號了，他還物理刪除呢，還是邏輯刪除呢？注意這是國家規定的一個方面，目前市面上大部分的產品是沒有注銷功能的，不用不管不登錄就好了。這...關於賬號的注銷又何去何從....