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，支付宝等均有账号注销功能，那么账号注销，从用户角度，彻底清空了账号了，他还物理删除呢，还是逻辑删除呢？注意这是国家规定的一个方面，目前市面上大部分的产品是没有注销功能的，不用不管不登录就好了。这...关于账号的注销又何去何从....